Run incidents without leaving Slack
Tailored to your organization for smarter incident management
Confident, autonomous teams guided by automations
Learn from insights to improve your resilience
Build customer trust even during downtime
Connect everything in your organization
Streamlined incident management for complex companies
Run incidents without leaving Slack
Tailored to your organization for smarter incident management
Confident, autonomous teams guided by automations
Learn from insights to improve your resilience
Build customer trust even during downtime
Connect everything in your organization
Streamlined incident management for complex companies
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.
Image credit: Martin Reisch
Enter your details to receive our monthly newsletter, filled with incident related insights to help you in your day-to-day!
Keeping the codebase consistent with Pattern Parties
As a codebase evolves, it’s common to see some divergence in the design patterns within it.
Kelsey Mills
Clouds, caches and connection conundrums
During a recent infrastructure migration into Google Cloud, we kept running into a pesky issue without a clear cause. Here, we dive into the twists and turns we took to finally figure out what the smoking gun was.
Ben Wheatley
Practical guidance for getting started as a Site Reliability Engineer
Here are a few strategies that might help you build up context, find the problems that really matter and turn these into a plan of action.
Ben Wheatley