Product Development: III. Planning

AI is making implementation cheaper. That does not make planning less important. It makes bad prioritization more expensive, b/c a team can now build the wrong thing much faster.

The bottleneck moves from engineering capacity to judgment: deciding what matters, getting enough evidence to act and changing direction quickly when the evidence changes. This is how I plan around that.

The unit I plan in is a six to eight-week cycle. This part is about what goes into one. The next part is about how one runs.

Planning should create momentum, not certainty.

A few bets at a time

I organize work around a small number of bets. A bet is an outcome we want to create for the customer or the business, not a list of features we promised to ship. Each one should answer three questions:

  1. What is true today, and why does it matter?
  2. What do we want to make true?
  3. How will we know if it worked?

In a cycle, the bets are the Priorities and the answer to the third question is the Measure.

Projects and weekly work should trace back to one of these bets. If something does not, either the priorities are missing something or the work should not happen. Both are useful things to find out.

A bet is not a permanent commitment either. Know upfront what evidence would make you continue, change direction, double down or stop. At the end of a cycle, unfinished work does not roll forward by default. We decide again.

Starting is cheap, finishing is scarce

AI makes it dangerously easy to start things. A prototype takes hours, a branch takes seconds and a coding agent will hand you a plausible implementation before the team has decided whether the idea matters.

So work in progress matters more than the size of the backlog. Every extra active project competes for product attention, design attention, code review, testing, GTM and customer feedback, and those run out long before generated code does. Starting another project is rarely the answer. Finishing, learning from or killing one usually is.

AI increases throughput at the beginning of the funnel. Focus is what increases throughput at the end.

Plan six weeks, steer weekly

I do not build quarterly or annual product roadmaps. The market, the models, customer expectations and our own understanding of the product move too fast for detailed plans that far out to stay useful.

I plan in six to eight-week cycles. At the start of one, we set targets, pick the major product surface to work on and make our best call on where the leverage is. That is a direction, not a contract. Every week, we re-evaluate based on what we learned. A customer conversation, a failed experiment, new product data, a competitor move or a new model capability can change the right thing to do next.

The job is to keep the direction without getting attached to the plan.

Stay one lap ahead

Product and design should stay ahead of engineering, but not by much. If engineering is waiting for the next problem to be understood, the team loses momentum. If product is specifying work months in advance, you pile up decisions made with old information.

The ideal distance is about one lap. While one thing is being built, the next is being researched, prototyped and de-risked. Beyond that, keep problems, evidence and opportunities around instead of detailed solutions. Inventory decays in product development too.

More and more, that lap is run on a working branch and not in a spec.

Discovery never stops

Ideas come from anywhere: customer conversations, product data, support, sales, engineering insight, competitive research, market changes or founder vision. Product turns those signals into prioritization, i.e., gathers the qual/quant evidence, understands the customer problem, compares it against the other opportunities and decides whether it deserves the team’s scarce attention.

Not every idea needs a long discovery process. Some are obvious enough to prototype right away. Others need research, technical de-risking or a small experiment first. When technical uncertainty is the main risk, run a spike. The purpose of a spike is not to build the feature. It is to buy clarity cheaply.

Where discovery sits in a cycle, and what changes when the unknown is a model and not the code, is in Cycles.

Reversible decisions move fast

Spend planning effort in proportion to how expensive a decision is to reverse. A UI experiment behind a branch preview deserves almost no ceremony. A database migration, a pricing change or an architectural decision that is hard to unwind deserves more.

AI and branch previews make many product decisions cheaper to reverse than they used to be. Take advantage of that. Build the branch, put it in front of people and learn.

Customer-centric units of work

Do not turn planning into hundreds of tiny tickets created in advance. The main unit of work should describe something meaningful from the customer’s perspective, and engineers break it into whatever tasks they need as they learn more. That keeps the project legible to product, engineering and GTM, and avoids false precision before the work starts.

Everything meaningful has a DRI and belongs to a project. Nobody should need a meeting to find out who owns what.

Backlogs decay

I do not treat a giant backlog as an asset. A ticket written six months ago captures six-month-old assumptions about the customer, the market, the product and the technical constraints. Keeping it around does not make it more correct.

Important problems resurface on their own. Keep the customer evidence, the research and the opportunities, and be much less precious about old solutions. A backlog should not become a cemetery where ideas pretend to be commitments.

Planning cycles are not release cycles

A six to eight-week planning cycle does not mean waiting that long to release something. Work ships whenever it is ready. A small improvement can go from branch to production in hours, and larger work ships progressively as useful pieces are done. Every week ends with a demo so the whole team sees what actually changed.

Progress is what shipped, what changed for customers and what we learned, not how many tickets moved across a board.

Leave slack

A team planned at 100% utilization cannot respond to anything. There is always variance: a production issue, customer feedback, an experiment that changes our understanding, a new model release or an opportunity that was not obvious a week ago.

So I leave slack on purpose. If nothing unexpected happens, it goes to bugs, technical debt, small improvements or de-risking what comes next.

Slack is not waste. Slack is maneuverability.

Quality still belongs to the team

Speed does not move responsibility somewhere else. Product, design and engineering share responsibility for the quality of what reaches customers. Automated tests, evals and AI-assisted testing help, but they do not replace judgment. The bar is the same whether the first implementation came from an engineer, a designer, a PM or a coding agent.

Fast teams need stronger judgment, not weaker standards.

Momentum is the loop

For me, momentum is not velocity points or tickets closed. It is the elapsed time between spotting something important, putting a useful change in front of customers, learning from it and making the next decision:

signal → decision → build → ship → evidence → decision

AI compresses the build step. The job of planning is to compress the rest of the loop too: fewer active bets, less ceremony around reversible decisions, product one lap ahead, continuous shipping and enough slack to change direction when the evidence changes.

The companies that benefit most from cheap implementation will not be the ones that generate the most code. They will be the ones that decide well, finish what matters, learn quickly and change their minds without losing momentum.

The mechanics of a cycle are in the next part, Cycles, and releases are in Shipping.