Planning When Building Is Cheap

TL;DR

• Cheaper implementation does not justify a larger roadmap. It moves the constraint to judgement, evaluation, review, adoption, operations, and distribution.
• Prioritise the uncertainty that could invalidate the bet. A quick prototype is useful only when it produces evidence for the next decision.
• Strategy gives fast teams boundaries. Every active bet needs an outcome, evidence threshold, capacity allocation, and abandonment condition.

---

AI tools can compress research, prototyping, analysis, and implementation. They do not compress every dependency at the same rate.

A team may generate five credible solutions in a day and still have capacity to test only one with customers, review one safely, or support one after release. Planning fails when it treats generated output as finished throughput.

The planning job is to limit work to the number of learning loops the organisation can complete.

Strategy is a constraint system

Strategy is often presented as a vision followed by a roadmap. Fast teams need more precision. They need to know where they may move without waiting and which choices would contradict the company position.

State four things:

Clear constraints increase autonomy. A team can move quickly when it understands the intended customer outcome, the competitive position, and the decisions that require escalation.

Strategy that consists only of ambition creates activity. It does not create direction.

Plan against the complete system

Engineering capacity is one input. AI products also consume capacity after the first implementation.

The narrowest constraint sets the portfolio size. A team that can build ten features and operate two should plan for two.

AI productivity should lead to fewer concurrent bets, not a backlog that expands to consume every recovered hour. The sustainable AI work chapter covers the workload consequences when leaders ignore that limit.

Prioritise the uncertainty, not the artefact

Start each bet by naming what could make it wrong.

Common uncertainties include:

• The customer does not care enough to change behaviour
• The model cannot meet the quality threshold on representative work
• Human review makes the workflow too slow or expensive
• The product cannot access or lawfully use the required data
• A competitor or platform can reproduce the feature before distribution compounds
• The organisation cannot support the change safely

Choose the cheapest credible way to test that uncertainty. It might be an interview, a concierge service, an offline eval, a technical spike, a pricing conversation, or a controlled production release.

A working prototype is persuasive, so it often receives more confidence than the evidence warrants. State its maturity and the decision it can support. A generated interface can test comprehension. It cannot prove retention, production reliability, or willingness to pay.

The product bet framework defines the observation, belief, intervention, expected outcome, evidence threshold, and abandonment condition behind each investment.

Match commitment to uncertainty and consequence

Use uncertainty and reversibility to choose the planning posture.

This prevents two common errors. Teams over-plan reversible work because the organisation is used to slow delivery. They under-plan consequential work because a polished prototype creates false confidence.

Allocate capacity before ranking ideas

A single score hides different kinds of work. Reliability, customer commitments, exploration, platform health, and growth should not compete as though they share one risk profile.

Set capacity ranges for the portfolio before ranking individual bets. The categories should match the business, but a useful set might include:

• Customer and business outcomes
• Reliability, security, and governance obligations
• Learning bets with explicit decision dates
• Platform or context work that removes repeated team cost
• Product retirement and operational cleanup

Capacity ranges are not permanent quotas. They expose the trade-off. When leadership adds an urgent initiative, the planning conversation identifies what loses capacity or stops.

Treat capability forecasts as assumptions

Model capability moves faster than most product planning cycles. Building only for today's weakness can create scaffolding the next model makes redundant. Building for an imagined future model can leave the current product unusable.

Separate three decisions:

1. What must work now? The current release needs evidence against the current production system.
2. What should remain substitutable? Keep model, prompt, retrieval, and tool boundaries testable where future capability could change the design.
3. What are we willing to wait for? Record which product ideas depend on an unproven capability and what signal would justify revisiting them.

Use the relevant eval suite to test new models against the job. Do not redesign the roadmap around vendor demonstrations or public benchmarks.

Use roadmaps to communicate outcomes and options

A roadmap should distinguish commitments from options.

Now contains bounded work with an accountable owner, available capacity, and enough evidence to justify action.

Next contains validated opportunities whose sequence still depends on learning, dependencies, or capacity.

Later contains strategic options and capability assumptions. It is not a promise with the date removed.

For each item, show:

• Intended customer and business outcome
• Evidence supporting the investment
• Main unresolved uncertainty
• Capacity and dependencies across the complete system
• Decision or release trigger
• Condition that would stop or reshape the work

When build speed increases, the roadmap should not become a longer feature list. It should become a clearer account of choices.

Set cadence from evidence

Do not accelerate every ceremony because implementation accelerated.

Review a bet when material evidence arrives, a constraint changes, or a decision is due. Some teams need weekly portfolio decisions. Others need a monthly strategy review supported by continuous delivery data. The right cadence is fast enough to act on evidence and slow enough to observe real behaviour.

Keep tactical coordination separate from strategic review. A daily discussion about implementation should not silently rewrite the customer, position, or risk appetite.

The portfolio review

Ask these questions at a regular decision forum:

1. Which active bet has produced new evidence?
2. Which uncertainty now deserves the next unit of capacity?
3. Where is review, adoption, operations, or distribution limiting throughput?
4. Which work is continuing because implementation is easy rather than because the outcome matters?
5. What changed in model capability, economics, regulation, or customer behaviour?
6. Which bet should stop, narrow, or graduate into production ownership?
7. What are we explicitly not doing?

Record the decision and the evidence that changed it. A roadmap without a decision history becomes a presentation of current intent with no organisational memory.

Anti-pattern: the infinite Now

The team can build faster, so leadership moves more ideas into active delivery. Prototypes accumulate. Reviews become shallow. Customer-facing teams cannot explain the releases. Agents and features enter production without durable ownership.

Everything is in progress. Nothing has completed the learning loop.

Planning when building is cheap requires restraint. Limit work to the evidence, review, adoption, and operating capacity available. Make the choice visible, then let the team move.