Recently, I’ve been mulling over why product teams fall into an equilibrium of sorts when it comes to innovation. The Innovator’s Dilemma is always framed in terms of companies and categories, but what does that look like within a product development organization?
Over the last few years, I’ve been working in environments where product work is framed as “bets”. If you’ve gone through any Reforge content you’re familiar with this concept of bet making. I’ve even shared my own framework for different types of bets (features, fixes, foundation, future). But lately I’ve been stepping back even further and thinking about the “why” behind bets, and in my opinion there are 3 recurring reasons:
Increment: iteratively improve the product you have
Evolve: meaningully change the product you have
Invent: fundamentally build a new product based
I’ll say it another way, using product hypothesis language:
Increment: keep going down the current solution path
Evolve: explore alternative solution paths to problem
Invent: revisit the problem without solution bias
So let’s dive deeper into each of these modes.
[1] Increment
When you have a widely adpopted solution, the leaning of the product team becomes maintaining and improving that baseline level of adoption. The focus is on what the historical uptake rates have been for incoming users, and how to optimize that. When an organization is in this mode, they have well-understood north star metrics and drivers, and a well-oiled product development machine designed to make incremental progress against those measures. To be clear, this is not a bad place to be if you are the major player in the market and your goal is to show you have a handle on your core flywheel.
[2] Evolve
When you are not the largest player in your space or there are external factors (competitor pressure, technical innovation) at play, you have to think about evolving your approach. This is tricky for product teams because they have to let go of investments they’ve made in the past that may no longer be the optimal solution path, but it’s also very do-able because someone is showing their is a better way to address the needs of users in the market. So the change management hurdles are more about alignment and skillset vs concerns about technical feasibility or market viability. The hardest version of this is when there is no external pressure, so you get complacent, and user perception atrophies and becomes a drag on both product and success teams. One of the best methods I’ve seen to combat this is to regularly re-surface the solution paths not taken for debate by your senior ICs in PM/design/engineering.
[3] Invent
Lack of invention and eventual disruption is what a lot of tech company literature covers, but I find most of that writing lacks empathy for what it’s like to be a product leader at a company that’s the king of the hill; it’s nearly impossible to get an organization to invest in bets that are orthogonal to the asks of customers and have no real timeline or guarantee of payoff. Invention is a luxury investment for an established product…until it’s suddenly not. Companies that successfully balance maximizing short-term outcomes while building their own future competitors in-house tend to do so through a combination of strategic hedging, buying innovation, and firewalling R&D teams.
tl;dr
The default mode for most orgs at scale is [1]. There are instances of [2] due to top-down (or external) pressure. But [3] doesn’t seem to happen much, if ever.
The whole conundrum reminds of this Jeff Bezos quote about process as proxy:
“Good process serves you so you can serve customers. But if you're not watchful, the process can become the thing. This can happen very easily in large organizations. The process becomes the proxy for the result you want.”
Is this just classic Innovator’s Dilemma? Or is there a cultural reason why we lean towards [1]? Could we change something in terms of rituals / principles to do more [3]?
As always, I’d also love to hear from readers about how they allocate bandwidth to different types of bets - please chime in via comments👇 or join the chat via the Substack app.
And if you enjoyed this post, please consider subscribing.
Lastly, I’m teaching a course on Scaling B2B Products on Maven - you can sign up for an upcoming cohort (December or January) via the link below - if you enjoy my writing it’s a great opportunity to apply these frameworks in practice to your product.
https://maven.com/ibscribe/scaling-b2b-saas
further reading / references
Reforge has several good posts that reference the concept of bets, including offense vs defense, big swings, beyond PMF, and scaling delivery
I explain features / fixes / foundation / future further in 4 Ways to F Up Product Development
the branch diagram above is from my Product Paths post
while looking for solutions to this dilemma, I came across the idea of The Bowie Scale which Atlassian employed at one point to counteract this tendency
childish drawing / interpretation
