Product Philosophy

A summary of how I approach product work—from problem-first thinking to empowered teams that win and beyond.

This page shares how I personally think about product work — not a rigid methodology or framework to copy, just lessons from years of what actually works (and what doesn’t) for me. Your experience may differ, and that’s perfectly fine.

Start with the Problem — Not the Solution

Most product failures I’ve seen come from jumping straight to a solution (“Let’s build an analyst portal”) instead of clearly defining the actual problem.

A real problem sounds like: “Analyst lose 2–3 hours every week hunting for docs scattered across five different systems.”

Before designing anything, force yourself to answer:

What exact pain or friction exists right now?
Who feels it, and how frequently?
What’s the cost / impact of doing nothing?

It feels obvious, but it’s surprisingly difficult to stay disciplined about. Our instinct is to jump to solutions the moment someone says “we need better monitoring.” The strongest specs always begin with a sharp, honest problem statement. If you can’t clearly write the problem, you’re almost certainly not ready to build anything.

Outcomes Over Outputs

There’s a difference between shipping things and changing things. Launching a new dashboard is an output. Reducing incident response time by 40% is an outcome. I try to focus relentlessly on the change we want to see in the world, not the activities or deliverables along the way. “Launch X” or “Ship Y” are tasks, not goals. The goal is what happens after you ship. Did behavior change? Did the pain go away? Did customers succeed in ways they couldn’t before? This distinction matters because it keeps us honest about whether we’re actually solving problems or just staying busy.

Empowered Teams Build Better Products

I strongly believe in Daniel Pink's assertion that lasting motivation comes from Autonomy, Mastery, and Purpose.

That belief drives how I want product teams to work. Instead of handing teams a fixed feature roadmap, give them:

A real problem worth solving
Enough strategic context to solve it intelligently

Quoting Marty Cagan: “An empowered team is given a problem to solve and they get to figure out the best way to solve it.”

As a product leader my job is to supply:

Strategic context — where the company is headed and why
Clear outcome goals — the measurable change we want to create
Guardrails — hard constraints, key dependencies, and absolute no-gos

Then step back and let the team own the “how.”

This isn’t abandonment. I stay engaged — dive into details, ask hard questions, suggest ideas, clear roadblocks — but final decisions live with the people closest to the users, data, and day-to-day reality.

Collaboration Over Consensus
I actively want diverse perspectives in decisions — the best insights frequently come from unexpected corners:

An engineer spotting patterns in support tickets
A designer observing real user sessions
A customer success rep hearing the same pain repeatedly

Collaboration fuels better ideas. Consensus kills speed. As Seth Godin says: “Nothing is what happens when everyone has to agree.” At some point a clear decision must be made — and it should come from the person(s) closest to the problem and the data, not the most senior person or the loudest voice in the room.

That’s why I favor lightweight frameworks like DACI (Driver, Approver, Contributors, Informed): Explicit decision roles → faster calls → far less second-guessing and resentment.

Roadmaps Are Road Signs Into the Fog

I think about planning through the lens of The Fog of War. In strategy games, the fog of war hides parts of the map you haven’t explored yet. You can’t see what’s there until you move toward it.

Product planning is the same. We can’t predict the future—we can only make the best decisions with the information we have right now. Customers will surprise us, technology will shift, and the market will change in ways we didn’t anticipate.

So I treat planning documents as “a road sign into the fog.” We make sure the direction and first few steps are known, and then we add and edit as the fog starts to lift. This is why I prefer Now/Next/Later roadmaps over deadline-driven quarterly roadmaps:

Now — what we’re actively working on (limited to 1–2 things per team)
Next — what’s coming in the next few weeks, fully spec’d and ready to go
Later — what we believe is important, but may shift as we learn more

The further out you go, the more likely things will change. That’s not a bug—it’s an honest reflection of reality.

Deadline-Driven Development Is Fraught

I’ve grown very skeptical of arbitrary, top-down deadlines. Dates matter — especially with real external commitments or hard dependencies — but too many are set without meaningful input from the people who actually do the work.

When that happens, teams face an ugly choice:

Hit the date → sacrifice quality, rack up tech debt, cut corners
Protect quality → miss the date and look “unreliable”

The shipped result is almost always weaker than it could have been with proper time.

I much prefer high-integrity commitments:

Teams get real time to understand and scope the work
They set (or help set) the date they believe they can hit with quality
Accountability comes from ownership, not pressure
If reality shifts (scope creep, blockers, new info), we discuss openly and adjust — no pretending an impossible date is still realistic. This approach produces better work, healthier teams, and far less burnout.

