What will product teams stop doing by 2030?

Great teams are likely to drop habits built for slow, expensive building: launch parties, measuring velocity, annual roadmaps, week-long test planning, running many bets at once, keeping zombie projects alive, separate playbooks for people and AI, asking users what they want, adding headcount to fix speed and waiting for certainty before deciding.

What should replace the annual product roadmap?

A small set of live experiments that the team re-decides every few weeks. Instead of a 12-month plan fixed at the start of the year, the roadmap becomes a list of current bets with clear signals for whether each one is working, reviewed often enough to change course.

How do you stop zombie projects?

Agree a number and a date before the project starts. If the project misses both, it ends. Setting the kill condition up front makes stopping a planned outcome rather than a personal failure, which is what usually keeps zombie projects alive.

Why is velocity a poor measure of a product team?

Velocity measures how much a team ships, not whether what it ships makes a difference. It is like grading a writer on typing speed. A better measure is how fast the team learns: how quickly it finds out whether a bet worked and changes direction as a result.

How many product bets should a team run at once?

Three at most is a sensible limit. Nobody can watch ten bets properly, so attention spreads too thin and the signals get mixed up. A small number of bets, watched closely, gives clearer results and faster decisions.

Should product teams still ask users what they want?

Asking was the best option when building was expensive. Now that rough versions are cheap, it is often better to show users three working versions and watch what they do. Behaviour with a real product in front of them is a more reliable signal than answers to a hypothetical question.

Product Team Habits to Drop by 2030: 10 Things Great Teams Will Stop Doing

1

The full infographic, as a PDF

The exact one from the post, sized to print or keep within reach.

2

A copy in your inbox

The download link lands in your email too, so it's there when you need it. No follow-up campaign.

3

The Product System, weekly

My note on leading product in the AI era. One idea a week that compounds. Unsubscribe anytime.

Here are ten things great product teams will stop doing by 2030.

Most of these habits made sense once. They grew up when building was slow and expensive, so the safest move was to plan carefully, ship in big batches and celebrate when something finally went out. That world is changing. A rough version of an idea now costs hours, not weeks, and teams are made of people and agents working side by side.

The old playbook shipped more. The new one learns faster. Here is what is dying, and what takes its place.

Launch day parties

Shipping isn't the win. A launch is the moment the bet starts being tested, not the moment it pays off.

What replaces it: celebrate when the numbers move. The party belongs to the week a customer behaviour changed, not the day the release notes went out.

Velocity worship

Measuring a team by how much it ships is like grading a writer on typing speed. It rewards motion and says nothing about whether the motion mattered.

What replaces it: measure how fast you learn. How quickly does the team find out whether a bet was right, and how quickly does that change what it does next?

The annual roadmap

A 12-month roadmap is a 12-month guess, signed in ink. By the time the second half of the year arrives, the assumptions it rests on have usually changed.

What replaces it: run a handful of live experiments and re-decide every few weeks. The plan becomes a set of current bets, reviewed often, rather than a promise made once.

Week-long tests

When a rough version of an idea costs hours, spending a week planning a test is often slower than running it.

What replaces it: if the meeting outlasts the test, run the test. Build the rough version, look at what happens and discuss real results instead of predictions.

Ten bets at once

Nobody can watch ten bets properly. Each one gets a little attention, none gets enough, and the signals blur together.

What replaces it: three in motion, max. Fewer bets, watched closely, teach a team more than many bets watched loosely.

Zombie projects

Killing a project feels like failure, so nothing dies. Projects carry on with no clear case for continuing, using up people and attention that could go somewhere better.

What replaces it: set a number and a date up front. Miss both, and it ends. Deciding the kill condition before the work starts takes the emotion out of stopping.

One playbook for people, another for AI

Your team is humans and agents now. Running two separate ways of handing over work creates gaps, because each side gets different context and different rules.

What replaces it: one handover for both, with the goal, the context, the decisions already made and the checks the work has to pass. A good brief for an agent is a good brief for a person.

Asking users what they want

Asking people what they want made sense when building was expensive, because you only had one shot. What people say they want and what they actually use are often different.

What replaces it: show three working versions and watch what they do. Behaviour with a real thing in front of them tells you more than answers to a hypothetical question.

Headcount as the fix

Adding people feels like the obvious answer to a slow team. Big teams ship more and decide slower.

What replaces it: fix how decisions get made before adding a seat. If decisions are the bottleneck, more people mostly means more meetings.

Waiting to be sure

When change was slow, waiting for more certainty was cheap. Now slow is riskier than wrong.

What replaces it: decide at 70%, and undo fast if you missed. Most decisions can be reversed, so the cost of waiting is often higher than the cost of a correctable mistake.

Learn faster than you build

Put the ten side by side and one pattern runs through them. Every old habit optimises for output: more shipped, more planned, more people. Every replacement optimises for learning: what moved, what you found out, what you decided next.

Teams that switch learn faster than they build. Teams that don't build faster than they learn.

For a closer look at the systems top teams put under these habits, How Top Product Teams Use AI (/vault/how-top-product-teams-use-ai) covers ten moves that change how they decide.

None of this needs a reorganisation. Each habit can be dropped on its own, by one team, starting with the next project. Set a kill date on one bet. Cap the bets in motion at three. Write one handover that works for a person and an agent. Small changes like these show up quickly in how fast the team learns.

Which one would you retire tomorrow? Start there.

Questions people ask

What will product teams stop doing by 2030?: Great teams are likely to drop habits built for slow, expensive building: launch parties, measuring velocity, annual roadmaps, week-long test planning, running many bets at once, keeping zombie projects alive, separate playbooks for people and AI, asking users what they want, adding headcount to fix speed and waiting for certainty before deciding.
What should replace the annual product roadmap?: A small set of live experiments that the team re-decides every few weeks. Instead of a 12-month plan fixed at the start of the year, the roadmap becomes a list of current bets with clear signals for whether each one is working, reviewed often enough to change course.
How do you stop zombie projects?: Agree a number and a date before the project starts. If the project misses both, it ends. Setting the kill condition up front makes stopping a planned outcome rather than a personal failure, which is what usually keeps zombie projects alive.
Why is velocity a poor measure of a product team?: Velocity measures how much a team ships, not whether what it ships makes a difference. It is like grading a writer on typing speed. A better measure is how fast the team learns: how quickly it finds out whether a bet worked and changes direction as a result.
How many product bets should a team run at once?: Three at most is a sensible limit. Nobody can watch ten bets properly, so attention spreads too thin and the signals get mixed up. A small number of bets, watched closely, gives clearer results and faster decisions.
Should product teams still ask users what they want?: Asking was the best option when building was expensive. Now that rough versions are cheap, it is often better to show users three working versions and watch what they do. Behaviour with a real product in front of them is a more reliable signal than answers to a hypothetical question.