Minimum Usable Product
From product-out to user-in perspectives
Minimum viability is very much a product-outwards perspective: what’s the least amount of work we can do to find out whether going down this line of thinking is a business idea that’s worth being invested in. It has nothing to do with viability for users.
It’s a well worn notion that the right way to build a product is to iterate through stages of development, where at each stage you deliver something that, on it’s own, provides real incremental value by accomplishing the user’s goal appreciably faster/cheaper/better than was possible before. A functional approach.
What makes a product viable for use is:
- Being more usable at each stage of creation
- Creating experiences of greater efficacy at every turn
- Providing incremental wins at each step tbat add up to something much greater — a sense of joy. [Something I’ve seen enough times to say it with a straight face.]
This is distinctly not a product-out orientation — but instead a user-inwards orientation.
We have to make up for the pain we put users through — our stumbling attempts at building something useful, the suffering of (re)learning how to do something, breaking their workflows — with some pleasure on the other side.
Leading to questions that should be answered:
- What is the qualitative, subjective improvement from the perspective of the user? Does it feel better? Does it yield results of higher quality?
- What is the quantitative, objective improvement from the perspective of the user? Does it get the task done faster? Does it yield more results?
- What is the quantitative, objective improvement from the perspective of the product? Is it faster? Does it do more of what users want?
Programming notes: this post is n in a series of indeterminate length on Product topics mainly for startup people, mainly leadership, mainly coming from non-GTM backgrounds.
Posts in this series
- Product 101 for Engineers
- Product 102 for Engineers
- Minimum Usable Product
- Product, Marketing, and the Art of Managing Expectations
Related series (and templates) on Marketing
- Marketing 101 for Engineers: A Functional Introduction
- Marketing 102 for Engineers: Roughing Out a Funnel
- Marketing 201 for Engineers: Messaging & Positioning
- Marketing 202 for Engineers: Launching
- Marketing 203 for Engineers: Sales Enablement
- Marketing 204 for Engineers: Generating Demand
- Marketing 301 for Engineers: Strategy & Planning
- Marketing 302 for Engineers: Hiring Marketers
- Marketing 303 for Engineers: Pricing Frame
- Marketing 401 for Engineers: Stages of GTM
- Marketing 402 for Engineers: Diagnostics & Troubleshooting
- Marketing 403 for Engineers: Answering Founder FAQs
- Sales 101 for Engineers: A Functional Introduction
- PR 101 for Engineers
- Analyst Relations 101 for Engineers
- Basic Messaging Template [Google Doc]
- Basic Funnel Metrics Template [Google Sheet]
- Basic Launch Timeline Template [Google Doc]
- Basic Battlecard Template [Google Doc]
- Detailed Battlecard Template [Google Doc]
- Basic Marketing Calendar Template [Google Sheet]
- Basic Marketing Ladders Template [Google Sheet]
Reading List
- The HEART framework
- Google Research: Measuring the User Experience on a Large Scale: User-Centered Metrics for Web Applications
