Weāre a small startup (10 people at time of writing) with big ambitions, particularly when it comes to our product. With so many things we want to do, itās important for us to be structured the way we approach our work, without being so process-driven that we lose all the benefits of being small and nimble.
As weāre still new, and the team is growing all the time, very little is set in stone. The way we work is constantly changing, and weāre always open to new ideas or suggestions to help us to collaborate as well as we can.
We also recognise that thereās no one true way to run a project. We can consider this outline as a list of tools in our toolbox which we can use when appropriate, as opposed to a runbook that we follow religiously for everything we build.
With all that in mind, hereās an outline of how we kick off projects at incident.io.
Letās assume weāve already decided on a project (for example, Workflows). We hope to discuss how we think about prioritisation at some point, but thatās a blog for another day.
A scout is someone whoās nominated to help us hit the ground running and guide our initial conversations about what we want to build. It also means the rest of the team can get on with other things while they focus on preparing for a successful kick-off.
Many of the things we build are similar to things other people have built before us. To avoid re-inventing the wheel, and help get some ideas, we pull together a prior art document. Itās not about finding something to imitate, but a collection of things to inspire discussion.
This document is a fairly unstructured round-up of the different approaches taken by other products. Sometimes this will include other incident tooling, but it often also includes companies which have solved similar problems in a different space. As an example, the prior art doc for workflows included products such as Slack, Zapier and Tines.
Now that weāve got our creative juices flowing, we need to work out in detail what our new product will look like. We find it useful for our scout to take a āfirst passā at what the product might need to do, deliberately looking for decision points or trade-offs weāll need to make. This doc forms the basis of our main kick-off (itās circulated as a pre-read-if-you-can).
We go through the doc as an entire team (not just engineers!), discussing the different decision points and shaping the scope of the project. We try to consider a variety of things:
We explicitly do not discuss implementation, except in the rare circumstances where an implementation detail forces us to change our UX (e.g. a Slack restriction forces us to choose UX option A).
At the end of the kick-off, we hope to have a shared understanding of the rough shape what we want to build right now, and what we might want to build later but donāt think is required for the MVP.
For some features, we want to talk to our customers to give us the best chance of building a product which works for them.
To help us with this, we produce a proposal which outlines the rough scope weāve agreed, calling out the trade-offs that weāve made along the way. We also try to be clear about things weāve decided not to do right now, to give customers a chance to tell us that weāre wrong.
Weāve found that we get more actionable feedback discussing the pros and cons of a concrete proposal than just a problem statement. Often, the devil is in the detail, and writing the proposal surfaces the tricky corners of the feature where customer feedback can be really valuable (e.g. which of these two non-ideal scenarios is more intuitive).
We then discuss this with current and prospective customers, both on individual calls and in our community Slack workspace.
We bring this feedback back to the team, usually asynchronously (in Slack), and use it to help reconsider the choices we made in the kick-off. That might include:
At this point, weāre comfortable that we have a shared understanding of an MVP. Letās get building! Check out this blog post for advice about how to break down a project into manageable chunks.
In reality, weāre likely to start building while we talk to customers; often there are parts of the feature (usually foundations) that we want to get started on straight away.
We also donāt view anything weāve decided so far in this process as gospel: as we build we expect to learn more about the problem domain and find new ideas and challenges. When we need to, weāll regroup (async or sync) to discuss the trade-offs of whatever implementation detail comes out of the woodwork.
The aim of this process isnāt to get a fully fledged enterprise product spec that can be thrown over the fence to a dev team. As an ex-Accenture consultant, I can 100% guarantee that is a recipe for disaster. This is just the beginning; a starting point for us to build and iterate from.
We created a dedicated page for Anthropic to showcase our incident management platform, complete with a custom game called PagerTron, which we built using Claude Code. This project showcases how AI tools like Claude are revolutionizing marketing by enabling teams to focus on creative ways to reach potential customers.
We examine both companies' comparison pages and find some significant discrepancies between PagerDuty's claims and reality. Learn how our different origins shape our approaches to incident management.
The EU AI Act introduces new incident reporting rules for high-risk AI systems. This post breaks down what Article 73 actually mandates, why it's not as scary as it sounds, and how good incident management makes compliance a breeze.
Ready for modern incident management? Book a call with one our of our experts today.