When Building Gets Easier, Deciding What to Build Gets Harder

AI is changing how quickly product teams can move. We can generate concepts faster. Prototype faster. Write requirements faster. Analyze research faster. And increasingly, engineering teams can build faster.

That's exciting. But there's a tension I've been thinking about lately: When it becomes easier to build things, it becomes even more important to decide whether we should build them at all.

For years, one of the natural constraints on product development was capacity. Ideas competed for limited design and engineering resources. That wasn't always a great prioritization system, but it forced choices.

AI is beginning to loosen that constraint. And that shifts the problem.

Speed Doesn't Create Clarity

If a team can build twice as fast, it doesn't necessarily mean it should build twice as much.

Without clarity, increased velocity can simply produce more features, more complexity, more inconsistency, and ultimately more cognitive load for customers.

The question changes from: Can we build this? to: Is this the right problem to solve?

That's a much more interesting question. And increasingly, I think it's where Product, Design, Research, and Engineering create some of their greatest value.

Product Discovery Becomes More Important, Not Less

When the cost of producing a solution goes down, it's tempting to skip discovery. If we can prototype or build something quickly, why spend time understanding the problem first?

Because faster execution doesn't reduce the cost of solving the wrong problem. It may simply allow us to create the wrong thing more efficiently.

Good product discovery doesn't need to mean months of research before a team moves. It means creating enough shared understanding and evidence to make a responsible decision: Who has this problem? How important is it? What are they trying to accomplish? What do we already know? What assumptions are we making? What's the smallest useful way to learn whether we're right?

AI can accelerate parts of that work. It shouldn't eliminate the thinking behind it.

Start With the Job, Not the Feature

One way I've been thinking about this is through Jobs to Be Done.

Instead of starting with a backlog of features, start by asking: What is the customer actually trying to accomplish?

Then dig deeper. Where are they struggling today? Which jobs are critical versus simply helpful? Are those jobs different for a small customer versus an enterprise customer? What happens if we don't solve this problem? And perhaps most importantly: Does solving this meaningfully improve the customer's ability to get their job done?

That framing creates a very different conversation than 'What should we add next?' It moves the team away from output and toward outcomes.

Evidence Should Increase With the Investment

Not every decision needs the same amount of research or validation. A small, reversible change doesn't need the same evidence as a foundational platform decision or a workflow that will affect thousands of customers.

I like to think about discovery proportionally: the greater the investment, uncertainty, customer impact, or difficulty of reversing the decision, the stronger the evidence should be.

That evidence might come from behavioral analytics, customer interviews, usability testing, support data, market signals, prototypes, experiments, or existing product metrics. The goal isn't research for research's sake. It's reducing the uncertainty that matters before making a larger commitment.

Not Every Problem Deserves Equal Investment

Customer-centered doesn't mean saying yes to every customer request. In fact, good product leadership often requires doing the opposite.

We need to understand the difference between an inconvenience and a meaningful barrier. A feature that delights one customer might add unnecessary complexity for thousands of others. A workflow that works beautifully for a customer managing 50 items might completely break down for someone managing 5,000.

Context matters. Scale matters. Frequency matters. And impact matters.

That's why prioritization can't simply be a list of requested features. We need to understand the underlying jobs, pain points, customer segments, business impact, evidence, and level of investment required. Only then can we make thoughtful tradeoffs.

Use AI to Increase Learning, Not Just Output

One of the biggest opportunities I see is using the speed AI gives us to shorten the distance between an assumption and evidence.

If teams can create prototypes faster, analyze feedback faster, explore alternatives faster, and identify behavioral patterns faster, we can potentially learn more before making a large investment.

That's different from simply filling the backlog faster.

The goal should be a tighter learning loop: understand the problem, form a hypothesis, create the smallest useful test, learn from what happens, and use that evidence to decide what deserves more investment.

AI Raises the Value of Judgment

There's a lot of conversation about which skills AI will replace. I'm increasingly interested in the opposite question: Which skills become more valuable because of AI?

Judgment is high on my list. So are curiosity, systems thinking, customer empathy, strategic thinking, and the ability to connect seemingly unrelated signals.

• AI can help us explore hundreds of possible solutions. Human judgment helps us determine which problems are worth solving.

• AI can help us analyze enormous amounts of customer feedback. Human curiosity helps us recognize the question we haven't asked yet.

• AI can help us prototype and build faster. Validation helps us learn whether the idea actually improves the customer outcome.

• AI can increase our capacity. Leadership helps ensure we're investing that capacity in the right direction.

A Better Question Before You Build

As the cost of building continues to fall, I think teams need a stronger decision habit before work gets pulled into delivery.

Before asking how quickly something can be built, ask:

• What Job to Be Done or customer outcome are we trying to improve?

• What evidence tells us this problem is meaningful?

• Who experiences it, how frequently, and at what scale?

• What assumptions would make this investment fail if they're wrong?

• What is the smallest useful way to validate those assumptions?

• How will we measure whether the solution actually improved the outcome?

• What complexity are we adding to the product—and is the value worth it?

The Goal Isn't More. It's Better.

For product organizations, I think this may be one of the most important mindset shifts of the AI era.

Our measure of success can't simply become increased velocity. The opportunity is much bigger than that.

We can use the capacity AI gives us to spend more time understanding customers, exploring problems, testing assumptions, connecting insights across the organization, and making better decisions.

Because ultimately, customers don't care how quickly we filled our backlog. They care whether the product helps them accomplish something that matters.

As building becomes easier, deciding what deserves to be built may become one of the most important skills we have.