Teams Make Better Products in Calm Environments

Airports taught me this: no running. Running only happens when something already went wrong — a delay, a bad plan, a missed detail. The real goal is arriving prepared enough that you can walk calmly to the gate.

Product work works the same way. Occasional urgency is inevitable. Chronic urgency is a symptom of deeper dysfunction. When teams live in permanent crisis mode:

They make sloppy mistakes
Deep thinking becomes impossible
Burnout sets in
People eventually leave

I’d rather prioritize calm, sustainable quality over fake speed:

Take real time to understand the actual problem
Give space for focused, uninterrupted deep work
Build it right the first time instead of piling up tech debt

It feels slower in the moment. It’s dramatically faster — and healthier — over months and years.

Calm teams don’t just ship more; they ship better, and they stick around.

Choose Your Battles Wisely

Product managers are drawn to wicked problems — messy, ambiguous, high-stakes challenges with no obvious answer. It’s part of what makes us effective. But it can become a trap. We have a finite supply of “life force” — energy, focus, willpower. Not every hard problem deserves it.

Some battles are worth the fight:

Complex issues where we have genuine influence
Problems where success would create real, meaningful impact

Others are traps:

Hard problems blocked by politics, lack of alignment, or zero executive buy-in
Situations where effort almost certainly won’t move the needle, no matter how brilliantly we execute

The skill isn’t avoiding difficulty. It’s ruthlessly selecting the right hard problems — the ones where our investment of time and energy has a realistic shot at paying off.

Process Should Serve the Team, Not the Other Way Around

I’m not religious about any particular framework — OKRs, Scrum, Kanban, Shape Up, etc. They’re just tools. The only question that matters is: Does this help our specific team do better work in our actual context?

A few lightweight approaches I’ve found consistently useful:

W Planning Leadership shares strategic context → teams propose concrete ways to hit the goals → back-and-forth refinement. Alignment without top-down diktat.
EOS Vision & Focus Simpler alternative to full OKRs: one long-term vision, clear quarterly priorities (“Rocks”), and a live issues list to keep blockers visible and resolved.
Product Discovery Structured way to stay problem-first: frame the real pain, explore possible solutions, test assumptions, then prioritize — before anyone writes a single line of code.

The thread running through everything I like:

Understanding > blind action
Collaboration > hierarchy
Flexibility > rigid dogma

Process exists to make the team more effective — never the reverse. If it starts feeling like the tail wagging the dog, change it

Learn to Love Documentation

Work in the open. Document not just what we decided, but why — the full context, trade-offs, and reasoning.

This creates organizational memory. A year later, when someone asks “Why are we doing this?”, the answer exists. Especially critical for strategy: forgotten context is why strategies flip-flop constantly.

Documentation isn’t red tape — it’s a generous gift to your future self and teammates.

Strategy Is Collaborative

Product strategy should never be three execs in a room with a whiteboard. The sharpest insights usually live with the people closest to customers and code. Involve the full team — engineers, designers, support, marketing — early and often. It’s slower and messier upfront, but produces stronger strategies and real buy-in.

(W Planning embodies this: leadership sets direction, teams own the how → true partnership.)

Iteration Over Big Bang

Ship small. Ship often. Learn fast. I’d rather release a tiny piece that delivers real value today and iterate on real feedback than spend months building “the full thing” only to learn we misunderstood something fundamental.

Long delays = massive accumulated risk. Each release must stand alone and provide standalone value — but breaking big bets into small, learnable steps wins almost every time.

The Person Comes First

Products are built by humans. Humans do their best work when they’re happy, healthy, and feel genuinely supported.

If someone is struggling — work stress, personal life, mental health — that takes priority over any deadline. Adjust timelines. Redistribute load. Protect the person.

This isn’t soft-hearted charity. Happy, rested teams consistently build better products. Full stop.

In Summary

Boiled down to what matters most to me:

Understand deeply before you build — always start with the real problem.
Trust and empower teams — give context + clear goals, then let them own the how.
Be honest about uncertainty — roadmaps are educated guesses; treat them that way.
Obsess over outcomes, not outputs — impact > shipping.
Choose calm over constant crisis — sustainable pace beats burnout heroics.
Work openly — document reasoning, collaborate widely, bring people along.
Adapt ruthlessly to your reality — frameworks are tools, never dogma.

None of this is revolutionary. It’s what I’ve learned (and stolen) from smart people, great books, and hard-won experience — distilled into what actually works for me.

Take what clicks for you. Adapt it. Ignore the rest. That’s the point.