Discipline In Product: Know How To Identify Problems and Ship Solutions

Jessica Scandaliato
Bain Public
Published in
6 min readSep 17, 2021

Today’s most valuable companies, like Facebook, Amazon, Netflix and Google, are product-led and customer-driven. They owe their success to a unified product vision that is informed by feedback from customers, prospects, and colleagues. These companies ship products that satisfy REAL customer needs that are built on REAL data inputs and feedback, NOT opinions or assumptions.

This is very different from a project-led approach, which is primarily based on the outputs — which is the actual product being built. A project-focused approach is often more expensive and less successful. Product-led approaches, however, involve identifying and solving the problems iteratively through a build, measure, learn loop, and figuring out which priorities should be the next priority.

That is the hardest part of working in a product job — figuring out what are the most important jobs to be done and how to prioritize them. Determining what the right roadmap priorities are is a rigorous process, where strategic choices and decisions occur in group decisions where the consensus is challenged. The solutions to these problems are articulated through the underlying rationale and evidence that product managers collect during their incredible amount of behind-the-scenes discipline; the solutions are then judged by placing feature OKRs to business metrics that matter.

In this article, we will teach you (the product leader) how to identify the problems during the developmental stage and how to provide proper solutions to those problems.

Creating discipline in product jobs will allow you to make better decisions!

Those same top-performing product organizations are also the ones that have successfully replaced reactive decision-making with a coherent strategy for achieving their product vision.

“Teams that have a clear product vision, strategy, and objectives are 55% more likely to believe that product innovation drives revenue at their companies.” — Paul Ortchanian, CEO & Founder of Bain Public

Here are some things you need to know to create disciple in your product job:

  • Deeply understand, refine, and articulate your product strategy and revenue growth model years before going IPO or your exit.
  • Be incredibly rigorous in how you approach building products. Creating very high-quality products takes an incredible amount of behind-the-scenes discipline, especially as your team grows.
  • Make sure that discipline always remains front and center by first identifying and then obsessively focusing on the 2–3 most important qualities of your product.
  • Ensure your product strategy accounts not just for how you’ll expand your current business, but also how you’ll compete in new markets as well. It also needs to tie very clearly to your go-to-market playbook, so that your growth becomes predictable. That’s what the public markets really value — and that’s how you can learn where the levers are in your business. It’s not enough just to have a business model; you actually need to be able to predict and forecast that business.
  • Learn to consolidate customer insights and identify trends to prioritize the right products and features based on what’s most important to the business.
  • Make sure your product leaders are making decisions around what to focus on and what not to focus on. Deciding what you think is a high-ROI bet versus what you think is a low-ROI bet is ultimately the most impactful thing you can do because it’s the thing we have the most control over.
  • Finally, understand that speed is important when it comes to identifying a problem to solve if you actually want to ship a solution. The WHY of it all creates momentum; if you forget the WHY and, for example, use meetings to throw more scope while disregarding the WHY (the problems and opportunities), then you’re just wasting time and money. Make sure you are keeping up to speed on things. For example, every week, you can put new product mockups in front of team members and a committee of senior leaders to inspect every proposed enhancement.

Strategy isn’t some mystical concept; it’s a simple set of key choices that reinforce against the metrics that matter.

Ultimately, the measure of your success is determined by your understanding of whether you’re helping or hurting the service. This can be assessed by answering the following questions:

  • What are our customers trying to hire us for?
  • Are you solving customer problems?
  • Specific metrics tell you whether you’re helping or hurting customer problems in specific dimensions. How do we build product solutions that have those dimensions in mind?

Product metrics should reflect how the team creates value for the business and therefore should primarily be judged by business metrics. Basically, ask yourself: how much impact are we having against the metrics that matter most?

Strategic choices and decisions happen in group discussions and team meetings.

More and more firms are adding the role of Chief Product Officer to the executive team, even for non-digital-only companies. Both the engineering and product teams need a seat at the top table to increase the product’s impact through sufficient strategic context and outcome-based cultural alignment, investment, accountability and evaluation.

Product vision and strategy lie at the heart of every great team! Discussing the roadmap strategy as a group is needed in order to raise the overall knowledge level of the entire team. Different people bring different perspectives — and that’s the value!

However, don’t let your product team fall into the trap of talking about consensus all the time. Don’t hesitate to push your leadership team for diverging opinions, deltas and biases on the strategic context, the results and approaches that drive success in your organization. This is where a product manager’s time should be spent — with the leadership team, not in the hyper-certified space of consensus!

To make a good decision, you need to identify stakeholders who are well informed and have a completely different opinion than yours (or that of the group consensus).

During team meetings, 80% of the time should be spent talking about the grenades, diverging opinions, deltas and biases; NOT the consensus. Because strategic choices were made based on a consensus, it’s almost like the decision is hyper-certified. Once a consensus starts to form, it generates its own momentum (which is bad). Much evidence shows the decision coming out of these group processes is pretty bad.

Naive Realism is defined as: we think something because we believe in something, and there’s a consensus among other people with that same understanding. Oftentimes, people don’t realize that when they are discussing a problem or its solution, they’re not actually talking about the same thing. This has to do with their language and huge variations in what words mean.

If you’re not defining the terms of a given situation with concrete facts, rather than summary-level adjectives, you get a fundamental misalignment in how stakeholders understand a particular situation. For a product manager, the challenge is to get all those perspectives to collide constructively; you want to identify and explore the areas where there’s disagreement and divergence.

How? The answer is simple: asynchronous exploration! That is, asking for individual input before the group discussion starts. Once the roadmap meeting starts, the product manager can quickly move through the consensus and spend most of the time talking about the differences, which is where the good stuff comes up.

You want to spend most of the time exploring and understanding the differences in points of view. Asking more questions to ensure stakeholders are all rowing in the same direction.

You are human; humans make mistakes all the time. You might be wrong without realizing it. And if so, you’ll benefit from having a stakeholder correct you.

If you’re not wrong, then you’ll benefit from this by articulating your understanding of the product strategy — the underlying rationale and evidence that you collected through behind-the-scenes discipline in order to support it!

--

--