Building a complex new product can be scary. What if no-one gets value from it? What if it doesn't work? What if it's hard to change?
One way to mitigate these risks is to break down the product into smaller shippable increments, allowing you to capture feedback early and confirming the most important assumptions before fully committing to a solution.
At incident.io, we believe that shipping is the heartbeat of any product company (see a great Intercom blog post on the subject). Shipping helps us as a company by:
When we're building something complicated, these things are even more important than usual. So rather than waiting until we've reached the final form, we look for ways that we can ship chunks of the new product along the way.
Shipping smaller increments along the way can feel like you're taking a detour; slowing the team down on their way to the real prize. But it's not that simple. Due to the benefits of shipping we discussed above, gathering feedback and validating technical assumptions means the team is less likely to waste effort. That can often shorten the time to complete the product you really want, rather than the product or design you imagined at the start.
Splitting a large project into several shippable increments has a number of other benefits:
It's all well and good talking about shipping smaller increments, but how can we break down a complex product?
Our first instinct (correctly) is to find a feature which delivers value to a customer. This is likely to be a subset of the functionality that your complex product can deliver.
A useful way of finding these increments is to think about use-cases: what might someone be trying to do with your new product? Are there ways that you can enable just a single use-case without having to build the entire product?
Ideally, you want to have a list of candidate use-cases which you think are compelling and can support with a sub-set of the original product. You'll also need a sketch of what would be needed to deliver each one.
Once you've got a list of candidates, you need to choose which one(s) to deliver, and how to sequence the work. As with all engineering and product problems, there are no easy answers: there are a number of factors we need to trade-off with each other. We can return to our three objectives:
The way we prioritise these three objectives should be specific to the product that you're building. Which of these is most true?
When building a house, you have to build the foundations before you build the walls. Software is no different; there'll be parts of the code you have to write first. This is something we also need to consider: if supporting this use-case would actually require you to build 95% of the final product, there might not be much point shipping this subset first.
Another way of framing this approach is to prioritise reducing uncertainty. Uncertainty about whether the product is valuable, or whether the technology works.
Depending on the size of the product, you might just want to choose a single use-case here, or you may want to choose a number that you deliver in sequence. Generally, the larger the end-product, the more good candidates you're likely to find. Equally, don't force it: if there are no good candidates, you might want to take a different approach.
Some projects might be better served by silently shipping parts of the product. This usually means taking something that your existing product already does, and doing some rewiring so it's now using your new code.
This is useful when you're trying to validate the technical approach (rather than gathering feedback or delivering value). You can get your code running in production, see how it performs, see how it feels to build and debug against, without needing to find a shippable unit which delivers new value.
Note that as this doesn't provide the opportunity for feedback, or direct value to customers, we'd generally prefer to ship a user-facing feature where possible, but this is a useful fallback when that isn't feasible.
When faced with a large scary project, first think about what makes it scary. Is it uncertainty about the product, the technical approach, or perhaps both? Break down the project into smaller shippable increments, designed to reduce this uncertainty and keep the team shipping, to give you confidence in your approach and retain momentum and focus.
Moving fast does not happen by accident. Here is some of the intentional things our engineers do to move so quickly!
Cutting through the hype and dollar signs, why should you actually join incident.io? And also, why might this not work for you
In the past year, we've reimagined how we build AI products at incident.io, moving from simple prompt based features to now building full-blown AI-native systems end to end. Learn why we’re hiring AI Engineers, what that work looks like, and how it’s changing the future of incident response.
Ready for modern incident management? Book a call with one our of our experts today.