Anti-pattern #2: Focusing on parts rather than the whole
Your transformation will likely fail if you treat product and tech as a bubble. To succeed, you need to be inclusive, build trust, and collaborate with the "business".
Note: this is the second 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".
Product is, in most companies, the most pivotal aspect of the business. It’s what provides solutions to customers’ problems. It’s what you sell and monetize to pay everyone’s salaries.
Since it states “product” in the product operating model, when embarking on a journey of transformation, you might have a bias to only focus on the “product” part. This may cause all kinds of problems that could, in the end, jeopardize the entire transformation.
Let me explain by telling a story—a story that perhaps rings a bell.
A story of a failed transformation
Enough was enough. This was the catalyst moment—the straw that broke the camel’s back.
The head of product, in a state of deep frustration, opened Slack and frantically sent the head of engineering a message: “We need to talk. This is getting out of control.” Done. A meeting was scheduled for later that day. As their tête-à-tête began, it became instantly clear how bad the situation had become. The tension had been building for years.
They decided—at that juncture—that they couldn’t go on like “this.” They needed to change.
Both of them had used words like “feature factory” or “build trap” when talking about how they were stuck in the middle—listening to the “business,” with their forceful tone, dictating what needed to get done, while teams themselves demanded autonomy.
The head of product and the head of engineering wanted to change the narrative. Instead of being handed requirements, they wanted to lead the way and give teams the leeway to succeed.
As a result, to break out of the rut they were in and to focus more on product management rather than project management, they locked themselves in a conference room over the weekend. Fueled by caffeine, they defined a simple product strategy and broke it down into a set of team objectives. With their new and shiny strategy in hand, they packed their bags and embarked on a roadshow to share their results with the teams. A few weeks later, they tackled the roadmap. Instead of a classic four-quarter roadmap with due dates and “accountability leads,” they created an outcome-based one that aligned with the teams’ objectives.
“Finally, we are working in the right way.”
There was a sense of momentum within the product and tech organization — an air of excitement.
Beneath all this shimmer, there was trouble. Big trouble.
Who didn’t they invite to the party?
Everyone else.
Picture this.
It was a few months into the change. You, the outsider on a field visit, walk around their office building. You stop. On the door’s nameplate, it states “VP of Sales” in golden letters. You decide to knock on the door and say hi. You introduce yourself and ask a few questions about their experience working with the product and tech organization.
Let’s pause there.
What words do you think they would use? What would they say? What facial expression would they have?
Smiles and giggles?
Most likely the opposite.
If you were to boil down that conversation to a few words, it might be: “Where is MY feature on the roadmap?!”
What would likely happen: the VP of Sales would go on a rant. They’d state that “product” just cares about themselves, that they just create solutions that can’t be sold, and that they don’t know what the customers — really — want.
You listen, nod, say thank you, and make your way.
Let’s play the tape again a few months forward. What would happen to the situation inside the company?
You smart cookie: transformation failure.
The small ponds of frustration across the “business” accumulate over time to create a groundswell. The groundswell becomes a tsunami of politics and negative energy that wants to revert to “how it used to be” or to change the ways of working to another, less fitting, operating model—SAFe, anyone?
The pinnacle is a meeting within the executive leadership team where the business, on one side, has mobilized with a vindictive PowerPoint to showcase how product doesn’t deliver. There’s clear tension in the room—a blame game, a tug-of-war. And the question is, who will win?
Let’s leave that open and instead ponder the root cause.
What caused this mess?
The root cause
The root cause of this failed transformation is a lack of inclusion, and holistic thinking.
The head of product and head of engineering wanted to fix the problem by leaving the business out of the equation. They might have said, “We know what good looks like. We just need to do things our way, and the rest will follow.” By excluding the rest of the organization, they disregarded others' talent, insights, and knowledge. Sure, they might have antiquated ways of viewing product development, but that doesn’t mean they aren’t competent in areas you might lack.
How to avoid this anti-pattern
Refraining from “centricity”
As part of my assessment approach when helping companies move to the product model, I meet with many people inside and outside of the product and tech organizations. What often surfaces in these conversations is how they view the centricity of their product or products. What I mean by that is the way they view the culture of product development. I might hear phrases like:
“We take product design seriously. We are design-centric.”
“We really care about our customers. We are service-led.”
“We have a really strong sales organization. I would say we are pretty sales-oriented.”
In the TRANSFORMED book, Marty Cagan brings this aspect to light as well. It’s not just a question of centricity and culture, but it’s a question of trust: who is most trusted to make the call of what to build, who is most attuned to the needs of customers, and how to monetize solutions. Who has the most chips on the table?
Building trust
“You have as much ownership as you have credibility.”
Marty Cagan
Trust takes time. It’s not a skill that you can pick up or something that can change in a month. You need to show your peers and senior leaders that you are capable and trusted to make the right decisions.
For the transformation to achieve a positive outcome, where product and engineering are empowered by the rest of the organization to make the calls on what to build, you need to foster trust and create transparency.
Trust from the rest of the organization is connected to competence. If you’re a product leader deciding the biggest bets for the product, and as a result, the company, the stakeholders surrounding you need to view you as the best person for the job to make the right decisions on what to build next.
And making sound decisions comes from:
Being exposed to your customers and learning about their needs (not wants)
Reviewing analytics to understand end-users’ and customers’ behaviors
Understanding where the market is moving and how the technology landscape is changing
Connecting and having relationships with stakeholders to gauge where opportunities lie
And many other aspects
That’s why being a product leader is such a hard but rewarding job.
If the CEO gives their blessing to move towards the product model, it needs to be made explicit that the heads of product and tech are now in the driver’s seat. It also needs to be explicit that the heads of product and tech need to earn the other business functions’ trust by engaging in dialogue and debate about the product strategy and progress toward its objectives. Involving stakeholders in the prioritization of projects or features will only lead to what I refer to as “the prioritization problem.”
What you could try
Now that we've explored the pitfall of focusing solely on the "product" while ignoring the larger organizational context, let's shift to practical steps you can take to build a more inclusive and holistic approach.
Launch a customer discovery program
Receive help from sales or customer service and launch a “customer discovery” program to recruit customers for research activities. Essentially, sales or customer service helps you curate a list of customers or end-users to talk to. This is a proven tactic to bridge the gap between the “business” and product.
Share and debate your product strategy
Host monthly or quarterly reviews with stakeholders outside of the product organization to review the product strategy. In these sessions, share progress you’ve made, and showcase bets for the forthcoming period. Invite debate and feedback.
Learn more: “How to Run A Quarterly Product Strategy Meeting” by Gibson Biddle
Invite the business to demos
To further increase transparency, invite stakeholders to your weekly or bi-weekly demos where teams share progress in learning (discovery) and experiments they’ve launched (delivery).
Involve stakeholders in high stakes discovery work, run a Design Sprint
Every now and then, there’s one item on the roadmap that you can’t debate. It’s an opportunity that’s been surfaced by the business for a long time. It just needs to be done. It’s near and dear to many stakeholders. In such a situation, you need to work closely with the business. You can’t leave them out of the equation, you need to co-create the solution. A great technique to facilitate such collaboration is a Design Sprint—a one-week sprint where you shape the solution together, and by the end validate multiple prototypes with end-users and customers.
Key takeaways
The truth is that your transformation will likely fail if you treat product and tech as a bubble. To succeed, you need to be inclusive, build trust, and collaborate with the business. You also need to make it explicit how product development will be different moving forward—and for the better.
As you progress in the transformation, dial up transparency and share progress. Invite stakeholders for debate and discussion. Pick their brains—because, you know what, they might have insights and puzzle pieces that you are missing that could take your product to new heights.
What’s next
Next up, we’re going to dive into the importance of balancing “innovation,” “business as usual,” and “keeping the lights on” work to ensure success when moving to the product model.