Product-Led Growth Starts Before the Product Is Built

October 15, 2026
product management
4 min read

What if the biggest mistake in Product-Led Growth happens before there is even a product to grow?

There is something particularly frustrating about building a product that doesn’t work out. Not because the technology failed, the team couldn’t execute, or the idea was particularly bad. But because somewhere between identifying a problem and building its solution, nobody established whether customers cared enough about that problem in the first place.

You can spend weeks refining an idea, debating features, building prototypes, and thinking through the user experience. You can do everything that looks like product development and still end up with something people don’t particularly want.

The strange thing is that the product might work perfectly well. It just doesn’t matter enough.

Product-Led Growth (PLG) is often associated with free trials, frictionless onboarding, self-service experiences, and viral adoption. These are important elements of a product-led approach, but I’ve increasingly come to think that the real foundation of PLG lies somewhere much earlier.

Before a product can drive its own growth, it must give customers a compelling reason to care.

In this article

Add a header to begin generating the table of contents

The Problem With a Good Idea

During my time at Product Labs, I encountered an experience that made me think more deeply about customer discovery. Insufficient discovery had contributed to a product idea not working as expected.

I wouldn’t reduce every unsuccessful product to one mistake. Products fail for many reasons, and hindsight has a convenient way of making complicated decisions look obvious. But the experience raises a question worth examining: How much of what we call product development is actually the development of an assumption?

Think about how a product idea usually begins. Someone notices an inefficiency, identifies a gap in an existing solution, or recognizes an opportunity to improve a particular workflow. A possible solution emerges, and the team begins discussing what it could look like. Features are proposed, prototypes take shape, and conversations gradually move toward implementation.

Somewhere along the way, the original question of whether customers need the solution can become secondary to the excitement of building it.

This is particularly common when teams have strong technical capabilities. When something can be built, the conversation naturally shifts toward how quickly and effectively it can be delivered. Yet technical feasibility tells us very little about whether customers will consider the resulting product valuable.

Three assumptions frequently get mixed together:

The problem exists. There is an identifiable inconvenience, inefficiency, or unmet need in the customer’s experience. However, identifying a problem does not establish how important it is.
The solution is useful. The proposed product can address that problem. But usefulness alone does not mean customers will prefer it over their existing alternatives.
Customers will adopt it. This is an entirely different assumption. Adoption requires customers to recognize sufficient value to justify changing their current behavior.

A team can be right about the first two assumptions and still be wrong about the third.

The uncomfortable reality is that building a solution successfully does not necessarily mean building a successful product.

Customers Can Like an Idea and Still Never Use It

Imagine asking ten potential customers whether they would appreciate a tool that saves them time. Most would probably say yes. After all, who wouldn’t want to save time?

Now ask how much time they currently lose, what they do about it, and what they would be willing to change to recover it. The answers might reveal something quite different.

Perhaps the problem occurs only once a month. Perhaps the existing workaround takes five minutes. Perhaps adopting the proposed solution requires learning a new tool, transferring data, or convincing several colleagues to change their processes.

Suddenly, the opportunity looks less compelling.

The problem exists, and the proposed solution could work. Customers might even describe it as useful. But none of that guarantees they will adopt it.

This is why customer discovery needs to go beyond collecting positive feedback. People can appreciate a product idea without having any intention of changing their behavior.

Consider the difference between asking a customer, “Would you use a tool that automates this process?” and asking, “Walk me through the last time you completed this process.”

The first question invites an opinion about a hypothetical future. The second reveals how the customer actually behaves today.

A useful discovery conversation should investigate several dimensions of the problem:

Frequency and intensity: How often does the problem occur, and how significantly does it affect the customer’s work or outcomes? A minor inconvenience experienced occasionally may not justify adopting another product.
Existing alternatives: How is the customer solving the problem today? Spreadsheets, manual processes, competing products, and informal workarounds can all reveal how customers currently manage the situation.
Consequences of inaction: What happens if the customer continues doing things the same way? If the answer is “not much,” the motivation to adopt a new solution may be limited.
Willingness to change: What improvement would make the customer reconsider their existing approach? Adoption involves more than recognizing value. It often requires overcoming habits, switching costs, and organizational resistance.

