What Product-Led Actually Means

Product-led has become one of those terms that nearly every technology company uses and almost everyone seems to define differently.

I've worked in organizations that described themselves as product-led because they had Product Managers. Others because Product owned the roadmap. Some because they practiced Agile, conducted discovery, or had empowered teams. None of those things, by themselves, make an organization product-led. To me, the clearest test is whether I can trace a line through the organization:

Business goals → customer problems → product strategy → what gets built → measurable outcomes

Each decision should have some relationship to the one before it. When that chain breaks, product teams can be extremely busy without actually creating much value. Melissa Perri (my Product hero) describes a version of this problem in Escaping the Build Trap. Organizations fall into the "build trap" when they begin measuring success through outputs rather than outcomes: features shipped, projects completed, roadmap commitments delivered. The machinery of product development may be working beautifully while the organization loses sight of whether any of that activity is producing value for customers or the business.

I've seen how easy that is to do. Launching something is visible. Learning isn't always visible. A completed feature is easy to put on a slide or demo to a client. A team spending two weeks discovering that the feature shouldn't be built can look like a team that accomplished nothing. Yet that second team may have created far more value.

Start with something worth accomplishing

Product strategy becomes very difficult when the business hasn't clearly articulated what it is trying to accomplish. "Increase engagement" isn't particularly useful if nobody has defined what kind of engagement matters, for whom, why it matters to the business, how much it needs to change, or over what period of time. The same applies to goals like "use AI," "improve the member experience," "modernize the platform," or "increase personalization." These may represent worthwhile areas of investment to “the business” or “leadership”, but don't tell a product team what outcome it is responsible for creating.

The business needs measurable objectives. Product can then identify the customer behaviors, problems, opportunities, and product outcomes capable of contributing to them. This is one reason Perri's distinction between outcomes and outputs matters so much. In Escaping the Build Trap, she connects product strategy to company vision and economic outcomes, then connects product work back to that strategy. Without that connection, prioritization becomes subjective. We’ve all seen a version of this. The loudest stakeholder wins. The biggest customer gets the feature. A competitor launches something and suddenly we need one too. An executive sees an impressive demo at a conference and suddenly it appears on the roadmap (oh, and it get’s launched this product increment, too, by the way).

There is no durable basis for saying yes, because there is no durable basis for saying no.

Strategy tells us where to look

A roadmap isn't a product strategy. Perri has written about this distinction explicitly: companies often describe a list of capabilities they intend to build as their "strategy." The problem is that a plan assumes considerably more certainty than product development actually gives us. Marty Cagan approaches the issue from a similar direction. He describes product strategy as the mechanism for deciding which problems teams should solve, with empowered teams then given the space to determine how to solve them.

A useful strategy constrains the problem space. It tells teams where the organization believes meaningful opportunities exist and gives them enough context to make decisions consistent with the direction of the business. The roadmap should then reflect that strategy. If the strategy says one thing while the majority of product capacity is going somewhere else, the roadmap is telling you what the organization's actual strategy is.

Fall in love with the problem. Then interrogate it.

This may be the part of product work I care about most. Before discussing solutions, I want to understand the problem.

Is this actually a problem? How do we know? Who experiences it? How many people experience it? How frequently?How severe is it? What are they doing today instead? What does the problem cost the customer? What does it cost the business? What would change if we solved it? What happens if we don't?

This becomes especially important when a technology is looking for a use case. AI is the obvious contemporary example. The pressure to "have an AI strategy" can quickly become pressure to put AI somewhere in the product. A few years from now, another technology will occupy that position (maybe). Technology can expand the solution space dramatically. It doesn't eliminate the need to establish that there is a worthwhile problem on the other side. Perri's original description of the Build Trap makes essentially this warning: teams jump into building with assumptions about what customers want before they have enough evidence that the proposed product will actually solve the problem.

The discipline is surprisingly simple: Problem first. Evidence second. Solution third.

And remain willing to discover that the problem isn't actually worth solving.

Product is a team sport

There is a persistent caricature of the Product Manager as the person who decides what gets built. The best product work I've done hasn't looked anything like that. Product brings context about the customer, market, business, strategy, and desired outcomes. Design brings deep understanding of users, interaction, and usability. Engineering understands the technical system, constraints, possibilities, and feasibility in ways Product never will. Data teams help distinguish intuition from evidence. Domain experts, like a clinical team, understand realities, constraints, considerations, or risks that may be invisible to everyone else. The customers and users understand their own lives better than any of us do.

The work gets considerably better when those perspectives meet early, while the problem and solution are still malleable. Cagan's product discovery framework is useful here because he separates four risks that need to be addressed: value, usability, feasibility, and viability. Will customers choose it? Can they use it? Can we build it? Does it work for the business?

No single function is best equipped to answer all four. That's why collaboration shouldn't mean Product writes requirements, Design makes screens, Engineering estimates them, and everyone meets again at sprint planning. Collaboration means solving the problem together.

Treat solutions as hypotheses

Eventually, you have to decide what you think will work. The important phrase there is think will work. A solution is a hypothesis until customers prove otherwise. The is why before committing months of engineering capacity, I want to know what assumption we're making and what evidence would increase or decrease our confidence in it.

This can be done in several different ways. Sometimes that means customer interviews, a prototype, a concierge test, technical spike, fake door, usability study, experiment, or limited pilot. The method matters less than the question: What's the cheapest reasonable way to learn whether we're right? This is also where product organizations need psychological permission to learn that they're wrong. Early in my career, I was told “If you’re not failing, you’re not really a Product Manager.” Discovery that invalidates an idea has produced information. And honestly, invalidation is the best kind of information because that’s an investment saved for something that may actually have a better chance of being successful! However, if the organization treats that result as failure, teams quickly learn to perform discovery designed to validate decisions that have already been made. Then discovery becomes theater and everything released has the same level of confidence that we have a right to win (or not).

