Product Owner and Scrum Master on a spec-first team

On a fast-moving project the risk usually isn't writing too little code, it's the team losing track of why the code is the way it is. STP was built by a team of six, and I was its Product Owner and its Scrum Master. That meant deciding what the product had to answer and in which order, and keeping the loop between feedback and a working increment as short as possible. This post is about how that loop worked, because it explains most of the other posts.

A backlog that starts from the problem

The backlog didn't start from features. It started from the research into what carmakers already use, which ended in six pain points, and every feature was tied to one of them. Prioritizing then meant asking which question the product couldn't answer yet: is this car profitable, what if the dollar moves, what happens at a higher volume. Features that didn't serve one of those questions waited.

Every decision written before code

The project had one non-negotiable rule: any new structural question is settled by a written decision, a spec or an architecture decision record, before any code.

• Each spec opens with a dated table of decisions, and lists what was considered, what was turned down and why. "A Kafka event to invalidate the market price" is in a spec as a rejected option, with its reason.
• Each implementation plan ends with what actually differed from the plan once it was done.
• The rules are written for humans and agents alike. We worked with AI coding agents, and a single AGENTS.md file gave them the same rules as everyone else: specs before code, Decimal for money, verify before announcing. Their output could then be reviewed against a spec instead of against someone's memory of a conversation.

That came to 38 specifications, 6 architecture decision records and 45 plans. Writing first is slower on the first day of each feature, and every decision has to be stated precisely enough to be wrong. In exchange, anyone starting on any part of the system started from the same written context, and the questions people kept asking ("why Kafka between instances?", "can a quote change?") already had written answers, with the alternatives we turned down.

From feedback to an increment

Feedback arrived as lists, from reviewing the product and from using it. As Product Owner, I triaged each list into lots: one coherent increment, one spec, one plan, and explicit dependencies on other lots.

The first list alone had eight items. Item 7, rethinking how options work, was flagged as the most important and went first. Some items were deliberately left out of scope, like a selling price per option, and the spec says so in writing rather than leaving them to be forgotten.

Done means tested, documented, verified

Our definition of done was short and strict:

• tests and lint pass;
• the README changes in the same increment if a service, a port or a command changed;
• the spec's status moves to "delivered" and links its plan;
• the increment runs on the full stack, with clean data, ready to show to anyone.

Performance followed the same standard: a measured report with a method section, comparing every version of the code, with its unknowns listed as unknowns (where the time actually went). And before the last redesign, a user-journey review went through the product profile by profile, at desktop and phone widths, in light and dark mode, and its findings became lots like any other feedback.