Anti-pattern #8: Going “all in” at the same time
Apply a product mindset to your transformation, launch pilot teams as experiments, and invest in onboarding programs to overcome this pitfall.
Note: this is the eight 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 set the stage. The organization has slowed down. Innovation is stalling. People are quitting. Investors are getting restless.
Sweat beads on your forehead.
As a leader, you want change—now. You’re ready to go “all in” on the product model. Tomorrow.
But wait—
Is that really the right move?
No. Not exactly.
Let’s explore why going “all in” can backfire—and what you should do instead.
First, let’s take a step back and examine what’s driving this urgent need for change.
Day 1 and Day 2 companies
“It’s always worth asking, do we own the process, or does the process own us?”
—Jeff Bezos
Jeff Bezos coined the terms “Day 1” companies and “Day 2” companies in one of his letters to Amazon shareholders.
Day 1 companies are at the beginning of their potential, even if they’ve been around for years. They are nimble, constantly on their feet, and exhibit customer obsession and high-velocity decision-making.
Day 2 companies, on the other hand, are process-oriented. They focus on capturing the existing value of their products. While they make high-quality decisions, they do so slowly.
A transformation to the product model offers Day 2 companies the chance to recapture their Day 1 mojo—reigniting their spirit, speed, and ambition.
A familiar story
When working with scaleups, I’ve heard this story time and time again:
“We used to be so fast. All of us in one room—coming up with an idea one day and launching a new feature the next. We were always in direct contact with customers, listening closely to their needs. I even stayed up late answering customer service emails myself. I miss those days. Now, we’re painfully slow.”
Faced with this dire situation, there’s often a knee-jerk reaction: “We need change. Now.”
And so, the instinct is to go “all in” on a transformation—immediately.
Without much further ado, let’s explore why that impulse will backfire.
A story about going “all in”
“Can’t we start next week with all teams?” the executive asked the HR director.
Management had made up their minds. They were ready to push the button.
Consultants had been brought in. Meetings held behind closed doors. A new org chart drawn up. Alongside it came a so-called “product strategy”—which, in reality, was just a list of projects to deliver on time.
HR was tasked with redefining roles and accountabilities. Product owners? Gone. The focus shifted to product managers—and you had to apply for these roles. No more SAFe. Agile terms like “Kanban,” “Sprints,” and “Estimations” were replaced with a new vocabulary: “Discovery,” “Outcomes,” and “Empowerment,” though there was little clarity about what these terms actually meant in practice.
The transformation office set up a project plan to communicate and roll out the changes—across the entire organization, all at once. All-hands meeting invites were sent out, with little explanation beyond the cryptic subject line: “BigCo’s New Operating Model.”
The day came.
BigCo’s new operating model was revealed. As a participant, you logged into the Zoom meeting, joining hundreds of others. A senior executive—smiling—greeted everyone and explained that this new way of operating would be a “game changer”.
From now on, everyone would work in “empowered teams.” The presenter went to great lengths to explain the shifts and clarified that, starting next Monday, the new model would take effect—for ALL teams across the ENTIRE company.
The executive handed the mic to the HR director, who walked through the next steps. You logged off the meeting, and the first word that came to mind was:
“Huh?”
You had tons of questions. Legitimate concerns. What does this mean for me? How will I work differently? A pang of anxiety hit you.
Why going “all in” backfires
Let the story above serve as a cautionary tale. Imagine yourself on that call. What’s running through your mind?
Come Monday, you can already predict what will happen: confusion. “What’s expected of me? What’s expected of my team?”
Confusion will give way to doubt: “Can we really pull this off?”
And doubt will spiral into stress: “This is never going to work!”
It’s a predictable chain of events—one that could have been avoided.
If you dive headfirst into a transformation without laying the groundwork, teams will lose their way. They won’t have the environment needed to succeed. Leaders won’t see tangible results because teams will be stuck in perpetual “hair on fire.”
The product model is built on autonomy, and as we explored in anti-pattern #1, autonomy only works if teams have:
A) the competence needed to succeed in this new way of operating, and
B) clarity of direction, meaning leaders have established a sound strategic context with clear problems to solve, framed as team objectives.
Without A and B, the loop of transformation failure is inevitable.
By going “all in,” you expose yourself to massive risks. And the biggest risk? That this new way of working produces worse outcomes than the old one.
Betting everything at once raises the stakes—and increases the likelihood of blowback.
There’s an alternative. A better way. Spread your bets.
How to avoid this anti-pattern
Applying a product mindset to a transformation
Embarking on a change journey toward the product model comes with a lot of uncertainty. And how do you handle uncertainty in product development? You gather insights. You test, learn, and iterate. You prototype to address product risks—making small, calculated bets along the way.
Driving a transformation should follow the same approach. To reduce the risk of “building the wrong organization,” you prototype your way forward.
Pilot teams as prototypes
When coaching organizations through change, a proven technique is to launch pilot teams to experiment with this new way of working. These pilots gather evidence to demonstrate that the new approach delivers value—providing proof to the rest of the company that the change is worth investing in and turning Doubters into Believers, as discussed in anti-pattern #6.
The two main product risks pilot teams should address:
Value risk: The risk of not delivering meaningful outcomes for both the customer and the business.
Viability risk: The risk of not understanding or aligning with stakeholders’ needs or managing their expectations.
Usability and feasibility risks are typically areas where teams already have expertise, so the focus should be on value and viability as critical measures of success.
Tackling the risks through coaching, mentoring and training
To address the risks outlined above, pilot teams need dedicated support to succeed. This includes coaching, mentoring, and equipping them with new techniques and skills.
But first, you need to carefully select the teams best suited to pave the way.
When selecting pilot teams, consider these criteria:
Ambition and willingness to learn: Choose teams that show a genuine eagerness to adopt new skills and embrace new ways of working.
Opportunity to create swift impact: Focus on teams working on initiatives that can deliver quick wins and gain high visibility across the organization.
Staffed with the right competencies: Ensure the team has the necessary roles and expertise to effectively achieve their objectives.
Credibility and political clout: Select team members who are respected and influential.
“Oh, I get it” moment
After selecting your pilot team, there’s often an initial burst of energy and excitement. They’re eager to be the team that paves the way. For many, this is a big shift—from being a “feature team,” where someone else dictates what to build, to being in the driver’s seat. It’s thrilling but also a bit uncomfortable.
As highlighted in the story of going all in, there will likely be initial confusion: What should we focus on? How do we collaborate? And most importantly, HOW do we work in this new way?
Your job as a coach, trainer, or mentor is to help the team reach the “Oh, I get it” moment as quickly as possible—that moment when the puzzle pieces fall into place, and everything starts to make sense.
A quote to aim for:
"Oh, I get it. This totally makes sense. Why haven’t we always worked like this?"
To achieve this moment, you need to bridge the gap between the big picture and the small picture—the day-to-day work. The key isn’t just explaining the transition in abstract terms—provide the team with tangible techniques and practices they can put into action right away.
What defines the “Oh, I get it” moment?
The “Oh, I get it” moment is when the team realizes that this new way of working will:
Make them more effective by having a deeper understanding of end-users, customers, and the business.
Strengthen collaboration by leveraging each other’s strengths.
Enable them to track progress, making their work more meaningful by tying it to the value they’re creating.
Clarify how their efforts align with the company’s and product’s overarching goals.
And, most importantly, show how this new way of operating supports their individual career growth by developing new skills.
Your focus should be on designing an onboarding program with that goal in mind—helping teams reach their “Oh, I get it” moment as quickly as possible.
Onboarding pilot teams: Setting them up for success
An onboarding program should connect the strategic view—the transformation's purpose and strategic context—with the tactical view—the team’s objectives and actionable techniques they can apply to experiment and make progress toward their goals.
Typical focus areas for an onboarding program include:
1. Introduction session ≈ 90 minutes
Hosted by leadership, this session establishes the foundation by sharing the story behind the transformation and explaining why this team was selected as a pilot. It provides clarity, inspiration, and a chance for direct interaction with leaders.
Example agenda:
Welcome: Introduce the session and its goals.
The purpose of the transformation: Share the "why" behind the change and key insights learned so far.
Introduction to the product model and empowered teams: Explain what it means to work in this new way.
Common challenges and tips: Address potential hurdles and approaches for overcoming them.
How the team will be supported: Outline the next 90 days, detailing available support (e.g., training, coaching, mentoring) and who will provide it.
Questions & answers: Encourage open dialogue through a fireside chat with leaders.
2. Product strategy (3 hours)
This session helps participants connect the company’s product strategy to their team initiatives. The focus is on “filling the air sandwich,” as Jason Yip describes—linking strategy, objectives, customer problems, and experiments into a clear narrative.
Example agenda:
Welcome: Start with the session’s focus.
How the world is changing: Explain macro factors influencing your company’s challenges and opportunities.
The product strategy: Outline the key problems to solve over the next 12–24 months.
Strategy to outcome: Show the important connection between strategy, team objectives, and experiments.
Team objectives: Define 90-day goals for the team that align with the broader product strategy.
How you measure progress: Highlight how an OKR dashboard can track weekly progress and the leadership’s role in removing roadblocks to help achieve the goals.
Next steps: Explain how teams will set their own key results with leadership feedback and guidance.
3. Product discovery (3 hours)
This session gives a crash course on how teams should approach product discovery. With a clear team objective, they learn how to measure progress and explore techniques for both problem and solution discovery.
A technique to emphasize: Opportunity Solution Tree (OST). This tool helps teams connect objectives with customer problems, solution ideas, and experiments to launch within weeks.
Example agenda:
Welcome: Introduce the session and its objectives.
Product discovery theory: Share key aspects such as product risks, discovery & delivery, and collaboration.
Practice: Product risk mapping: Facilitate a “pre-mortem” exercise to identify potential risks with their team objective and how to address them over the next 90 days.
Practice: Opportunity Solution Tree: Build on the pre-mortem by connecting the team’s objective to customer opportunities, solutions, and experiments that can be tested in the coming weeks.
Next step: Challenge the team to launch one experiment within the next two weeks to make progress toward their objective.
Examples of additional sessions:
More sessions could be added based on your understanding of the team’s competencies when it comes to the skills needed to move toward the product model.
For instance:
Product delivery: Apply concepts relating to team topology, architecture, dependencies, and continuous delivery.
Stakeholder management: Techniques to collaborate and partner with stakeholders in an effective way.
Additional product discovery sessions: Exploring user research, further mapping, and validation techniques.
Team collaboration: Exploring traits of high-perfoming teams, coaching and psychological safety.
Optional sessions for new teams:
Social event: An informal session for team members to get to know each other.
Team working agreement: A structured session to define the team’s norms, values, and ways of working.
Why onboarding matters
This onboarding program addresses the key skills and competencies teams need to thrive in the product model—guiding them to the pivotal “Oh, I get it” moment.
By taking teams through such a program, you ensure they understand the “why” behind the transformation while equipping them with the tools they need to succeed in this new way of working. It prepares them to confidently tackle continuous discovery and delivery.
When teams build these new capabilities, something remarkable happens. As we’ve discussed earlier, pilot teams evolve into case studies for “What good looks like,” capturing the attention of the rest of the organization and proving that this new way of working delivers meaningful value.
Key takeaways
If you go “all in” at once, your transformation efforts will likely backfire. Instead, focus on creating the right conditions for success. To do this:
Adopt a product mindset for transformation: Approach change iteratively by testing, learning, and refining along the way.
Launch pilot teams as prototypes: Leverage these teams to gather evidence, showcase value, and turn Doubters into Believers.
Invest in onboarding programs: Provide teams with the skills, tools, and context they need to excel in the new operating model.
What’s next
In the next article, we’ll dive into the trap of “Leaders not talking enough about the ‘why’.” Defining a clear purpose, vision, and objectives for the transformation is critical. But it doesn’t stop there. Leaders must continuously share these with teams. This ensures alignment and keeps everyone steering in the right direction.