Minimum Viable Product
At a recent Agile Conference in Scandinavia, presenter Dr. Venkat Subramaniam said, “programmers should have the courage not to write code.” This applies to all startup product developers no matter what the product. Please. Stop.
You should be building out product features only if the following applies to you:
You know.
If you are still learning, you should not be building features; you should be building experiments (which may contain features). It’s an important distinction.
Think of your product as having an intrinsic feature threshold. This threshold maps to the pain or passion of your market segment; once that threshold is met and the pain is resolved, adding more features will not resolve more pain. This bears repeating:
Economists call this declining marginal utility—we go as far as to suggest that if you build features into your product, release them to the world, and do not measure whether they are used or desired, you are inflicting harm to your existing value proposition; that is to say, the marginal utility of too many features is negative.
Increasing stuff that doesn’t add value dilutes existing value. Period.
It’s also extremely wasteful. Your testing team is wasting time testing it. Your sales team is wasting time and money selling new unwanted features. Your marketing team is wasting time marketing it. Your support team is wasting time supporting it.
To know means the customer demand is pulling the features out of you. How do you know? By understanding the customers within your target segment deeply. You have knowledge and signal:
Your customers have been segmented into buckets grouped by pain or passion.
You can prioritize which segments are “high value;” key to growth.
You understand which customers are passionate about your product.
Feature requests, support needs, feedback, and engagement from these specific customers or channel partners is increasing and urgent.
The direction in which you’re being pulled (what and who) is congruent with your vision.1
What should engineers be doing if not building features? Plenty:
Fixing bugs and refactoring existing product.
“Going to the source”—in other words, going to the customer and learning about customer needs.
Serving on cross-functional teams charged with improving company operational processes.
Automating quality-assurance tests.
Designing and implementing new experiments related to existing products.
Experimenting with new, disruptive ideas.
Improving your shadow force.
These are not rhetorical suggestions. Leading organizations must adapt. The elimination of old-school silos—not through touchy-feely, new age, kumbaya, can’t-we-all-just-get-along idealism, but through building cross-functional teams charged with finding and eliminating business model bottlenecks—is the key to success in the value-creation economy.
Your First mvp
The minimum viable product (MVP) is your first attempt to deliver value to your customer. If you have made the effort to interact with potential customers and have run experiments testing your customer, problem, and solution assumptions, your first MVP will be the first effort to deliver validated value to a known customer.
In this context, an MVP is not a landing page or a mockup of your application. It’s not a model or nonfunctioning prototype. Your minimum viable product is comprised of the least amount of functionality necessary to solve a problem sufficiently such that your customer will engage with your product and even pay you for it, if that’s your revenue model.
It will take more than one try. You’re not going to nail it the first time out. In fact, you’re never done. In today’s value-creation economy, there’s no such thing as done, which is why you might as well get your product in the hands of a few customers as soon as possible. You won’t learn what you’re missing or getting wrong until you let someone try and use it. Hence the minimum in MVP.
Your product may or may not require an artful design, 42 features, beautiful packaging, a kickstand, and blue buttons to be viable to your chosen market profile. A viable product, at the very least, delivers just enough of its value proposition that customers will use it. The trick is admitting you don’t know all that’s required to be viable.
Releasing early to early adopters is the most efficient way to learn what’s required. Too much product hides the specific functionality that provides viability. The core functionality that provides value such that customers are satisfied because the product fulfills its promise forms the foundation of your future business.
It doesn’t guarantee high growth or even success, but you can’t achieve those without it.
Most failed startups fail in the MVP phase. Iteration through features can quickly become flailing, to the point where founders are no longer able to recall the vision or the original value proposition. Or perhaps the value proposition was vague from the outset!
Reid Hoffman, founder of LinkedIn, famously said “If you are not embarrassed by the first version of your product, you’ve launched too late.” The idea causes massive cognitive dissonance in the startup world. Entrepreneurs are scared that:
A buggy product will kill the brand.
Customers will leave behind an unfinished product and never return.
Their idea will be stolen.