Decide what success means before you build

One of the simplest product disciplines is also one of the easiest to skip: Before building something, write down what you expect to happen if it works. The metric will vary enormously depending on the problem, but every problem should have “success metrics.” Success metrics may look like conversation rates, decreased call volume, more efficient workflows, increased completion rates, decreased error rates. It should always be something you measure. And it should be something like “the feature launched.” The outcome may not be visible for months and you need leading indicators along the way. You should identify what those may be ahead of time, too.

There isn't a universal product metric. There should always be an explicit definition of success. This changes the conversation before development begins. Teams have to explain the mechanism through which the proposed solution is expected to create value. We believe that doing X for Y users will change Z behavior, which contributes to this customer or business outcome.

Now we have something testable.

Data should have more authority than hierarchy

Product decisions rarely happen in environments free of opinion. Executives will have opinions on what gets invested in. Customers have opinions on what they want to see or have happen. Sales has opinions on what’s going to make the business the most closed deals. Engineering has opinions on what should be done the most technically feasible way. Product has opinions. I certainly have opinions. But, opinions don’t really matter.

The goal isn't to eliminate judgment. Product requires judgment, particularly when evidence is incomplete. Cagan explicitly argues that judgment is fundamental to discovery because teams must continually assess different types and levels of risk. The discipline is knowing the difference between an opinion and evidence. When evidence becomes available, it should be capable of changing the decision regardless of who originally advocated for it.

That's one of the cultural tests I use for product-led organizations: Can the organization change its mind? Can a team stop an executive-sponsored initiative because discovery shows customers don't value it? Can a PM abandon her own idea when the experiment fails? Can Engineering surface feasibility information that changes the solution? Can research overturn something everyone had assumed was true?

Empowered teams aren't especially useful if the acceptable answer has already been determined.

Launch is when the evidence gets better

Product organizations understandably put enormous energy into launches. There are deadlines, release plans, enablement, communications, demos and celebrations. The feature goes live. And then attention shifts to the next thing. This may be one of the strangest habits in software development because launch is the moment when we finally get access to some of the best evidence we've had.

Real users.

Real behavior.

Real constraints.

Real consequences.

The questions we asked before launch become much easier to answer: Are people using it? Are the right people using it? Are they getting the value we expected? Did the behavior we wanted actually change? Did the business outcome move? What are users telling us? What aren't they doing that we expected them to do? Did we create unintended consequences? Should we iterate, expand, reposition, or stop investing?

A product-led organization has to care as much about those questions as it cared about getting the thing shipped.

Product-led is an operating model

This is ultimately why I think the term product-led gets misunderstood. It describes more than the behavior of a Product team. The organization has to create the conditions that allow this way of working. Leadership needs to establish meaningful business objectives. Strategy needs to translate those objectives into areas of opportunity. Teams need access to customers and data. Product, Design, Engineering, Data, and domain experts need to work together. Teams need room to discover solutions rather than simply receive them. Success needs to be measured through outcomes. And leadership needs to tolerate the uncertainty inherent in learning.

That creates the through-line:

Business goals → customer problems → product strategy → what gets built → measurable outcomes

And then the arrow loops back around.

The outcomes become evidence. The evidence changes our understanding of the customer. That understanding changes our strategy. And the next decision should be better informed than the last one. That's what product-led means to me. An organization built around problems, evidence, outcomes, learning, and accountability, with a clear connection between what the business needs to accomplish and what teams choose to build. t's also the kind of product organization I want to help build.

I ask a lot of questions. I want the data. I challenge assumptions, including my own. I want to understand the problem before becoming attached to a solution. I bring the people who understand different parts of that problem into the room. And when the evidence tells us we were wrong? Good. Now we know something we didn't know before. The question is what we do with it.

Notes & References

1. Melissa Perri, Escaping the Build Trap: How Effective Product Management Creates Real Value (O’Reilly Media, 2018). Perri describes the “build trap” as the organizational tendency to focus on shipping features and other outputs rather than producing meaningful customer and business outcomes.

2. Melissa Perri, “What Is Good Product Strategy?” Melissa Perri, July 14, 2016. Perri distinguishes product strategy from a plan or list of features, arguing that strategy provides a framework for making product decisions in pursuit of organizational goals.

3. Marty Cagan, “Product Strategy Overview,” Silicon Valley Product Group. Cagan describes product strategy as the process of identifying the most important problems for product teams to solve in service of business objectives.

4. Melissa Perri, “The Build Trap,” Melissa Perri, August 5, 2014. Perri argues that organizations frequently move into building solutions based on assumptions about customer needs before sufficiently validating the underlying problem and proposed solution.

5. Marty Cagan, “The Four Big Risks,” Silicon Valley Product Group. Cagan identifies four fundamental risks addressed through product discovery: value risk, usability risk, feasibility risk, and business viability risk.

6. Marty Cagan, “Discovery — Judgment,” Silicon Valley Product Group. Cagan emphasizes the role of judgment in product discovery, particularly when teams must evaluate risk and make decisions with incomplete information.

Further Reading

Perri, Melissa. Escaping the Build Trap: How Effective Product Management Creates Real Value. O’Reilly Media, 2018.

Cagan, Marty. Inspired: How to Create Tech Products Customers Love. 2nd ed. Wiley, 2017.