4.4 MVPs, Pretotyping, and Pivot vs. Persevere Decisions

4.4 MVPs, Pretotyping, and Pivot vs. Persevere Decisions

Executive Takeaway: Most new product ideas fail—not because of poor technical execution, but because they simply fail to solve a real problem for real customers. Alberto Savoia's pretotyping framework forces teams to validate 'The Right IT' before spending millions 'Building IT Right.' In Professional Scrum, an MVP is not a sloppy, buggy prototype; it is a fully 'Done,' high-quality increment designed specifically to maximize empirical learning. Grounded in telemetry, the Product Owner makes objective Pivot, Persevere, or Kill decisions without falling prey to the sunk-cost fallacy.

In his groundbreaking work on product innovation, The Right It, Alberto Savoia articulated The Law of Failure:

$\text{The Law of Failure: } \text{Most new product ideas will fail in the market, even if they are flawlessly executed.}$

Historical empirical data across startups, venture capital portfolios, and corporate enterprise innovations reveals that approximately 80% of new product launches fail. The devastating realization for software teams is that failure is rarely caused by buggy code, poor architectural scalability, or missed deadlines. Most products fail simply because they are the Wrong IT—products that customers do not want, do not need, and will not pay for. Building the Wrong IT flawlessly on time and on budget is the ultimate form of organizational waste.

---

Savoia's Pretotyping: Validating "The Right IT"

To prevent teams from sinking months of engineering effort into building the Wrong IT, Savoia developed the discipline of Pretotyping (a portmanteau of pretend and prototype).

Pretotyping is defined as:

"Testing the initial appeal and actual usage of a potential new product by simulating its core experience with the smallest possible investment of time and money."

The Fundamental Distinction: Prototype vs. Pretotype

---

The Hierarchy of Evidence: Opinion Data vs. "Skin in the Game"

Savoia differentiates between two types of customer information: OPD (Other People's Data / Other People's Opinions) and YODA (Your Own Data).

• OPD (Opinions and Surveys): When you ask people if they like an idea, they are giving you their opinion. Opinions are notoriously cheap, polite, and unreliable. Market research surveys and focus groups are littered with false positives because answering "Yes, I'd definitely buy that" costs the participant nothing.
• YODA (Behavioral Skin in the Game): Authentic validation occurs only when customers give up something of real value to acquire or use your product. Savoia calls this Skin in the Game.

                     [ THE SKIN-IN-THE-GAME LADDER ]
                                    ▲
                                    │  [LEVEL 4: HARD COMMITMENT]
                                    │  Non-refundable deposit, enterprise LOI,
                                    │  credit card pre-authorization, data migration.
                                    │
                                    │  [LEVEL 3: PERSONAL REPUTATION]
                                    │  Referral to boss, sharing on LinkedIn,
                                    │  scheduling team calendar invite.
                                    │
                                    │  [LEVEL 2: VALUABLE ASSETS]
                                    │  Work email address, phone number,
                                    │  60 minutes of time for a workshop.
                                    │
                                    │  [LEVEL 1: CASUAL ENGAGEMENT]
                                    │  Website click, social media like,
                                    │  anonymous poll response. (Weakest)

An advanced Product Owner never prioritizes a backlog item based purely on survey results. The PO insists on seeing Level 3 or Level 4 Skin-in-the-Game data before authorizing full development.

---

Pretotyping Methodologies in Practice

Product Owners leverage several established pretotyping patterns to validate market demand rapidly:

1. The Fake Door / Painted Door

• Mechanism: Offering a button, link, or navigation menu item for a capability that does not yet exist. When the user clicks the element, a polite, transparent modal appears: "We are currently piloting this capability with select accounts. Tap here to join the priority waitlist."
• Telemetry Captured: Click-through rate (CTR) of users who demonstrated authentic behavioral intent to use the capability, along with email waitlist conversions.

2. The Mechanical Turk / Wizard of Oz

• Mechanism: The user-facing interface appears fully automated and software-driven, but the entire back-end logic, data processing, and execution are performed manually by human operators.
• Famous Example: Nick Swinmurn founded Zappos using a Wizard of Oz pretotype. He did not build an enterprise warehouse or logistics software. He walked to local shoe stores, photographed shoes, posted them on a rudimentary website, and when an order came in, he bought the shoes at retail and mailed them. He proved customers were willing to buy shoes online before writing inventory code.

3. The Concierge Service

• Mechanism: Providing the service 100% manually, transparently, and personally to a small group of early-adopter customers without any software interface.
• Value: Highly intimate, high-touch learning. The team observes every nuance of the customer's workflow, pain points, and objections before automating the process into software.

4. The Infiltrator / Impersonator

• Mechanism: Inserting your offering into an existing physical or digital platform or bundling third-party SaaS tools together with Zapier scripts to test whether users will adopt the combined service.

