Product work is choosing what not to build.
"Understand what product discipline means at a small agency."
Musa IbrahimWhy this exists
Most product failures are failures of clarity rather than engineering. Nobody agreed on success, nobody asked users the right questions, and nobody said no. We wrote this handbook to make these failures rare.
Operational Flow
Seek clarity first: Write the spec before the story, and define the outcome before the spec.
Prioritize continuously: Every yes is a no to something else. Make that trade-off consciously.
Ship behind flags: Put features in production when they are ready, not when the branch merges.
Base decisions on research: Talk to users before building, instead of wondering why a feature flopped.
Measure outcomes: If you ship a feature to improve retention, measure the retention.
What good looks like
- The team explains in one sentence why they are building a feature and what will change if it works.
- Specs get challenged in review and come back sharper, rather than being rubber-stamped.
- Engineers push back on vague requirements because they know what a clear spec requires.
- The backlog gets shorter every sprint because we know when to say no.
What NOT to do
- Don't treat this handbook as a checklist. A spec with ticked boxes but no real thinking is useless.
- Don't use these processes to simulate product work. Focus on outcomes.
- Don't treat process as a shield against hard decisions. Process is scaffolding, not a replacement for thought.
Product discipline at an agency requires restraint. A large company can fund ten bets and succeed on three. We cannot. Every feature we build is time lost fixing something broken. Every new screen increases maintenance overhead. The temptation to build every idea a client gets excited about is strong. That is how you end up with a product that does twenty things poorly instead of five things well.
This handbook details how we write specs, prioritize backlog items, ship behind flags, interview users, and verify if our code worked. None of these ideas are new. They are just the basics that get skipped when people hurry. Product work is mostly saying ‘not yet’ and ‘why’. You must be rigorous enough about both that the team trusts you when you finally say ‘yes’.