How to build minimum lovable products and grow as a PM

Executive overview

Most PMs jump to solutions before understanding the problem. The real job is to understand users deeply, edit possibilities, and lead through influence — not authority.

Minimum lovable product replaces MVP as the standard: do fewer things at a high quality bar rather than many things partially. Know why users love your product, then double down on that core instead of chasing adjacent bets.

The most common PM mistakes

• New PMs attach to a solution before understanding the problem — the core thing to un-teach
• PMs expect authority over what gets built; the job is actually influence and editing, not control
• Jumping to solution space without validating unit economics leads to costly failures
• Sunk cost fallacy extends failing bets — pre-define go/no-go milestones at every quarter

Minimum lovable product vs MVP

• MVP sets a low quality bar; MLP asks what quality actually resonates with your users
• MLP is context-dependent: if users are replacing spreadsheets, the bar is lower; if users are designers, it's higher
• Better to do five things excellently than 15 things adequately — users notice the difference
• "Pixie dust" moments — keyboard shortcuts, pre-populated templates — create disproportionate love
• If you can't reach MLP internally, decide whether your ecosystem can close the gap

The Airbnb Plus failure

• Airbnb Plus tried to solve trust through physical home inspections — expensive and unscalable
• The real problem: guests didn't know what they'd get; better reviews and structured host onboarding were the right solutions
• WeWork made the same error: over-indexed on tech when the core was inventory management
• Inspections cost more than lockboxes or local cleaning partnerships — cheaper solutions existed
• Unit economics must work at the beginning, not at hypothetical future scale
• When pushing back on a founder, return with the spirit of their goal plus better options

Roadmapping and prioritization

• A roadmap is a story, not a spreadsheet — articulate themes so the team understands why, not just what
• RICE scores and impact/effort columns don't replace a narrative
• Write roadmaps as docs, not decks — docs scale better in async and remote cultures
• Link out to live Jira tickets rather than static snapshots that go stale
• Themes should change when you learn major new things about users — the story absorbs new inputs

OKRs

• Start from qualitative clarity: what would make you say "we crushed it"?
• Sandbagging OKRs to stay green is a company-level innovation failure
• Prefer red OKRs with clear learnings over green OKRs that signal nothing
• Break ambitious north stars into quarterly milestones with explicit go/no-go decisions
• Culture must not punish ambitious misses — risk-taking requires psychological safety

Career acceleration for PMs

• Become known for one thing: complex launches, technical depth, regulatory work, execution — then get more responsibility
• Build a reputation that earns you bigger projects, not a title that assumes authority
• Early career: analytical strength and execution compound fast
• As you move into leadership, the thing you're known for shifts — flex the core strength into new forms

The WeWork year

• Over-hiring ahead of validated milestones is a structural risk — laying people off is a permanent cost to leadership credibility
• Empathy is a leadership competency: a team in crisis needs a leader who considers visa timelines and personal situations
• Unlock hiring gates tied to results, not ambition
• Big visions don't require big teams — WeWork needed better inventory tools, not a platform engineering org

First 90 days as a product leader

• Prioritise building contacts across functions and levels — not just your direct team and peers
• Talk to long-tenure engineers; they know what's hard about the tech stack
• Treat trust as a bank account: deposit before you withdraw — pushing for change too early costs more than it gains
• Set a plan before any leave or transition: assign research tasks, flag strategic gaps, surface blockers to the board
• The biggest trade-off: deep product knowledge vs. organisational context — choose based on your team's existing expertise

Core lesson across Dropbox, Airbnb, WeWork, Webflow

• Dropbox: chasing Slack instead of investing in sync performance; people loved the simplicity
• Airbnb: inspecting homes instead of deepening discovery, reviews, and host onboarding
• WeWork: platform engineering instead of inventory management excellence
• Webflow: investing in non-designer features instead of doubling down on the designer and CMS

The common principle: understand why users love you, double down on that, and build adjacencies from strength — not from competitive fear.

Asking for help as a leadership principle

• The best leaders explicitly say "I don't know" and ask their teams, peers, and mentors
• Asking for help produces better answers than solving alone — and models the behaviour you want from your team
• Apply it to strategy: AI is changing weekly; no product leader has complete context alone