One distinction I find particularly important is that a product doesn’t compete only with other products. It competes with the customer’s willingness to do anything differently.

That is a much harder competition to win, and it is one that product teams need to understand before investing heavily in a solution.

So Where Does Product-Led Growth Actually Begin?

When people discuss Product-Led Growth, the conversation tends to move quickly toward the mechanics. Free trials, freemium models, activation rates, conversion funnels, and viral loops often dominate the discussion.

These mechanisms matter, but they are built on an assumption that deserves more attention: customers must experience enough value from the product to want to continue using it.

In a product-led model, the product itself plays a central role in customer acquisition, activation, retention, and expansion. Instead of relying entirely on sales or marketing to communicate value, customers can discover that value through direct interaction with the product.

However, this approach only works when the underlying customer need is sufficiently strong.

A free trial might encourage someone to explore a product, but it cannot create a need that wasn’t there. A seamless onboarding experience might help customers get started, but it cannot compensate for a product that solves an unimportant problem. A referral program might encourage users to invite colleagues, but those colleagues still need a reason to stay.

You can remove every obstacle between a customer and your product. You still need to give them a reason to cross the distance.

This is where customer discovery becomes directly connected to growth strategy.

Before designing an activation journey, teams need to understand what meaningful value looks like to the customer. Before optimizing retention, they need to understand whether the problem occurs frequently enough to encourage repeated usage. Before introducing referral mechanisms, they need to investigate whether the product creates value that naturally extends to other users.

In other words, many of the questions that shape a successful PLG strategy are customer discovery questions in disguise.

The Difference Between Being Used and Being Valuable

There is another distinction that deserves attention: usage is not necessarily value.

Someone can create an account, complete onboarding, explore several features, and never return. From a product analytics perspective, that journey might initially look promising. The customer signed up, interacted with the interface, and completed several important actions.

But what did they actually accomplish?

Consider a project management tool. A new user creates a workspace, adds tasks, invites a colleague, and experiments with the dashboard. These activities indicate engagement, but they do not necessarily demonstrate that the product has improved anything meaningful.

Now imagine the same user returning the following week because the tool helped their team avoid a missed deadline or coordinate work that previously required several meetings. The product has moved beyond being something the customer tried. It has become something the customer finds useful.

This distinction has important implications across the product-led growth journey.

Activation: What does the first meaningful outcome look like?

Activation should represent the point at which a customer experiences genuine value, rather than simply completing a sequence of onboarding steps.

For an analytics product, that might mean discovering an actionable insight. For an automation tool, it could mean eliminating a repetitive task. For a collaboration platform, it might involve completing a shared activity more effectively.

Customer discovery helps teams identify these moments before they design the experiences intended to deliver them.

Retention: Why would the customer come back?

A compelling first experience does not automatically create a lasting relationship. Customers return when a product continues solving a problem that matters to them.

Understanding the frequency, context, and consequences of a customer’s problem helps teams determine whether the product has the potential to become part of an ongoing workflow.

Expansion: Why would the value spread?

Not every useful product has an inherent viral growth loop. Some products create value primarily for individuals, while others become more valuable when colleagues, teams, or departments participate.

Discovery helps reveal how value is created and shared, allowing teams to identify realistic opportunities for expansion rather than assuming that referrals or collaboration features will automatically generate growth.

What connects these three stages is a simple idea: sustainable product-led growth depends on understanding what customers value, not merely measuring what they do.

The Faster We Build, the Easier It Becomes to Skip the Difficult Questions

There is an interesting contradiction in modern product development.

Building has become easier in many ways. AI can help generate prototypes, analyze research, draft requirements, and accelerate development. Ideas that once required significant time and resources can now be explored much more quickly.

This creates tremendous opportunities for experimentation. But it also makes it possible to move from an assumption to a working prototype before properly examining whether the assumption is valid.

And a working prototype can be remarkably persuasive. It gives the team something tangible to demonstrate, stakeholders something concrete to evaluate, and everyone involved a sense that progress is being made.

Meanwhile, the uncomfortable questions may remain unanswered. Does the customer experience this problem frequently enough? What are they doing about it today? What would make them switch? Would solving the problem actually improve an outcome they care about?

These questions are less exciting than watching a prototype come to life, but they are often more consequential.

