When Building Becomes Cheap, Learning Becomes the Advantage

Knowing what to build has always been core to the value of product management. The rapid acceleration of building, enabled by AI, is putting a premium on product teams that know what to build. And the path to knowing is learning.

For most of my career in product, building was expensive.

A prototype might take weeks. A production-quality feature might take months. Engineering capacity was scarce, so one of the most important jobs of a product team was deciding where to spend it.

AI is rapidly changing that equation.

Things that once took weeks to build can sometimes be created in hours. Working prototypes can emerge almost as quickly as low-fidelity prototypes once did. Engineering itself is becoming faster. So are design, analysis, research synthesis, documentation, and many of the other activities surrounding product development.

That sounds like an enormous advantage for product teams.

It is.

But it also creates a dangerous illusion.

The ability to build faster does not mean we know what is worth building.

In fact, as the cost of creating things approaches zero, I believe the ability to determine what should be created becomes increasingly valuable.

The bottleneck is moving.

For exceptional product teams, the scarce resource isn't going to be the ability to produce. It's going to be the ability to learn.

All innovation is gated by the speed of learning

I've come to believe that learning is the central mechanism of a great product organization.

The job of product is to find the intersection between customer value and business value—and then stay there as customers, competitors, technology, and markets change.

You don't find that intersection in a conference room.

You learn your way into it.

You learn who has a problem worth solving. You learn how painful that problem actually is. You learn whether your proposed solution addresses it. You learn whether people will use it, whether they'll pay for it, whether you can build it, whether the economics work, whether the experience delights them, and whether any of those things change over time.

Then you act on what you learned and start the cycle again.

Learn. Act. Repeat.

That's why I think product teams should pay at least as much attention to learning velocity as they do to delivery velocity.

Shipping faster is valuable if you're learning from what you ship.

Shipping the wrong thing twice as fast isn't progress.

The best teams I've worked with constantly pushed themselves to learn faster. They looked for ways to reduce the time, money, fidelity, and effort necessary to get a credible signal. They didn't equate rigor with slowness.

The question wasn't:

How quickly can we build this?

It was:

What's the fastest credible way to learn what we need to know?

That's an increasingly important distinction in the age of AI.

AI changes the WHAT much more than the WHY

One way I've been thinking about AI's impact on product management is to separate the purpose of the discipline from the mechanisms and artifacts we've historically used to practice it.

The WHY of product management is remarkably durable: find the intersection of customer value and business value.

The HOW is learning, sensemaking, judgment, and decision-making. AI can dramatically accelerate parts of that process, but it can also degrade it. AI can synthesize enormous amounts of information while also introducing hallucinations, false confidence, shallow understanding, and conclusions that are difficult to explain.

Then there's the WHAT: the artifacts, analyses, specifications, prototypes, presentations, tickets, documents, decisions, and interventions product people create.

That's where AI is causing enormous disruption.

Much of the WHAT is becoming dramatically faster and cheaper to produce.

That's why I don't believe the core of product management is going away. Quite the opposite. The parts of the job closest to artifact production may be automated or accelerated, while the ability to learn, make sense of what you've learned, exercise judgment, and choose wisely becomes more important.

We're approaching a world where creating things is cheap, but knowing what is worth creating is incredibly valuable.

So what should product teams get exceptionally good at learning?

I've found it helpful to separate product learning into four categories:

• Hygiene: Knowing your customers and your market.
• Discovery: Identifying problems and opportunities and seeking value.
• De-risking: Removing risk around feasibility, viability, usability, scalability, trust, safety, compliance, and other critical assumptions.
• Optimization: Improving things that already exist—funnels, pricing, personalization, engagement, retention, and other outcomes.

Most mature product organizations do all four.

Very few are excellent at all four.

Hygiene: staying close enough to reality

Think about hygiene learning the same way you think about brushing your teeth.

You don't brush your teeth because you have a specific hypothesis about one tooth. You do it because it's an ongoing practice required to stay healthy.

Customer learning should work the same way.

Product teams should have predictable, low-friction ways to interact with customers and observe what is happening in their markets. For many teams, I'd expect direct customer interaction at least weekly.

