My Approach
Every engagement starts the same way: listen first, diagnose the real problem, build just enough structure to get a team moving, and leave them owning the practices -- not dependent on me.
The first two weeks are diagnostic
I don't show up with a framework and ask a team to adopt it. I show up and watch. Week one is observation: I attend every ritual, read the backlog, and do 1:1s with everyone I can reach. I ask three questions: What is working? What is not? What would you change tomorrow if you could?
Week two is the mirror. I present what I found, propose three concrete changes, and let the team pick the smallest one. That first win builds trust faster than any slide deck. By week three, we are working on the real problems -- not the ones someone assumed existed six months ago.
I wrote about the specific signals I check in What I Look for in a Product Team -- five diagnostic questions that tell me more about a team in a week than any status report.
What I actually do
Once the diagnostic is done, the work falls into four areas. The order depends on what the team needs most.
Discovery
Establishing who the users are, what they need, and how to learn from them continuously -- not just once at the start.
Coaching
Working alongside PMs, designers, and engineers to build product judgment -- not just process compliance. I do, we do, you do.
Delivery model
Designing the rituals, cadences, and artifacts that make shipping predictable. Standups that produce decisions. Retros that change behavior.
Culture
Building the conditions where teams can disagree safely, prioritize ruthlessly, and ship weekly instead of planning to ship "soon."
How I work with teams
I embed. I sit in the standups, pair on the PRDs, attend the customer calls. I am not an advisor who shows up for a weekly check-in and sends a deck. I am a player-coach who does the work alongside the team while building their capacity to do it without me.
Engagements are time-boxed. Whether it is a 6-week sprint or a 6-month fractional role, there is a defined end state and a handoff plan from day one. The best outcome is a team that forgets they ever needed outside help.
What changes when I leave
The goal is never to be indispensable. When an engagement ends, the team should own the practices, not rent them. That means the discovery playbooks live in their wiki, the coaching rhythms are run by their leads, and the delivery cadence is muscle memory -- not something that stops when the consultant leaves.
At Kaiser, the product practice guide I authored reached approximately 20,000 IT staff and outlasted my engagement by years. At Space Force, the delivery model we built cut MVP cycle time from 6 months to 2 weeks and kept running after I moved on. That is the measure: does the work sustain itself?
Want to see this in practice?
Browse case studies from 14 years of engagements, or get in touch to talk about what your team needs.