Anti-pattern #3: Not balancing innovation, business as usual, and keeping the lights on work
The product model is not all about innovation: it’s about focus and addressing how your organization and products can create value now and in the future.
Note: this is the third article in the series on anti-patterns when moving to the product model. Here’s the first anti-pattern: "Giving too much autonomy, too soon".
Let’s start with a story.
A “sad trombone” moment
We had laid the foundation. The CPO and CTO had a strong bond and were committed to making this change happen. The ambition was to fundamentally improve the ways of working, shifting from a relay race to fostering a cross-functional, collaborative environment. A key stepping stone of the transformation was finding a pilot team to lead the way. The idea was to train, coach, and mentor the team in mainly product discovery through user research, prototyping, and validation techniques. The question was: which team would be the best fit?
We found one that met our criteria:
The team had an opportunity to make a swift impact.
The team had a driven product manager who was invested in working differently.
The team had direct access to customers and data.
The team had designers willing to facilitate product discovery activities.
Together, we decided that the first step would be to facilitate a full-day session to explore opportunities for the team. We created an agenda with relevant exercises to generate hypotheses, or “bets,” for the near future. As we progressed through the agenda, there was energy in the room and excitement to try new approaches.
Around 2 pm, we reached the finale of the day: planning the next six weeks of discovery and delivery activities.
Oddly enough, the energy in the room shifted.
People lined up in front of the walls to lay out activities. Post-its were flowing. Conversations were held between the PM, designers, and engineers. We walked up to the wall to take a peek.
And then, reality hit.
Two words were written on post-its across the entire wall:
“AWS upgrade.”
Apparently, a few days prior, engineering leadership had determined that a specific part of the infrastructure needed to be updated by a set date, without consulting or informing anyone outside of tech. A colleague next to me became increasingly agitated and raised their voice.
“What about this AWS upgrade? Do we have to do it?”
An engineer replied, “Unfortunately, we need to do it. They’re shutting down the old environment.”
Cue the “sad trombone” sound. The plug was pulled: the focus had to shift to “keeping the lights on.” We had just hit our first roadblock in the transformation.
The reality hits you
This story isn’t uncommon when starting a transformation. The point is to highlight the naivety that can occur when moving to the product model. There’s excitement. You find pilot teams. There’s alignment on the transformation’s direction. Energy is ready to be released.
But then, reality hits. You haven’t done your homework to assess your readiness.
The fallacy: the product model is all about innovation
There’s a common misconception when moving to the product model: that it’s all about innovation. Teams can finally do proper product discovery instead of being handed half-baked requirements from the business.
The narrative above highlights misalignment, but it also reveals what happens beneath the surface. The truth is, product teams are responsible for all kinds of work to ensure their product remains valuable. And, it’s not just about innovation.
The three buckets of product work
In a product team, there are three major categories of work:
Bucket #1: New value work
This category is all about creating new solutions that don’t exist in the market to meet new use cases and needs. For instance, this could mean targeting a new customer segment or solving a new problem adjacent to what you’re currently addressing.
Example: If you’re a media streaming business, this could mean venturing into gaming, choose-your-adventure stories, and other innovative ways to meet customer needs.
Bucket #2: Existing value work
Here, you’re working with an existing product and feature set. The goal is to retain customers and continue capturing the product’s current value. You iterate on functionality to improve metrics, attract new customers that fit the profile, and keep existing customers happy through incremental improvements.
Example: For a streaming service, this could involve improving the sign-up flow, updating pricing plans, or adjusting the personalization engine.
Bucket #3: Protect value work
This is often referred to as “keeping the lights on” work. It’s about protecting the business's future by making investments to ensure compliance, security, and scalability.
Example: The AWS upgrade in the story is a perfect example. For a streaming service, it might also mean adhering to new privacy regulations or updating the architecture to enable teams to work more independently.
However dull this work may seem, it’s crucial to the health of your product and business. This category of work also takes precedence over other initiatives if there is a major incident.
The downside is that stakeholders from the business often don’t understand—or don’t want to understand—the value of this work. They can’t sell your efforts to reduce tech debt or migrate your cloud infrastructure. If you’re in sales or marketing, you need new features to showcase to customers. That’s why it’s essential to tell a compelling story about why you’re investing in this bucket, explaining how it will lead to future value and return on investment.
How to avoid this anti-pattern
A key factor for a successful transformation is to show early, tangible results that demonstrate how the new way of operating delivers faster outcomes and more value. To achieve this, you and your peers leading the transformation need to have serious conversations to create alignment and to manage expectations. One effective technique is to create a hybrid roadmap, blending the traditional “project mindset” with the “product mindset.”
Project mindset: focuses on timelines and features to build
Product mindset: emphasizes outcomes and product discovery
A hybrid roadmap: Co-creating a path you believe in
Many people have a love/hate relationship with roadmaps—or maybe just hate. Roadmaps tend to become a Frankenstein’s monster, with either too much detail or not enough. Below, I’ll outline actionable ways you can create a roadmap as a key tool to drive and align the transformation—one that:
Creates a holistic picture of what is and will be worked on (output)
Connects features/output to specific problems to solve (outcomes)
Manages stakeholders’ expectations about the likelihood of delivering features.
Encompasses all three buckets of work: new value, existing value, and protect value
How to facilitate a hybrid roadmap workshop
Step 1: Have all product leaders (product, tech & design) fill in a similar sheet prior to the workshop:
The goal is for them to list everything they are currently working on and what they want to work on in the future. Using a sheet like this helps shift the focus toward problems and outcomes, as well as ensures they consider how data will be leveraged to measure the value of their ideas.
Note: The list shouldn’t just be based on their own priorities—it should also incorporate requests received from the business. In many cases, these ideas may come in the form of features to build, rather than problems to solve. You can reverse-engineer the feature requests to identify the underlying problems they aim to address.
Step 2: In the workshop, stack rank the problems you want to solve
To kick off the workshop, each participant shares the problems they’ve identified and places them on the whiteboard. After the presentations, the group discusses and debates to prioritize the list. The goal is to create a clear, ranked order of problems to solve, based on importance and impact.
Step 3: Categorize problems based on the three buckets of work
Now that you’ve prioritized the problems, have a conversation about how to distribute efforts across the three categories of work: new value, existing value, and protect value. Discuss what percentage of efforts should be invested in each bucket.
Afterwards, adjust the stack ranking of problems if needed.
Step 4: Sequence the problems across four quarters
On a whiteboard, create a table with four columns representing the four quarters of the year. Using the stack ranking from earlier, sequence out the problems you want to solve over the year. Also, write the success criteria (metric) for each problem to solve.
Step 5: Create the list of initiatives (solution hypotheses) tied to the problems
Start by listing all ongoing initiatives in the current quarter for both product and tech. Then, move on to the next quarter.
For product, label initiatives as either delivery (features being shipped) or discovery (learning and reducing risks). This distinction helps differentiate between work that's in progress and what’s still being figured out.
In the tech row, engineers should consider the enabling technologies they need to build, as well as the feasibility or technical discovery needed for the product teams to deliver on their initiatives.
By the end of this step, you should have a roadmap filled with problems to solve and initiatives mapped out across all four quarters.
Step 6: Voilà! You now have a prototype of a hybrid roadmap.
That wraps up the workshop. You've now got a first draft of the roadmap, ready to be shared for further alignment.
Keep in mind, this will likely need a few iterations before it’s polished enough to share with a wider audience.
What’s neat is that you can translate your problems to solve to Objectives and Key Results (OKRs).
Problems = Objectives
Leading/lagging indicators = Key Results
Step 7: The CPO and CTO come together to create a cohesive roadmap in a digital format that can be shared.
Step 8: The CPO and CTO then meet with stakeholders from the business to present the roadmap and gather feedback.
Now it’s time to gather feedback and create alignment on the direction moving forward. When discussing the roadmap with the business, an important factor is to talk about “likelihood”—explaining that it’s very likely you will deliver the initiatives in this quarter, but as you move further out in time, the confidence decreases.
The story you tell: This is due to the fact that you haven’t done proper due diligence yet (discovery). There are many risks tied to these initiatives, and you’ll need to conduct research and run experiments to reduce product risks. You don’t want to end up in a situation where these initiatives don’t return on their investment.
Step 9: You have alignment on the problems to solve, and now pilot teams can start working.
Hopefully, your meetings with the business were successful. You’ve gathered feedback and received the go-ahead to move forward. Now, you can begin staffing pilot teams who will start working on solving the prioritized problems to initiate the change journey.
Key takeaways
The product model is not all about innovation: it’s about focus and addressing how your organization and products can create value now and in the future. To set your transformation up for success, ensure that your pilot team(s) have the opportunity to create swift value and show tangible results. To achieve this, you need to create alignment on which opportunities are ripe for the picking. A useful technique is to create a hybrid roadmap that solidifies a common understanding among the business, product, and tech teams on how you will create new value, capture existing value, and protect value for your company over the next 12 months.
What’s next
Next up, we’re going to talk about the D word: Dependencies. They can make or break a transformation.