PRODUCT · PEOPLE · PROCESS
I operate at the intersection of product, people, and process, and I don't sacrifice one to save another.
Diagnostics and a roadmap that runs without me, for companies navigating a merger, a leadership transition, or a deadline they can't afford to miss.
Most companies mid-merger, mid-leadership change, or racing a deadline they can't miss can point to the one thing that's visibly failing. They can't usually tell you why the other two fronts are about to go too.
You've read the org chart. You've read the roadmap. Meetings run long, decisions stall waiting on the wrong person, and the plan that looked fine on paper keeps slipping anyway. Nobody can point to exactly where it's breaking, because it isn't breaking in one place.
Twenty years of doing this work as an operator, not an observer. Taking a product from zero to one under a hard, customer-committed deadline. Leading a team through leadership turnover. Standing up an operating function from nothing. Often all at once, inside a company navigating its own merger.
I come into a business, pinpoint exactly where each front is breaking, and hand over a specific plan to fix it - not an ongoing contract where I run it.
The principles behind all my work
When something breaks, the easy explanation is a person: the one who missed it, dropped it, didn't see it coming. The accurate explanation is almost always structural: a decision with no clear owner, an incentive built to reward the wrong thing, a process that assumed something false about how work actually moves. I look at the structure before I look at the person standing closest to it, because blame explains nothing and structure explains almost everything.
Most new problems aren't new. They're a known shape wearing unfamiliar language, a familiar failure mode showing up in a system nobody has mapped yet. I'd rather recognize the pattern and translate it into the specifics of what's in front of me than invent a new framework to feel original. Originality is overrated. Fit is not.
Confidence is easy to project and frequently wrong. Calibration, knowing exactly how sure you should be given what the evidence actually supports, is harder to fake and far more useful. I trust a well-calibrated maybe more than a confident yes, and I trust people who can tell me the difference more than people who can't.
A clean org chart, an orderly roadmap, a plan that sounds good said out loud, none of that guarantees it reflects what's actually happening. Legibility is a presentation problem. Truth is a different, harder problem, and the two get confused constantly because legible things are easier to reward. I optimize for the second one, even when it costs me the first.
As more of the work gets generated rather than made by hand, drafted, modeled, summarized, decided on, the question that matters most is who owns what comes out of it. Generation is not the same as ownership. A tool can produce the option. A person still has to be named as the one who chose it, and that naming is the actual work now, not an afterthought to it.
ALSO, FROM STEPHANIE
The Observatory, a newsletter on product leadership, and The Practitioner's Field Guide, a field guide for experienced product managers looking to level up their rapid prototyping.
Both come from the same thinking that shapes the client work above.