---

Defining the Minimum Viable Product (MVP) in Professional Scrum

The term Minimum Viable Product (MVP), coined by Frank Robinson and popularized by Eric Ries in The Lean Startup, is frequently abused in enterprise software.

What an MVP Actually Is:

"The smallest package of capabilities or increment necessary to initiate empirical learning and test a foundational business hypothesis with real users."

The Two Deadly Misconceptions of MVP:

1. The 'Sloppy Code' Fallacy: In mature Scrum, an MVP is never an excuse for buggy, half-finished code, missing automated tests, or unmaintainable architectural shortcuts. In Scrum, every released increment—even an MVP—must satisfy the Scrum Team's Definition of Done (DoD). The Increment must be potentially releasable, thoroughly tested, secure, and maintainable. The scope is minimal; the quality is uncompromising.
2. The 'Phase 1 Waterfall' Fallacy: An MVP is not the first milestone of a predetermined, fixed-scope 18-month plan. An MVP is an empirical learning instrument. What you learn from the MVP dictates whether you build Phase 2 at all.

   WRONG: BUILDING WATERFALL PIECES                 RIGHT: INCREMENTAL VALUE SLICE
  (Wheel -> Axle -> Chassis -> Car)              (Skateboard -> Scooter -> Bike -> Car)
  
  Sprint 1: [ Wheel ] (Useless to customer)      Sprint 1: [ Skateboard ] (Basic mobility)
  Sprint 2: [ Axle  ] (Useless to customer)      Sprint 2: [ Scooter    ] (Steering added)
  Sprint 3: [ Chassis] (Useless to customer)     Sprint 3: [ Bicycle    ] (Efficiency added)
  Sprint 4: [ Car   ] (Finally usable)           Sprint 4: [ Motorcycle ] (Engine added)

In Professional Scrum, the MVP is sliced horizontally and vertically: it provides a complete, working end-to-end slice of functionality that delivers actual human utility and collects actionable telemetry.

---

The Empirical Decision Nexus: Pivot, Persevere, or Kill

Once an MVP or experiment is released to live users, the Product Owner faces the ultimate strategic crossroad. Grounded in telemetry—specifically Dave McClure's Pirate Metrics (AARRR: Acquisition, Activation, Retention, Referral, Revenue)—the PO must decide to Pivot, Persevere, or Kill.

                             [ EXPERIMENT TELEMETRY INSPECTED ]
                                             │
         ┌───────────────────────────────────┼───────────────────────────────────┐
         ▼                                   ▼                                   ▼
   [ PERSEVERE ]                        [ PIVOT ]                            [ KILL ]
  Metrics hit/exceed target.     Core hypothesis falsified,        Systematic failure across
  Scale development, optimize    but adjacent need uncovered.      hypotheses. Zero traction.
  features, expand segments.     Change strategy, keep vision.     Stop waste immediately.

1. Persevere (Double Down on Validated Traction)

• Condition: Leading metrics hit or exceed hypothesis thresholds. Users activate rapidly, return frequently (high retention), and demonstrate authentic skin in the game.
• Action: Invest developer capacity to harden architecture, optimize usability, and scale the feature set in upcoming Sprints.

2. Pivot (Strategic Course Correction)

• Condition: The initial hypothesis is falsified, but empirical telemetry reveals an unexpected, viable adjacent opportunity, or users love the product for a completely different purpose than expected.
• Definition: A Pivot is a structured course correction designed to test a new foundational hypothesis about the product strategy, customer segment, engine of growth, or value proposition—while keeping the overarching Product Vision intact.

Common Product Pivots:

• Zoom-In Pivot: Refocusing on a single standout feature that gained traction, turning it into the entire product (e.g., Slack emerging from an internal chat tool within a failed multiplayer game).
• Customer Segment Pivot: Realizing that while individual consumers ignore the product, enterprise compliance officers desperately need it.
• Value Capture Pivot: Changing the revenue model (e.g., transitioning from ad-supported freemium to premium recurring enterprise subscriptions).
• Engine of Growth Pivot: Shifting from viral/social growth to a direct sales enterprise motion.

3. Kill (The Courageous Decision to Stop Waste)

• Condition: Multiple iterations and pivots fail to generate traction; customer retention is flat; users exhibit zero skin in the game; the opportunity cost of continuing exceeds the potential value.
• The Sunk Cost Fallacy: The greatest psychological enemy of the Product Owner is the sunk cost fallacy ("We have already spent $800,000 and six Sprints on this portal, so we cannot cancel it now").
• The Advanced PO Stance: Sunk costs are gone forever. An elite Product Owner has the courage to declare a feature or product dead, gracefully sunset it, and reallocate the Scrum Team's precious capacity to high-potential Product Goals.