AI is making implementation cheaper.
That does not make planning less important. It makes bad prioritization more expensive because a team can now build the wrong thing much faster.
The bottleneck is moving from engineering capacity to judgment: deciding what matters, getting enough evidence to act, and changing direction quickly when the evidence changes.
Our planning system is designed around that.
A few bets at a time
We organize work around a small number of initiatives.
An initiative is a bet about an outcome we want to create for the customer or the business, not a list of features we have committed to shipping.
Each one should answer three questions:
- What is true today, and why does it matter?
- What do we want to make true?
- How will we know if it worked?
Projects and weekly work should trace back to one of these initiatives. If something does not, either our priorities are missing something or the work probably should not happen.
Both are useful things to discover.
An initiative is also not a permanent commitment. We should know what evidence would make us continue, change direction, double down or stop.
At the end of a cycle, work does not automatically roll forward because it is unfinished. We decide again.
Starting is cheap. Finishing is scarce.
AI makes it dangerously easy to start things.
A prototype can take hours. A branch takes seconds. A coding agent can produce a plausible implementation before the team has finished deciding whether the idea matters.
That means work in progress matters more than backlog size.
Every additional active project competes for product attention, design attention, code review, testing, GTM and customer feedback. Those become the scarce resources long before generated code does.
We keep the number of active initiatives deliberately small. Starting another project is rarely the answer. Finishing, learning or killing one usually is.
Plan six weeks, steer weekly
We do not build quarterly or annual product roadmaps.
The market, models, customer expectations and our own understanding of the product move too quickly for detailed plans that far out to remain useful.
We work with roughly six-week horizons. At the start of that period we set targets, identify the major product surface we expect to work on and make our best judgment about 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 preserve direction without becoming attached to the plan.
Stay one lap ahead
Product and design should stay ahead of implementation, but not by much.
If engineering is waiting for the next problem to be understood, we lose momentum. If product is specifying work months in advance, we accumulate decisions made with old information.
The ideal distance is roughly one lap.
While one thing is being built, the next thing is being researched, prototyped and de-risked. Beyond that, we mostly preserve problems, evidence and opportunities rather than detailed solutions.
Inventory decays in product development too.
At Durable, this increasingly happens through working branches rather than large specifications. Product and design can prototype directly inside the product, validate the experience and give engineering something executable to review or extend.
Discovery is continuous
Ideas can come from anywhere: customer conversations, product data, support, sales, engineering insight, competitive research, market changes or founder vision.
Product is responsible for turning those signals into prioritization.
That means gathering qualitative and quantitative evidence, understanding the customer problem, comparing it against other opportunities and deciding whether it deserves scarce team attention.
Not every idea needs a long discovery process. Some are obvious enough to prototype immediately. Others need research, technical de-risking or a small experiment before we should commit meaningful engineering time.
When technical uncertainty is the main risk, we run a spike. The purpose of a spike is not to build the feature. It is to buy clarity cheaply.
Reversible decisions should move fast
We spend planning effort in proportion to how expensive a decision is to reverse.
A UI experiment behind a branch preview deserves very little ceremony. A database migration, pricing change or architectural decision that will be difficult to unwind deserves more.
AI and our branch infrastructure make many product decisions cheaper to reverse than they used to be.
We should take advantage of that.
Build the branch. Put it in front of people. Learn.
The more reversible the decision, the less upfront planning it deserves.
Keep the unit of work customer-centric
We avoid turning product planning into hundreds of tiny tickets created in advance.
The main unit of work should describe something meaningful from the customer's perspective. Engineers can break that work into whatever implementation tasks they need as they learn more about the problem.
This keeps the project legible to product, engineering and GTM while avoiding false precision before implementation begins.
Everything meaningful has a clear DRI and belongs to a project. Ownership should be obvious without requiring a meeting to discover who is responsible.
Backlogs decay
We do not treat a giant backlog as an asset.
A ticket written six months ago captures six-month-old assumptions about the customer, market, product and technical constraints. Keeping it around does not make it more correct.
Important problems tend to resurface.
We preserve customer evidence, research and opportunities. We are much less precious about preserving old solutions.
A backlog should not become a cemetery where ideas pretend to be commitments.
Planning cycles are not release cycles
Teams should ship whenever work is ready.
A six-week planning horizon does not mean waiting six weeks to release something.
Our infrastructure and branch workflow are designed around continuous delivery. Features can be built, reviewed and exercised in isolated environments before being merged to production. Small improvements might move from branch to production in hours. Larger work can ship progressively as useful pieces become ready.
Every week ends with a demo so the broader team sees what actually changed.
Progress is measured by what shipped, what changed for customers and what we learned, not by how many tickets moved across a board.
Do not optimize for utilization
A team at 100% planned utilization has no ability to respond.
There is always variance: production issues, customer feedback, an experiment that changes our understanding, a new model release or an opportunity that was not obvious a week ago.
We intentionally leave slack.
That is not wasted capacity. It is what lets the team absorb reality without blowing up the plan.
If nothing unexpected happens, that capacity goes toward bugs, technical debt, small improvements or de-risking future work.
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 feature should be exercised on its branch, reviewed by the right people and held to the same product standard regardless of whether the first implementation came from an engineer, designer, PM or coding agent.
Fast teams need stronger judgment, not weaker standards.
Momentum is the loop
For us, momentum is not velocity points or tickets closed.
It is the elapsed time between identifying something important, putting a useful change in front of customers, learning from it and making the next decision.
The loop is:
AI compresses the build step.
Our job is to compress the rest of the loop too.
That means fewer active bets, less ceremony around reversible decisions, product staying one lap ahead, continuous shipping and enough slack to change direction when the evidence changes.
AI will keep reducing the cost of implementation.
The companies that benefit most 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.
That is what our planning system is designed to optimize.