The Product Playbook
This is the system I use to build product, product teams, and the cultures that make good product work repeatable. I started building this playbook over a decade ago and carried it into every job since, sharpening it each time. For most of its life it was mine, a private system I leaned on to help every team I joined do their best work. I'm sharing it now in case it helps you wherever you are in your own product journey.
Nobody is born into product. People find their way in from everywhere. Engineering, design, project management, business analysis, straight out of a school that never taught the job at all. Each one picks up the craft a little differently, shaped by wherever they came from. That mix is a strength, not a flaw. The best teams I've built had the widest range of instincts in the room.
But range comes with drift. An engineer leans on an engineer's instincts. A project manager reaches for a plan and a date. Left to sort it out alone, people fall back on an old habit or lose an afternoon hunting for how the good teams handle it. That doesn't scale. The bigger the team, the more that can go wrong.
That's the gap this closes. Not with a rigid process to run start to finish, but with the best ways I've found to do the work and the judgment for when to reach for each one. It breaks product down into its real parts, teaches them one at a time, and tells you the stories underneath. So a method connects to your actual week instead of sitting in your notes as theory.
That's the difference between this and a quick search or an AI that spins you up a process on demand. Those hand you steps. This hands you the whole picture. The situation you're in, the move that fits it, and the point of all of it, which is to stay close to your customer and solve real problems.
Line everyone up behind that same picture and the range finally pays off. The instincts still differ, but they point at one goal, and the product comes out built well instead of built around whoever argued hardest in the room.
I've used this playbook to build systems across AgTech, compliance, insurance, and CPG, on teams as small as two and as large as twenty-six.
The industries change. The work doesn't.
You shape the method to the room you're standing in. AgTech is a clean example. You don't have millions of users, you have hundreds, and the calendar runs the business. Build a brilliant app for planting, miss the planting window, and you haven't shipped a week late, you've shipped a year late.
What it emphasizes
Strip away the domain and the fundamentals are always the same.
- Get close to your customer
- Understand the problem before you fall in love with a solution
- Validate cheaply before you build expensively
- Ship in a way that lets you learn
- Chase outcomes, not output
Everything in here points back to those few ideas. The pages just give you the methods to actually do them.
Who it's for
Anyone doing product work, at any stage. A two-person startup and a global enterprise need the same fundamentals. Scale changes how you apply the ideas. It doesn't change the ideas.
It's also for the people around product, the engineers, designers, business leaders, and executives who want to understand why product teams work the way they do. It's not because we enjoy made-up words like spike, epic, kanban, sprint, or scrum master.
How to use it
You don't have to read it front to back. Each page stands on its own, but they're stronger stacked together.
New to product? Start with Life as a Product Manager for the mindset, then The Opportunity Backlog for the core operating system. Here for a specific tool? Go straight to The Toolbox.
Keep an open mind about how flexible this is. A lot of it does double duty. You can run the Opportunity Backlog on your product and on your own career. You can use Design Thinking to build empathy with the customers you serve and the colleagues you work next to. Take what fits the room you're in and leave the rest.
A note on sources
What a job actually is
When broken down to its simplest form, the essence of any job is problem-solving. Regardless of your role or department in an organization. A company hires you to solve problems, and the best place to point that problem-solving is at making or saving money, by solving the right problems inside the business and for its customers. Companies exist to make money. Products exist to solve problems. Every career is some version of those two things meeting. Keep that in view and most of the noise gets quiet.
This is a living document
This playbook is never finished, and that's on purpose. It reflects what I've learned so far. As the world changes, as AI reshapes what's possible, as I learn from the next team and the next problem, it gets updated. A playbook that stops changing is a playbook that's stopped being useful.
So treat everything here as the current best version, not the final word. If you've got a better way, or you think I'm wrong about something, let's talk. I love a good discussion.