Don't prove value, create it: Matt LeMay on product management and Lean Startup

Executive overview

Product teams drift into defending their work rather than driving business impact. The result: vanity metrics, cascading OKRs nobody reads, and experiments that prove things in the abstract instead of creating real value now.

The fix is an entrepreneurial mindset — asking "would a CEO fund our team?" and running experiments that ship value to customers today, not someday.

Matt LeMay argues that product management is a business-accountable generalist role, and that accountability to business impact is both the hardest part and the most liberating one.

Business accountability vs. viability

• Viability is not "can we build this?" — it's "does this justify what the business invested?"
• You cannot account for viability without first knowing what the business specifically needs: growth, revenue, new business model exploration, or something else.
• 10 users sounds exciting until you ask whether that number justifies the team's existence.
• Most orgs skip the open conversation about how success is actually being measured.
• Vanity metrics and defensibility metrics are closely related — both protect work rather than evaluate impact.

Innovation accounting in practice

• Most teams struggle because they never explicitly state what they expected before shipping.
• Assumption mapping forces assumptions into the open: here's what we expect, here's how we'll adjust if we're wrong.
• The best strategic thinking is happening at the team level, not in executive strategy documents.
• Effective teams don't wait for a perfect strategy — they take the ambiguous strategy and ask: here are three paths, which one does this actually lead us down?
• Short-term vs. long-term accounting tension is real: quarterly revenue goals and five-year vision cannot coexist without deliberately resourcing them separately.

Don't prove value — create it

• Don't run experiments to validate whether something could theoretically create value in the future.
• Run experiments with the goal of creating value in the market right now.
• At MailChimp, a team shipped a long-requested feature on existing infrastructure with feature flags — got it in front of users fast rather than architecting it perfectly over a year.
• Real value in market, with real users responding, blows theoretical conversation out of the water.
• Shopping "validated learnings" to other teams rarely works. Showing a live thing people are already using does.

Making learning part of the loop

• When learning is treated as a separate, discrete activity, it gets deprioritised.
• Build-measure-learn is one loop, not three phases — separating "learning time" from "building time" breaks the model.
• People avoid user research because it means giving up control: you can't defend your decisions, you have to just listen.
• Bad user research is better than no user research — but teams are underprepared for the emotional discomfort, not the methodology.
• Approaching users requires the opposite mindset from approaching stakeholders: no cards, no answers, just observation.

The OKR trap and keeping altitude

• Organisations that want to be impact-driven while running 500 OKRs are not going to be impact-driven.
• The cognitive overhead of managing cascading low-level goals becomes a full-time job that crowds out actual impact thinking.
• Product leaders need to hold the conversation at the right altitude: what impact should these teams drive, how are they measuring it, and what do they need to get there?
• The entrepreneurial mindset replaces the cascade question ("how do we align our 49 OKRs?") with the business question ("how do we do stuff that creates value?").

Frameworks vs. outcomes

• Organisations confuse implementing a framework with achieving the outcomes the framework was designed to produce.
• Agile at scale can coexist with strategic confusion and business failure.
• The same pattern is repeating now with AI adoption — FOMO is not a strategy.
• Frameworks need on-the-ground coaching and support from people who have been through it — not silver-bullet, one-size-fits-all deployment.
• The right question is always: what do you actually want to achieve, and how will you know if this worked?