New product development

From a vision to a harness that can build against it

Everything starts from a vision and resolves into a technical approach. Those two documents are what every later decision gets argued against, and a team that skips them discovers halfway through that it has been building two different products.

A vision and a technical approach used to align people. They now also brief the agents, which raises the cost of skipping them: an agent with no product vision optimises the ticket in front of it rather than the product, and one with no written technical approach invents an architecture per session.

The original version of this playbook ran vision, roadmap, approach, then an inception workshop to size the work. The first three still hold. Step four changed because estimating a quarter of work in a room is worth less than building the harness that will do the work.

1. 01
   Product visionKnowledge

   Where this is going and why. It settles the arguments that would otherwise be re-litigated every sprint, and it is what tells an agent which of two valid implementations is the right one.

2. 02
   Product requirements definition (PRD)Knowledge

   Set out every feature with acceptance criteria that make it checkable. This is the densest piece of context an agent will read, and the criteria are what its tests get written against.

3. 03
   Tech approachKnowledge

   How it gets built: stack, boundaries, storage, integrations, and the reasoning behind each. Write it down and the choice stays arguable while it is still cheap to change.

4. 04
   Harness Maturity ModelGovernance

   This is where an inception used to sit. Build the harness against the three documents above: twelve checks across four layers covering what the agent knows, what it can do, what it can touch, and what it cannot do without permission.

5. 05
   Automated acceptance testing strategyCapabilities

   Define what "works" means before there is code to check. On a new product this is the cheapest it will ever be, and it is the only thing that lets an agent verify its own output.

6. 06
   Decouple code deployment from feature releaseCapabilities

   Ship to production from the first week without showing anyone. A new product has no users to protect yet, which is exactly when the habit is free to build.

7. 07
   Work in small batchesCapabilities

   Keep each increment small enough that a person can still review what came back. Batch size is the throttle on everything above.