Starting projects at incident.io

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.

🔭 Choose a scout

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.

🎨 Prior art

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.

❓The what

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:

1. What would the ideal experience be for the customer?
2. What is technically feasible?
3. What is a sensible trade-off for releasing an MVP?

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.

💬 Customer consultation

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:

• Rethinking a design decision (to make it more understandable / intuitive for a user)
• Altering our scope (pulling stuff into or out of the MVP because it’s more/less valuable than we anticipated)
• Adding new features to the ‘post MVP’ phase (e.g. extra ways to help customers get value from the feature).

🏃 On your marks, get set...

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.