AI Killed Product Estimation

I spent 18 years estimating how long products take to build. Story points. T-shirt sizing. Sprint planning. Quarterly roadmaps. Gantt charts that nobody believed but everyone pretended to follow.

All of that is useless now.

Not because estimation was always wrong (it was, but that’s a different article). Because the thing we were estimating changed so fundamentally that the frameworks don’t apply anymore. It’s like using a sundial to measure microseconds. The tool isn’t broken. The scale is.

What broke

The old estimation model assumed a relationship between features and time that was roughly predictable. A login screen takes two days. A payment flow takes a week. An API integration takes three days. You could be wrong by 2x or even 3x, but you were in the ballpark.

That relationship dissolved.

A login screen takes an hour. A payment flow takes a day. An API integration takes a few hours. Not because the work got simpler. Because the execution layer compressed by an order of magnitude. AI coding tools, better frameworks, faster infrastructure. The gap between “I know what to build” and “it’s built” shrank to almost nothing.

When the execution step goes from weeks to hours, every framework built around estimating that step becomes noise.

Story points? They measured relative effort in a world where effort was the bottleneck. Effort isn’t the bottleneck anymore.

Sprint planning? It was a way to batch work into two-week chunks because deploying and coordinating was expensive. Deploying is cheap. Coordinating a two-person team takes five minutes.

Velocity tracking? It assumed consistent team output that you could project forward. When one person’s output can vary 10x depending on the problem, velocity is just a random number.

The part nobody talks about

Here’s where it gets tricky. The same thing that killed estimation created a new problem that’s arguably worse.

When building is fast, you build too much.

“It’ll only take a day” is the most dangerous sentence in product development right now. I hear it constantly. From founders, from engineers, from myself. And it’s true. It probably will only take a day. That’s not the point. The point is whether it should be built at all.

Feature creep used to be a discipline problem. A PM said no, or the sprint was full, or the budget ran out. There were natural constraints that prevented teams from building everything.

Those constraints evaporated. When every feature is cheap and fast, there’s no natural stopping point. The backlog grows instead of shrinking. The product gets wider instead of deeper. You ship 30 features when users needed 3.

I’ve caught myself doing this. Shipping something in an afternoon that I should have questioned for a week. The speed is intoxicating. You feel productive. But productivity without direction is just organized waste.

The old way is dead. What replaces it?

I’ve been thinking about this for months, and I keep coming back to the same idea: flip it.

Stop estimating how long features take. Start with a time constraint and work backward.

Instead of “here are the 20 features we need, how long will this take?” try “we have 4 weeks, what’s the most useful thing we can ship?”

This isn’t a new idea. Basecamp talked about shaping work to fit appetites years ago. But AI made it urgent. Because without a hard constraint, the default is to build everything. And building everything is the fastest way to build something nobody wants.

Here’s what the new model looks like in practice:

Set a time box. 4 weeks. 6 weeks. 12 weeks. Whatever fits. This is the constraint that replaces estimation. You don’t estimate to find the timeline. You set the timeline and scope to fit.

Define one problem. Not ten features. One problem that, if solved, makes the product worth using. Everything else is a distraction until that one thing works.

Ship it. Not to investors. Not to your advisory board. To real users who have the problem you’re solving. Put it in their hands while it’s still rough. This is the part most founders resist because it feels premature. It’s not. It’s the whole point.

Let them tell you what’s next. This is where it gets interesting. Instead of guessing what features to build, ask the people using the product. Not with surveys. With conversations. What’s missing? What’s frustrating? What would make this something you’d pay for?

The best products I’ve built recently weren’t shaped by roadmaps. They were shaped by users who cared enough to tell me what was wrong. That feedback is worth more than any estimation framework.

The MVP your users help you build

There’s a version of MVP that most founders skip. The traditional MVP is “the smallest thing we can launch.” You build it, you ship it, you measure it. The users are subjects in an experiment.

The version that works better in 2026 is an MVP your community is actively involved in building. Not just testing. Building. Telling you what matters. Voting with their attention and their money. Shaping the product through feedback and requests.

This works because the build cycle is so short that user feedback can actually influence what ships next week. In the old world, feedback took months to turn into features. By the time you built what users asked for, they’d moved on. Now you can hear something on Monday and ship it on Wednesday. The loop is tight enough that users feel heard. And when users feel heard, they stick around.

tini.bio started this way. gratu started this way. The first version was barely there. But the people using it told me exactly what to build next. Not a product manager. Not a market research report. The actual humans with the actual problem.

What estimation becomes

Estimation doesn’t disappear entirely. It just changes what it’s for.

You still need to answer “can we ship something useful in 4 weeks?” That’s a judgment call, not a math problem. It requires someone who understands the problem, the technology, and the scope well enough to say yes or no without a spreadsheet.

You still need to answer “is this feature worth building?” That’s a prioritization question, not an estimation question. The answer comes from user feedback, not story points.

You still need to answer “are we building too much?” That’s the hardest question. And it’s the one that matters most. Because the default in 2026 is to build too much. Every team I talk to has this problem. The discipline isn’t shipping faster. It’s shipping less.

The skill that matters now

The skill isn’t building fast. Everyone can build fast. AI gave that away for free.

The skill is knowing what not to build. Saying no when building yes would only take a day. Keeping the product focused when the temptation to add one more thing is constant. Choosing depth over width when width is cheap.

That’s a judgment skill, not a technical skill. And it’s the one that separates products that work from products that do everything and matter to nobody.

The founders who figure this out first will ship products that feel focused, useful, and alive. The ones who don’t will ship feature factories that nobody loves.

Estimation is dead. Good riddance. What replaces it is better: a tight loop between building and listening, constrained by time, shaped by the people who actually use the thing.

That’s how products should have been built all along. We just didn’t have the tools to make it work until now.