![The start of a racetrack](/_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2Foqy5aexb%2Fproduction%2F0ce666a9067b046b1a4d3932d78f35e4ec2bcdcd-2400x1576.jpg&w=3840&q=75)
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:
- What would the ideal experience be for the customer?
- What is technically feasible?
- 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.
Image credit: Austris Augusts
![Picture of Lisa Karlin Curtis](/_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2Foqy5aexb%2Fproduction%2Ffdd2d553f58284a7641cb96adad76b70c273d127-690x690.png&w=256&q=75)