Practices and frameworks from 14 years of coaching product teams.
These are the things I teach, coach, and implement with every team I work with. Each practice is standalone -- start wherever feels most relevant to your situation.
Want help implementing these practices with your team?
Let's talkThe fundamentals of building software with discipline
How to run a planning meeting that actually improves your next two weeks
Use this when: You're running or improving your team's sprint/iteration planning process
Writing stories that developers can actually build from
Use this when: Your stories keep growing mid-sprint or developers keep asking 'what do you actually want?'
Two people, one problem -- and why it produces better work faster
Use this when: Your team works in silos, handoffs create rework, or you want to introduce cross-discipline collaboration
How to run team ceremonies that respect everyone's time and actually produce decisions
Use this when: Your meetings run long, only one person talks, or decisions don't stick after the room clears
Writing tests first isn't just for engineers -- it's how product teams verify that what gets built is what was intended
Use this when: Your team ships code without tests, reviews AI-generated code by reading instead of running, or quality is declining
Understanding users and validating ideas before building
How to validate assumptions before investing development time
Use this when: You're about to invest weeks of development time on an assumption nobody has tested
How to ground product decisions in what users actually need instead of what the loudest stakeholder wants
Use this when: Your team is building from assumptions, research isn't reaching the backlog, or you haven't talked to a user in weeks
Keeping your team aligned, energized, and unblocked
A diagnostic framework for teams that know something's wrong but can't name it
Use this when: Your team knows something is off but can't articulate what
Why product, design, and engineering need equal voice -- and how to make it work
Use this when: One discipline is dominating decisions, or the team feels siloed
Why the 80% planning rule protects your team's velocity, quality, and retention
Use this when: Velocity is declining without clear cause, people are working weekends, or energy is visibly dropping
A structured process for resolving disagreements before they erode trust
Use this when: A disagreement has persisted beyond one conversation, people are working around each other, or decisions keep getting relitigated
How to adapt team practices when you're not in the same room
Use this when: Your team is partially or fully remote and ceremonies, pairing, or trust are suffering
Adopting AI with intention, not just enthusiasm
Diagnosing problems and defining what success looks like
How to figure out why your team is slow before deciding what to change
Use this when: Velocity is declining, stories keep carrying over, or something feels off but you can't explain why
How to define success before deciding what to build
Use this when: Your team measures success by what they shipped instead of what changed
How to make technical decisions together when architecture is also a product decision
Use this when: PM and engineering are making technical decisions in isolation, build vs buy needs evaluation, or timeline disagreements are stalling progress