Leaders shouldn't prescribe solutions. What should they do instead?
Execs in transition to the product model need something to grab on to.
One of the core ideas about becoming a strong product company is that execs and stakeholders should avoid prescribing solutions for the product team to build. And that instead, they ought to assign product team(s) customer or business problems to solve, and let the team come up with a solution that delights customers and works for the business.
But humans have a very hard time letting go of something without something else to grab on to instead.
So stakeholders transitioning to the product model quickly hit this question:
“So…if I can’t tell them what to build…what should I do? What’s my role in this thing?”
While there are many ways to answer that question, let’s start with this: stakeholders should:
Emphasize critical thinking—push the thinking of the product team to be as strong as it can be
Shift the conversation from binary thinking to shades of grey.
Insist on sufficient evidence, not proof. There is no proof until the product is live in the market. But through strong product discovery, we can develop sufficient evidence that the bet is worth it, or that we should kill it and move on to another idea.
Here’s my favorite way to do this in practice:
Instead of asking questions such as “are you sure?” or “have we validated [feature X]?”, ask these two questions instead:
“What’s your level of confidence? What’s that based on?” → are they a 3/10, or a 7/10? Look for sufficient evidence and critical thinking.
“How did you decide on [solution X]? Walk me through how you got there.” → Even if you aren’t an expert on the details, you can contribute to a better thinking process.
This tiny, easy change starts to instill two of the most important habits for building & scaling strong product culture: critical thinking and intellectual honesty.
The Daily ROI is a 2-min weekday newsletter to help tech leaders get better at the hard stuff: people, culture, tough calls, ambiguity, thinking.