One of the core principles we apply to building product at Intercom is “think big, start small”.
What looks like a small piece of UI can sometimes be supported by 6 months worth of code.
This means taking on big, ambitious projects and tackling them as a series of small, iterative steps. We call it the cupcake approach to building product. Instead of building in one big chunk (i.e. a complicated, three-tiered wedding cake) cupcakes deliver value to your customers early, let you learn what works and what doesn’t, and fast forwards the feedback loop. You’ll then be able to take the next step towards your big ambitious project, armed with more information and a clearer sense of direction.
Building and shipping these well-scoped pieces of product is easier said than done. Small projects can often hide huge amounts of complexity, and no matter how small a feature you scope, it can still take a significant amount of engineering work to actually build it. What looks like a small piece of UI can sometimes be supported by 6 months worth of code.
For example, we’re working on improving reporting features for our Respond product. There are many additional features that we plan to deliver, but our first “cupcake” release last week was simply to allow time periods of our current reports to be customizable. This might look like a simple change superficially, but there’s months of complex engineering work behind it. Even though this feature is small, we’ll learn a lot from how well our technical solution handles scale, the date ranges our customers use most frequently, etc. This will directly feed into our future releases, making for a better wedding cake in the end.
Thinking big and shipping small is a simple concept but is really hard to get right, and we’ve got it wrong more than a few times. One trap you can fall into is when a feature requires a large amount of engineering work. In this case, the temptation for any product manager is to keep adding to the original scope of your cupcake. To justify the investment in the months of engineering effort, you want to add all the features that this new tech enables. When time and resources are limited, it’s natural that you want to get the most bang for your buck.
Features are like children…once they’re born you’re stuck with minding them and saving for their college fund.
But this is a dangerous path. By adding so many features, you’ve inadvertently built a wedding cake. On releasing it, it becomes very difficult to validate anything about your approach – the whole point of building a cupcake in the first place. It becomes tricky to know what customers appreciate about what you’ve shipped and what they don’t, what features are really impacting your metrics and what features weren’t needed at all. Remember, features are like children. They might be conceived in a night of passion, but once they’re born you’re stuck with minding them and saving for their college fund.
By building and testing so many things at the same time, you end up not knowing how to improve the feature. The feedback is diluted and iterating on it is more difficult because of all the features you’ve built.
The simple advice here is that if the feature you’re building requires a large amount of engineering effort, avoid the temptation of layering on additional functionality to leverage this technical investment. There is no correlation between effort spent and a minimum number of features, so keep it as a cupcake. Keep your scope tight and make it the smallest but most delicious version of the feature you can. Release the cupcake, understand how it’s being used and learn what you need to build next.
If you want to come build some cupcakes with us, we’re hiring Product Managers.
Comments