Core Beliefs

Product leadership isn’t about shipping features or following frameworks. It’s about creating the conditions where great products emerge naturally—through trust, evidence, and relentless focus on what actually matters.

These beliefs have been forged over 30 years working in dysfunctional organizations, resistant cultures, and hostile environments. They’re not theory. They’re survival tools that became principles.

Build Trust, Not Features

Everything starts with trust. Not user trust in your product—though that matters. I mean the trust between people building the product. In dysfunctional organizations, trust is the scarcest resource. People hide mistakes, hoard information, and cover their butts instead of solving problems. The organization optimizes for not getting blamed instead of creating value. My job isn’t to ship features. It’s to create environments where:

• “I don’t know” is a strength, not a weakness, because we can learn together
• People bring problems before they become crises
• Failure is data, not career-ending - in fact failure = learning
• Disagreement is productive, not dangerous - it’s HEALTHY debate

When trust exists, everything else gets easier. Discovery becomes honest. Priorities become clear. Teams move fast because they’re not navigating political minefields.

When trust doesn’t exist, no framework or process will save you. You’ll build the wrong things efficiently while talented people burn out or leave. I’ve built trust-based subcultures inside toxic organizations. It’s possible. It’s slow. That’s why it’s important for trust to be built from the top. It all starts with vulnerability.

The Leadership Contract

Trust is bidirectional. Leaders who understand this get dramatically different results from their teams.

After 30 years, I’ve learned that when a team underperforms, the first question isn’t “what’s wrong with the team?” It’s “what did leadership fail to provide?”

Leadership’s job is to come to the team with:

• A problem or opportunity — not a solution
• Strategic context — how this opportunity aligns with organizational goals and where the guardrails are
• The “who” — who is experiencing this problem, who will benefit from solving it
• The cost of inaction — what happens if we don’t act
• A definition of success — what does “solved” actually look like
• A time horizon — how much investment is worth making before we know if this is working

When leadership brings all of this, something remarkable happens. The team brings back creativity, technical ingenuity, and options: in one sprint we can validate this; in two, we can build this; in a quarter, we can ship this. They take calculated risks. They make bets. That’s where the real value gets created.

But when leadership brings a solution instead, all bets are off. Literally.

A solution signals — whether leadership intends it or not — we don’t trust our team to find the right answer. The conversation immediately shifts from outcomes to estimates. Engineers spend days calculating how long the solution will take to build. Nobody asks whether it should be built at all. The work becomes soul-crushing precisely because the most important question has already been answered for them.

The Formula 1 Problem

I’ve lived this scenario more times than I care to count. Leadership arrives with a mandate: build us a Formula 1 car. The team executes. Twelve to eighteen months later, it’s delivered — exactly to spec, beautifully engineered. Customers and users ignore it. Sales can’t move it. Not a single contract gets signed.

Of course not. Nobody stopped to ask what problem the Formula 1 car was solving.

I was the person on those teams who started asking. I’d get a blank stare. That blank stare is one of the most expensive expressions in business — it means someone is about to spend the organization’s money testing an assumption with a production budget.

Most leadership ideas are assumptions. The visionary leader who sees the future clearly is, nine times out of ten, making a very confident bet. That bet might be worth pursuing right now. Or it might be a $5 million waste. The only way to know is to test it — and the only way to test it is to define the problem before proposing a solution.

Given the right context, the team doesn’t build a Formula 1 car. They ask who needs to go where, when, and why. They learn it’s a suburban customer getting groceries delivered between 6:30 and 7:00 PM every other Friday, who also needs a ride afterward — and that the organization is focused on short-trip pickup and delivery. So they build a Honda CRV. It costs less, ships faster, fits the lane perfectly, and customers love it.

That’s not a lesser outcome. That’s product thinking working exactly as it should.

The leader’s job is to provide context and then get comfortable with uncertainty about what the team will build. In my experience, that uncertainty resolves into something better than what leadership imagined — and faster than anyone expected.

Evidence Over Assumptions

Most product failures don’t happen because teams build the wrong solution. They happen because teams never questioned whether they were solving the right problem. I’ve saved over $1.2 million by stopping projects that had no evidence to support them. Not because I’m smarter than anyone else—because I insisted on testing assumptions before committing resources. Evidence-based product development means:

Discovery before delivery, always Small bets to validate big ideas User research that asks “should we?” not just “how should we?” The willingness to hear “this is a bad idea” and act on it

The hardest part isn’t finding evidence. It’s building cultures where evidence is allowed to kill ideas people are attached to. Where “the data says no” overrides “the CEO really wants this.” I’ve watched organizations waste millions building features no one asked for, solving problems that don’t exist, and optimizing metrics that don’t matter—all because no one had permission to ask “but should we?” Evidence gives you that permission. And the courage to use it.

Outcomes Over Outputs

Feature factories are comfortable. You know what you’re building. Roadmaps look impressive. Stakeholders get their requests. Everyone feels productive. You’re also probably building the wrong things. Outcome-focused product development is uncomfortable. It requires:

• Saying no to features that don’t move the needle
• Measuring what matters, not what’s easy
• Focusing deeply on problems, not solutions
• Accepting that “we shipped nothing” might be the right answer

I drove a personnel system from paper workflows to 100% electronic submission by rejecting competing features and focusing on complete payroll integration. We could have shipped a dozen small features that made stakeholders happy. Instead, we shipped one complete solution that eliminated 400+ hours of annual manual work. That’s the difference between outputs and outcomes. Outputs are what you ship. Outcomes are what changes. Most organizations reward outputs because they’re visible and predictable. Outcomes require patience, discipline, and the willingness to look unproductive while you validate whether what you’re building actually matters. I optimize for outcomes. Even when it makes me unpopular. If you want outputs, don’t bother filling out my contact form. If you want to talk about transformation - and what outcomes are, I can’t wait to hear from you.

Ready to see how I put these principles into practice? Check out my case studies.