These conversations don't always need an elaborate research plan. Their purpose is to build accumulated understanding: what customers are trying to accomplish, where they're struggling, how their environment is changing, what language they use, and what alternatives they're considering.

Over time, this creates something extremely valuable: intuition grounded in repeated exposure to reality.

The obstacle is often surprisingly mundane: friction.

At Ancestry, we built the ability to intercept customers at relevant points in the product and ask whether they'd be willing to immediately spend time with someone on the product team in exchange for a gift card. Because of the volume of customers, it rarely took long to find someone willing to participate.

At Lucid, one of our UX leaders created a system we called SQRL—Scaled Qualitative Research and Learning. A member of the product or UX team could identify an opening on their calendar, and the system would recruit a customer and book the conversation.

That system eventually enabled thousands of customer conversations.

The insight wasn't that every company needs SQRL.

The insight was that leaders should systematically remove friction between product teams and reality.

If talking to a customer requires three weeks, four approvals, and coordination across sales, customer success, research, product, and legal, you're going to learn slowly.

That's a leadership problem.

Discovery: try to prove yourself wrong

Discovery gets substantially more attention in product circles, so I won't attempt to recreate the many excellent methodologies that already exist.

At its core, discovery is about finding problems and unmet needs and identifying potential ways to create value.

• Who is the customer?
• What are they trying to accomplish?
• What problems or unmet needs exist?
• How valuable would solving them be?
• What potential solutions might create that value?

The mistake I see teams make is subtle: they conduct discovery to prove themselves right.

They've already fallen in love with a problem or solution, and research becomes a mechanism for validating the decision they've essentially already made.

That's dangerous.

I prefer the opposite posture.

Try to prove your hypothesis wrong.

If you think you've found an important problem, aggressively search for evidence that it isn't important. If you think customers will pay for something, look for evidence that they won't. If you love a proposed solution, look for where it fails.

Think of it as the inverse of the U.S. justice system.

Every product hypothesis is guilty until proven innocent.

The objective of learning isn't to validate our ideas.

It's to improve our decisions.

Those are not the same thing.

De-risking: what would need to be true?

This is probably the most underdeveloped learning competency I see on product teams.

The simplest question I've found for de-risking is:

What would need to be true for this to work?

Make the list.

Some of those assumptions are dealbreakers. If they're false, you don't have a viable opportunity.

Others are path-dependent. If they're false, you'll need to change course, but there may still be a viable path.

The goal is to identify the highest-risk assumptions and find the cheapest, fastest credible way to test them.

I once worked with a product manager at Vivint Smart Home who wanted to explore a feature that would allow someone to walk up to their front door and say something like, "Vivint, unlock the door."

The system would recognize the person through voice and facial recognition and unlock the door automatically.

The proposed de-risking plan was fairly reasonable by normal product-development standards: four engineers, a UX designer, and a product manager would spend roughly six weeks building a functional prototype. We'd spend several thousand dollars on hardware and then conduct customer testing.

My challenge to the product manager was different:

Figure out how to test this this afternoon without buying hardware or writing code.

We happened to have a model home inside the R&D floor with a smart lock and doorbell camera.

So the UX designer brought participants to the door and asked them to unlock it using their voice.

A product manager stood on the other side of the door and manually unlocked it.

The participants believed they were interacting with a functioning prototype.

Then the team started changing the response time.

They discovered something extremely useful: after about two seconds, people began feeling anxious.

That mattered enormously for a company whose brand promise revolved around peace of mind.

The team learned the thing that mattered without spending six weeks building the technology.

Today, ironically, AI might allow that same team to create a functioning prototype in an afternoon.

Great.

But the principle doesn't change.

Don't build something simply because building it has become cheap. Find the fastest credible way to learn what you need to know.

That's the discipline.

One way I teach teams to do this is to force themselves to consider multiple time horizons.

If you think an assumption requires a quarter to de-risk, ask what you could learn in a month.

Then ask what you could learn in two weeks.

A week.

A day.

Maybe the one-day approach isn't sufficient. That's fine.

The exercise forces you to confront an important question: How much confidence do we actually need before taking the next step?

Early in the life of an idea, invest enough to learn.

As confidence grows, increase the investment.

As evidence weakens the thesis, pivot or stop.

Optimization: shortening the distance between action and evidence

