Minimum Isn’t the Constraint Anymore: Better Questions for Building with AI

TL;DR

AI has made code cheap, which changes what MVP scope means and how teams stay on track. The discipline that used to come from limited build time now has to come from judgment, anchored to a shared hypothesis.

• The old MVP question is outdated. “Can we make this smaller?” made sense when build time was the constraint. In AI product development, building is fast, so the better question is what’s the least we need to build to learn what we need to learn.
• The bar for products is rising, and the bar for tests is falling. Users expect more from anything presented as a product, but a test only needs to check your riskiest assumption. Often a landing page or waitlist is enough.
• Feature creep moves faster with AI. Teams can iterate dozens of times a day, and each AI suggestion seems reasonable on its own, so builds drift from the problem they were meant to solve.
• Teams need a shared anchor. Write down the problem, what done looks like, and the hypothesis you’re testing. The product manager owns it, and everyone builds against it.
• Includes five questions to ask before saying yes to the next AI suggestion.
• When the build forks, compare each branch against the anchor, not against each other, and change the hypothesis on purpose if the evidence calls for it.

We recently set out to build an internal product for our professional development framework. We had a sponsor, a team, and a shared brief. Then everyone went off to build.

One person worked on the front end. Another prototyped in Claude. A third built a version on a real back-end architecture. When we got back together, nothing lined up. Our assumptions were different, and merging it all took a lot of rework.

Nobody was careless. Everyone was moving fast, and that was the problem. We could get far enough in a short time that three versions of the product drifted apart before anyone checked direction. Same starting point, same expectations (we thought), and the build still diverged faster than any of us expected.

My colleague, Lindsey Walker, sees a version of this on almost every internal project now. Fifteen minutes after kickoff, a developer says, “I have a prototype.” The code exists before anyone has agreed on what problem it solves or what done looks like.

MVP scope used to be a build-time problem

Whether we’re building for clients or for ourselves, MVP scope has always been a balancing act. Everyone wants one more feature, one more delighter, the thing that makes it stand out. And there’s always a baseline that has to exist before any of it works. So we taught our teams to keep asking: can we make this smaller and still deliver the same value?

That question came from a real constraint. Code was expensive. As Lindsey W puts it, a big part of a product manager’s job was being the gate between all the ideas in the world and what actually got built.

In AI product development, that constraint is gone. Code is no longer the scarce resource. The gate hasn’t disappeared, it has flipped. Instead of deciding which ideas get built, we’re now deciding which of the many things we’ve already built should make it out into the world.

That changes what “minimum” means, in two directions at once. The bar for anything you put in front of users as a product has gone up, because everyone can build polished software now. But the bar for a test has gone down. A test doesn’t have to be a product at all. It only has to check the assumption you’re least sure of. Sometimes that’s a working app. Often it’s a landing page, a waitlist button, a sign-up form, or a clickable prototype.

Here’s the trap: when building is cheap, we build the whole product even when a landing page would answer the question. At our last Hack Day, nearly every team built the full app, even though the brief only asked for whatever would support their test.

So, the old question stops being useful. “Can we make this smaller?” assumes size is the problem. The better questions are: what’s the least we need to build to learn what we need to learn, and does what we’re building deliver the value we’re after?

The discipline that used to come from scarcity now has to come from judgement, and judgement needs something to hold onto: a shared anchor made up of the problem we’re solving, what done looks like, and the hypothesis we’re testing.

Feature creep is faster with AI, and harder to see

Your taste and judgement still decide what the thing becomes. The AI will always have another suggestion, and you’re the one who has to force the no.

Lindsey W points out that drift isn’t new. As a team refines their ideas, balancing user design with implementation considerations, every round of ideation naturally tweaks the shape of the solution. Each time, that solution drifts a little further away from the problems it was meant to solve. What’s new is the pace. A team that used to iterate once in a day or two can now iterate fifty times a day. In exchange for speed, we take on a lot more risk of building software that doesn’t solve the problem.

That’s feature creep with a new engine. It moves faster and it’s easier to miss, because every suggestion is cheap and reasonable on its own.

Divergence isn’t the enemy. We want it. Explore lots of ideas, then converge. The trouble is unintended divergence, which can quietly invalidate your test or steer you away from the value you set out to deliver. Ending up somewhere unexpected is fine, as long as you chose to go there.

Looking back at our professional development build, we had a brief. We didn’t have a shared anchor.

Being precise about that anchor matters. The problem statement says what friction we’re removing and for whom. The definition of done says how we’ll know we’ve solved it well enough, since no problem is worth solving 100%. The hypothesis is narrower than people expect: it’s a bet on one or more specific assumptions, not a description of the whole product. Together, they give the team boundaries, and boundaries protect you from overbuilding, underbuilding, and building the wrong thing entirely.

At our most recent Hack Day, every team wrote a hypothesis and a test plan. The teams that wrote theirs before building stayed aligned. One team changed its hypothesis partway through the day and updated the test plan with it, which is exactly the point. The people who left the test plan until the end said it was their biggest regret. The surprise benefit was the test plan brought in scope guardrails: “we need this to run the test” settled arguments that are usually just opinions.

Someone still has to own the anchor. The product manager writes it, brings it as a proposal and defends it, and changes it when new information arrives. But everyone on the team needs to understand it, because they’re the ones building against it and making build decisions in the moment.

Questions to ask before you say yes to the next suggestion

Before anyone builds, agree on the broad jobs: the minimum things the build has to do to run your test, with no design decisions attached. This is the step most likely to get skipped, and skipping it is where most “that’s not what I thought we were building” moments come from, especially when people are working async.

Then, next time the AI offers another feature, or asks “want me to add this?”, stop and ask:

• Does this help us test our hypothesis?
• Is it essential, or is it polish?
• Does the user get real value from it?
• If we add it, what will we learn that we don’t know now?
• If we skip it, what will we be missing?

You can ask your AI too. Just give it the anchor first, or it’ll tend to agree with you. It’s also good at checking your work against the broad jobs and flagging when you’ve added something extra, missed something, or wandered off in a new direction.

When the build forks

Sometimes the build splits anyway. That’s fine. What matters is how you come back together. It’s what we should have done on our professional development build.

Get the team together and write down the problem, who the user is, what done looks like, and the hypothesis you’re testing. Then compare each branch against those, not against each other. Every branch probably has something worth keeping, so judging them head to head just turns into a popularity contest. Judge them against your purpose and pull the best pieces from each.

Sometimes those pieces fit your hypothesis and you can merge them. Sometimes the best branch shows the hypothesis needs to change. If so, say it out loud, rewrite it on purpose, and test again.

Where this leaves us

Scarcity used to do our saying no for us. Now that’s on judgement, and judgement works best when it’s anchored. The teams that do this well will be the ones where the PM holds the pen on the anchor, and anyone on the team can answer “why this, why now,” and can say no to one more thing.