I don’t think the answer is to slow down product development. Faster experimentation is an advantage, particularly when teams use it to learn rather than simply produce more features.

The distinction lies in what the team is trying to achieve. Building a prototype to test whether customers understand and value a proposed solution is very different from building one because the team has already accepted its assumptions as facts.

AI can strengthen customer discovery by helping teams synthesize interview findings, identify recurring themes, compare competing hypotheses, and explore possible solutions. But it cannot turn weak evidence into genuine customer demand.

The real advantage of building faster is not that teams can pursue more ideas. It is that they can test more assumptions before deciding which ideas deserve to be built.

What I Would Want to Know Before Building

If I were evaluating a new product opportunity, I would want to establish a few things before becoming too attached to the proposed solution.

Not because answering these questions guarantees success. It doesn’t. But because they help reveal the assumptions that enthusiasm can easily hide.

Is the problem important enough to change customer behavior?

The existence of a problem does not establish its priority. I would look for evidence that customers already invest time, effort, or money in addressing it. Strong workarounds, repeated frustration, or measurable business consequences can indicate that the problem deserves attention.

Who experiences the problem most intensely?

A broad target audience often hides significant differences in urgency. Identifying the customers who experience the strongest need can help teams design a more focused solution and establish where initial adoption is most likely.

What is the customer using instead?

Competition isn’t limited to products with similar features. A spreadsheet, a manual process, an internal tool, or even doing nothing can be the customer’s preferred alternative. Understanding these choices reveals what the proposed solution must improve upon.

How quickly can customers experience meaningful value?

I would want to understand the smallest useful outcome the product could deliver and what might prevent customers from reaching it. This is particularly important in PLG, where customers often evaluate the product through direct usage rather than extensive sales conversations.

Why would customers return or encourage others to adopt the product?

Initial usage can be driven by curiosity, marketing, or a compelling demonstration. Sustainable growth requires recurring value and, where relevant, a natural reason for that value to spread across users or teams.

These questions are not a replacement for experimentation. They help teams decide what to experiment with and what evidence should influence the next product decision.

Growth Cannot Rescue a Product That Doesn't Matter Enough

Product teams are understandably drawn to growth. Growth is visible, measurable, and relatively easy to communicate. An increase in sign-ups, active users, or conversion rates creates a reassuring sense that something is working.

Customer understanding is considerably messier.

It involves conversations that challenge assumptions, observations that contradict expectations, and occasionally discovering that an idea everyone was excited about isn’t particularly important to the people it was meant to serve.

Nobody enjoys that discovery, especially after investing time and effort in a solution. But learning early that a product doesn’t solve a sufficiently important problem is far less expensive than discovering it after launch.

This is perhaps the part of Product-Led Growth that deserves more discussion. The work isn’t only about finding ways to make products grow. It is about discovering whether the product has something worth growing in the first place.

A team can optimize onboarding, improve conversion funnels, experiment with pricing, and reduce friction across the entire customer journey. Those improvements matter when the underlying value is real. Without it, they risk becoming attempts to make an unconvincing proposition more convenient.

And convenience, on its own, is rarely enough.

Before the First User Signs Up

Product-Led Growth sounds like a strategy that begins when a product reaches the market. In reality, many of the decisions that determine its potential are made much earlier.

They are made when teams decide which customer problem deserves attention, challenge an attractive assumption, investigate existing behavior instead of collecting encouraging opinions, and choose to validate a need before becoming invested in a solution.

These decisions don’t always look like growth work. There are no dashboards to celebrate, no conversion rates to improve, and no impressive adoption numbers to share. Sometimes the outcome is simply deciding not to build something.

And that might be one of the most valuable product decisions a team makes.

My experience with Product Labs is one reason this subject interests me. It is a reminder that the questions we fail to ask at the beginning can become the problems we struggle to solve much later.

So before asking how to acquire the first thousand users, perhaps there is a more important question worth answering.

What have we learned about the first ten that makes us confident they would want to stay?

Because getting people to try a product is one challenge. Giving them a reason to care is another. And growth has a much better chance when the second comes first.

Institute of Product Leadership is Asia’s First Business School providing accredited degree programs and certification courses exclusively in Product Management, Strategy, and Leadership.

Explore Our Programs