Optimization is another type of product learning, but it has a different intent.

Here we're generally not asking, "Should this product exist?"

We're asking, "How can we make something that already exists perform better?"

That might mean acquisition, activation, engagement, retention, pricing, monetization, personalization, or another measurable behavior.

Because optimization tends to rely heavily on experiments and statistics, one of its biggest constraints is often the time required to get a trustworthy signal.

I saw this firsthand at Ancestry.

One important measure of retention was whether a customer who started with a free trial would ultimately pay again after completing their first paid subscription period.

It was a good measure.

It was also painfully slow.

It could take roughly two months for an experiment to acquire enough customers and mature far enough for us to know the answer. Because of the number of customers required, we were reluctant to run too many large tests concurrently.

In a perfect world, we could learn perhaps six things a year.

So we worked with the analytics team to find an earlier signal that was sufficiently predictive of later retention.

We discovered that day-one trial cancellations were predictive of what would ultimately happen at renewal.

That changed everything.

Instead of waiting months for a test to mature, we could begin getting useful signals almost immediately. We went from the ability to run roughly six of these tests a year to around 300.

And importantly, the increased rate of learning helped unlock substantial improvements in retention.

We hadn't suddenly unlocked the ability to become 50 times smarter.

We had dramatically shortened the distance between action and evidence.

That's what learning velocity can do.

Measure learning, not learning activity

If learning really is the core mechanism of a product team, leaders should pay attention to the rate of learning.

But be careful what you measure.

Counting customer interviews isn't necessarily measuring learning.

Counting experiments isn't measuring learning.

Counting discovery sessions isn't measuring learning.

Those are activities.

I'm much more interested in questions like:

How many meaningful hypotheses did we prove or disprove?

How many important assumptions did we de-risk?

How many investment decisions changed because of new evidence?

How long does it take us to move from a critical question to a credible answer?

How frequently are we changing our understanding of the customer, market, or opportunity because of new evidence?

There will always be qualitative dimensions to this. I wouldn't turn learning into some giant bureaucratic scorecard.

The purpose isn't measurement theater.

The purpose is to make the organization aware of the speed and quality with which it converts uncertainty into understanding.

And then get better at it.

Learning speed is ultimately a cultural choice

Excellent teams don't occasionally run experiments.

They develop a culture that is obsessed with learning.

They celebrate someone who finds a clever way to learn in an afternoon instead of six weeks.

They reward the product manager who kills an idea after disproving a critical assumption rather than punishing them for "failure."

They make customer access easy.

They create systems that preserve what has been learned so the organization doesn't repeatedly rediscover the same thing.

They encourage small-batch learning instead of waiting for enormous launches to answer dozens of questions at once.

They develop leaders who instinctively ask, "How could we learn this faster?"

And they understand that speed is not recklessness.

Fast learning does not mean accepting bad evidence.

It means being deliberate about the amount of certainty required to make the next decision.

That distinction matters.

AI makes this more important, not less

One of my concerns about AI is that for many product organizations, it may accelerate building faster than it accelerates learning.

That could produce a strange outcome.

We might dramatically increase the amount of software we create without improving the quality of the decisions that determine what should be created.

More features.

More experiments.

More artifacts.

More code.

More activity.

But not necessarily more value.

The opportunity is to apply AI just as aggressively to the learning side of the equation.

Use it to prototype faster.

Use it to identify patterns across customer interactions.

Use it to explore alternatives.

Use it to make experimentation cheaper.

Use it to surface contradictions and generate better questions.

Use it to compress the distance between an idea and the evidence required to evaluate it.

But don't outsource learning to AI.

There is a difference between having information and developing understanding. There is a difference between summarizing what customers said and building intuition about why they behave the way they do. And there is a difference between producing an answer and possessing the judgment to know whether that answer makes sense.

Those capabilities sit very close to the enduring value of product management.

As AI makes creation cheaper, I believe product managers that know how to learn fast will become more valuable.

For years we've talked about product teams becoming faster at delivery.

That's no longer ambitious enough.

Build teams that learn faster.

Because ultimately, the fastest-building product team doesn't win.

The fastest-learning product team does.

This article is adapted from Leading Product Excellence, my forthcoming book about building exceptional product leaders, teams, and lives.