Internalize the handbook.
"Understand what internalizing these product practices looks like in day to day work."
Musa IbrahimWhy this exists
A handbook you consult is a crutch, but a handbook you have internalized is a compass. Do not treat this as a reference document. We want the thinking behind these practices to become reflexive defaults.
Operational Flow
Write the spec: Force yourself to understand the problem before designing a solution.
Name the metric first: If you cannot define what success looks like, you are not ready to build.
Talk to users before you decide: Research is input for decisions, not validation after the fact.
Ship behind flags: Separate deployment from release. Roll out gradually and clean up the flags when done.
Check the metric 30 days later: Shipping is not the finish line. Look at the numbers.
What good looks like
- A team asks what metric a feature is supposed to move during the first discussion, without being prompted.
- Sprint planning takes under thirty minutes because the backlog is clean, scored, and understood.
- Product reviews focus on outcomes rather than output. The team presents an activation improvement of 12% instead of counting features shipped.
- An engineer flags a vague spec before writing code because they know what a clear one looks like.
What NOT to do
- Don't quote this handbook to win arguments. This is a framework for thinking, not a legal code.
- Don't follow process blindly when judgment is needed. A 30-day check-in is useless if you can see a feature is broken in real time.
- Don't mistake running research for understanding users. Reading transcripts and sitting with the findings is what builds intuition.
If this handbook did its job, you have stopped thinking about it. You write specs because they clarify your thinking. You talk to users because you have been burned by skipping it. You check metrics thirty days out because you want to know if the feature worked, not because of a calendar reminder. The reasoning behind the rule becomes obvious, and the rule itself disappears.
Product work at an agency means balancing constant client requests with a pressure to build. This handbook makes several bets. We bet that thinking before coding saves time, that measurement is worth the overhead, and that a clear ‘no’ is better than a bad ‘yes’. If you disagree with one of these bets, write a new version, share it, and make your case. The handbook is a living document.