What Does It Mean to Be "Minimally Viable"?
This is the first post in our "Launch!" series, addressing the design, development, operation and marketing of new websites and web-based services. We're releasing it in conjunction with our new LAUNCH @ Logicbrush Premium Service. Check it out today!
When you're considering launching a new product or service, the question of its "viability" often arises very early in the process. The term has become a bit of a buzzword in the entrepreneurial community — its meaning co-opted and confused by parties with differing experiences and agendas. When combined with "minimum" — as in "minimum viable product" — it might mean anything from "a starting point", to "prototype", to "(perpetual) beta", to "whatever, as long as it's profitable", depending on whom you ask.
So, whenever interpretations of a term abound, I find it's a good idea to see what it says in the dictionary to help steer us in the some direction:
- capable of working, functioning, or developing adequately
- capable of existence and development as an independent unit
- having a reasonable chance of succeeding
- financially sustainable
“viable,” Merriam-Webster.com Dictionary. Adapted from the second meaning. Accessed 3/17/2021.
Hmm. There's a lot of room for interpretation in this definition. Words like "adequately" and "reasonable" are subjective and don't really help us to quantify things. I suppose it's understandable how different individuals could come to very different ideas of what makes a product "viable".
So, rather than searching for the "one true meaning" of viability, let's just define it for ourselves. We'll need to do so in a way that makes sense to our stakeholders, and gives us all a common perspective on what it is we're building.
So how do we do that? Let's use the Merriam-Webster definition as a springboard to formulate some questions we should consider as we come to our definition. We'll break it down, point by point and see what use we can make of it…
Point 1: "Capable of Working, Functioning, or Developing Adequately"
Let's dissect this further, starting with "functioning", as that term seems the most straightforward. What does it mean for our product to be "functioning adequately"? Doing what it's supposed to do with an acceptable rate of failure?
To that end, let's consider:
- What is our product supposed to do? Do we have that written down anywhere? Can we measure performance in some way?
- What constitutes a failure, and at what point do we reach "unacceptability"? Can we test things before they become failures?
- If a failure occurs, do we have a plan to respond?
What about "working"? "Work", in the physical sense, is a force applied to an object over a distance resulting in an overall increase in its kinetic energy (SCIENCE!). So, it's not a static quantity; it's dynamic — it's an application of effort over time to produce some useful result.
- How will our product work for us? What's the useful result? Do we have an objective test for that?
- How will our product change the status quo? Is it novel? Cheaper? Faster? Easier? What makes it worth building?
- Who benefits from our product, besides us? What is it worth to them?
- Where will we meet resistance?
Finally, "developing" implies growth — evolving and improving over time.
- Do we have a plan for growth? If we're not perfect out of the gate (we won't be), how will we improve?
- How do we anticipate and accept change? Where are the harbingers of change likely to come from?
Point 2: "Capable of existence and development as an independent unit"
I think the key takeaway here is independence. Our product must be able to live on its own. Is that even possible? It's hard to. build a software product that exists without any dependencies. At a minimum, we should have a good understanding of what our dependencies are, even if we can't eliminate them entirely.
- Are there services, processes or systems that our product depends upon? Should we try to eliminate them? What happens if they go down?
- What level of support do we need? Open source vs. commercial? Buy vs. build? What are the tradeoffs?
- Are there any single points of failure we should be aware of?
Point 3: "Having a reasonable chance of succeeding"
A reasonable chance of success is far from an absolute certainty. It seems fairly obvious that if we try to wait until the point of certainty, we may very well miss our opportunity. We will need to determine the level of risk we're comfortable with.
- What does success even mean for us? Can we quantify and measure it?
- Is our definition of success realistic? Do we know what we don't know?
- Does our team have the experience we need to be successful?
Point 4: "Financially sustainable"
Everything always comes back to money. We haven't met a client yet with unlimited funds (aside: Jeff Bezos, we'd love to chat!). We'll need to consider what makes the most effective use of our cash.
- How big is our audience, and how big are their pockets? Are we better off targeting a niche or the general public?
- What's our budget for the project? We can't spend indefinitely.
- How & when do we recoup our investment? Do we have a plan to make money?
- Do we even have the skills to understand and measure our profitability?
So, what's the final takeaway here?
"Capable of working, functioning, developing adequately", "existing independently", "financially sustainable" — maybe our "minimum viable product" shouldn't be as "minimum" as we thought? At least not in order to give it a "reasonable chance of succeeding".
At the end of the day, we make our own decision on what makes our product worth pursuing and when it becomes viable. But, spending a bit of time to think about what our criteria are, writing them down, making a plan to achieve them, and figuring out a way to know when we do — that should be the bare minimum. :-)