February 19, 2019
You spot your biggest competitor walking down the street. They have a big chocolate cake in a box under their arm - at least that’s what it looks like from your window. You think: “####!! How did they get that? We better have one of those. Now!”
In the world of technology companies, this happens all the time: company X launches feature Y, and other companies follow. The trouble is that cake is not what you think it is, the reason you think it exists isn’t the right one, and it’s almost certainly not what’s best for your customers and company.
Instead of thinking about delivering cakes to Songkick’s users (as nice as that would be…), our teams care about solving problems which result in outcomes for them. If there’s a better product for them out there than a chocolate cake, they’ll find it - and everyone will be so much better for it. Here’s how.
A recipe in a cookbook affords a great structure that explains all the different types of things a product team is set up to deliver: the ingredients, the method, and the end product itself.
Together, these outputs are what creates value for your users and company, and can power a product team through years of customer-centric innovation. As time goes on, these recipes form a book of solved problems and product recipes that become a hugely valuable company resource.
However, when a team is starting to make something new for the first time, there are big gaps all over the recipe. Perhaps the team knows they’re trying to make a sweet dish, but there are a just a few (of many) ingredients listed, a space for what looks like a rather long method - and nothing else - and the specific end product they’re trying to make isn’t well articulated either.
The ingredients are a good place to begin. Starting out it’s likely your company might not have all the ingredients your team needs to solve this problem. Don’t have a bit of technology that does that complicated thing? Are you okay investing the effort and time to grow it from seed? Or do you want to find a substitute for it?
The composition of the ingredients can be very different too. When you’re cooking, an egg is pretty much an egg. But in technology there’s much more variety in components that aim to do roughly the same thing. Think you have a system that handles user authentication? It probably does, but doesn’t in the way you think it will, or need it to.
While AWS and the other cloud platforms are creating more sophisticated easy-to-use ingredients for teams, this isn’t yet the norm. With these challenging ingredients, it’s important that teams really take the time to understand what they’re working with - this need drives every day questions and challenges for product managers and tech leads.
Recipes don’t just appear out of thin air. They’re often a result of trial and error: tweaking, refining, trying something a little bit different. Seeing what an extra egg does to your cake recipe, or cooking at a slightly different temperature are great examples of this in the kitchen. It allows a team to control all the other factors and learn if that change makes the cake better or not. The same happens in building products, iteratively working through logical additions to your mix to find the next big thing.
Sometimes the team can taste something and know if it’s better. But often blind taste tests tell the team so much more about the potential success of a product. Through A/B testing, the team can learn by understanding what customers really do: how they interpret and use the various parts of the end product, and what they find engaging about what they see.
By this point the team has a good idea what they’re going to create to solve the problem. They’re now thinking about what the composition of the end product is, and how they can deliver it quickly to all of their users. Tricks like shop-bought pre-rolled puff pastry, or cooking in the microwave, allow them to condense multiple ingredients or complicated method steps into one, and great teams are always on the look out for these trades.
It’s also important for the team to use their creativity to make sure the end product tastes the best it can for the end users. Using knowledge of customer preferences when productising any feature is vital - know they have a sweet tooth or are used to doing things a certain way? The team is going to want to factor that in to the finished product, and using this qualitative data.
While the team is now handy in the kitchen and their recipe has been refined for their audience, they’ve never done a service of hundreds of thousands of covers. By starting by rolling out your product to a small audience, teams are able to check it’s behaving as expected, that enough of the edge cases are well-enough handled, and that the technology is able to scale to simultaneously handle service to a large, hungry audience.
But before the team gets on to tackling another problem, there are some really important things that still need to happen to get the most out of all this work.
The most important is to get the recipe in the book - sharing what they did, how they did it, and what the results looked like. For companies with a strong focus on data-driven product delivery, this knowledge becomes a real accelerator for all teams - enabling them to transplant the most effective learnings and patterns into the next problem they solve, with the potential to save weeks and months of effort at a time.
There’s lots of work to be done across the team and technology too - cleaning down the kitchen, refactoring similar things into components or services you can use again, and chucking out stuff you no longer need, all of which will make it easier next time you get back into the kitchen.
The value a product team creates isn’t just the meal that delights your customers. The ingredients they develop along the way, and the learnings the team and the company forge in the method are often just as important in ensuring your company means something to your customers. While your instinct to fast-follow chocolate cakes with more won’t ever go away, by thinking about product this way, you’ll find a much more fruitful way of innovating with technology.
This was part 2 of stretching-tenuous-analogies-that-explain-what-product-managers-and-product-teams-do, hopefully for your entertainment.