Tag Archives: Stakeholder Management

The original meaning of MVP (and How it Drifted)

Traditionally, MVP (Minimum Viable Product) meant:

“The smallest thing you can put in front of users to maximize learning with minimal effort”

All of us have very likely heard or read about Dropbox’s MVP, which was essentially a PowerPoint deck explaining the notion of file sharing. That was probably one of the few instances where MVP actually stood for what it means.

What it is not:

  • A sellable SKU
  • A fully supported product
  • A revenue-ready launch

Over time, however, MVP became shorthand for

  • “Something sales can demo”
  • “Something Marketing can announce”
  • “Something support won’t revolt over”

That shift is where the confusion and friction commence!


MVP is a Supply Chain, Not a Feature

Like any good supply chain, MVPs do not exist in isolation. They require alignment across a lineup of stakeholders, each optimizing for different signals:

The Stakeholder Stack

All product management training states that one of the key value propositions of being a product manager is stakeholder management. I have my interpretation of the term “stakeholder management,” as it sounds outdated, reminiscent of the year 1995. My term is “Stakeholder Stack.” It is inspired by the term “technical stack,” and there is a reasoning behind it. Before we get to the reason, let us understand this stakeholder stack.

StakeholderPrimary Concern
Engineering (Foundation Layer)Technical feasibility, architecture integrity
Design Partners / Early UsersDoes this solve a real problem?
Product & UXUsability, workflows, behavioral signals
Community/DevRelAdoption friction, feedback loops
MarketingNarrative clarity, positioning
Sales/RevOpsSellability, repeatability
Support & Customer SuccessOperational burden, scale readiness

As you can see, all these stakeholders matter, but not at the same time. Here is an example of something that has worked for me throughout my career.

Power/Interest Grid

High Power, High InterestHigh Power, Low Interest
• CPO (Product Strategy)
• CTO (Technical Feasibility)
• Engineering Managers
• Product Manager (GA Owner)
• CFO (Budget Impact)
• Legal/Compliance
• Security Team
Low Power, High InterestLow Power, Low Interest
• Customer Success
• Sales Teams
• Documentation Team
• Key Beta Customers
• Industry Analysts (inform only)
• Technology Partners (coordinate)

Engagement Strategy by Stakeholder

1. Manage Closely (High Power/High Interest)

  • Weekly status updates
  • Direct involvement in decision-making
  • Early escalation of risks

2. Keep Satisfied (High Power/Low Interest)

  • Monthly executive summaries
  • Gate reviews at key milestones
  • Escalate only critical issues

3. Keep Informed (Low Power/High Interest)

  • Regular communication cadence
  • Solicit feedback actively
  • Include in testing/validation

4. Monitor (Low Power/Low Interest)

  • Periodic updates
  • Self-service information access
  • Engage as needed

Why is this stakeholder management element vital in the context of discussing MVPs? Let us get to that.


The Core Disagreement: Sell versus Learn

Stakeholders are vital to understanding what an MVP is going to be, and they agree on what an MVP is but disagree on why it exists.

Two legitimate, but conflicting, definitions

  1. MVP as a learning vehicle
    • Goal: Accelerate validated learning
    • Audience: Design partners, early adopters, internal teams
    • Characteristics:
      • Rough edges tolerated
      • Limited support expectations
      • Fast iteration steps
    • Enables
      • Early engagement during development
      • Architectural and UX corrections before scale
      • Lower long-term risk
  2. MVP as a Commercial Artifact
    • Goal: Enable Selling
    • Audience: Broader Market
    • Characteristics:
      • Market-ready messaging
      • Support and success coverage
      • Sales Enablement
    • Requires:
      • Strong cross-functional readiness
      • Higher cost of change
      • Slower learning velocity

Neither is wrong, but they are not the same thing!


The Real Failure Mode

Most organizations fail at MVP because they try to:

Optimize for selling while pretending that they are focusing on learning.

This creates:

  • Over-engineered “MVPs”
  • Premature go-to-market pressure
  • Feedback filtered through sales conversations instead of usage signals
  • Teams arguing past each other using the same acronyms

A few things to note:

  • If the customer is willing to pay for the vision and use the MVP, you are in a rare and excellent position to get the product out and use the MVP learnings towards the greater goal.
  • I hate acronyms; they generally make people feel stupid and are not inclusive by nature. These acronyms are created specifically for communication within the organization, while industry-standard acronyms, such as TCP/IP, are acceptable.
  • Do not optimize the MVP for all stakeholders at the same time; at different stages, different stakeholders matter.

A More useful framing

Instead of asking, “Is this an MVP?” ask:

  • What are we trying to learn?
  • Who must be involved now, and who can wait?
  • What commitments are we implicitly making by calling this an MVP?

A product intended for accelerated learning can and should engage stakeholders early, but selectively:

  • Engineers and design partners early
  • Community next
  • Only when the intent shifts towards selling do you include sales, marketing, and support.

** If it is a product you are not charging for but is a critical element of the experience, you still include sales, marketing, and support when the intent shifts towards broad-based access.


The Bottom line

An MVP is not a thing. It is an intent.

Unclear intent and lack of stakeholder involvement cause confusion. When the right stakeholders are not engaged, then different parts of the organization assume different definitions. Then we have a situation where the “Highest Paid Person’s Opinion” decides the fate of the MVP definition.

Clarity on what you are building an MVP for is what allows the entire supply chain to line up and move fast without breaking trust.

This remains true even in an AI-driven world, where AI agents can generate content and checklists while maintaining a clear intent and context window. Otherwise, what you get is slop and not anything useful.