If you’re a startup, especially with a software component to the business model, you’ve probably heard the term “MVP”. While it is nice to think of that time when you were surrounded by friends or family at your favorite sports event, joining the crowd to chant “Mmmmmm Veeeeeee Peeeeeee” of the all-star on your favorite team, this isn’t that type of MVP. The same enthusiasm is certainly encouraged though.

What we’re talking about instead, is “MVP” as it stands for a Minimum Viable Product for your startup or business venture, and as your stand-in CTO, we want to ensure that you have these acronyms down. A quick Google search can do just the trick to help you garner confused logic around the concept but inevitably it lends itself to a lean first version of the software product or service you want to take to market. Less all the bells and whistles, this minimum viable product offers only the necessities to prove a hypothesis.

In “The Lean Startup”, which is a book, you might find that the general concept is to rely less on focus groups or surveys (which can be found in many business plan/investment deck “market validation” slides), and we agree with the notion. As our very own CTO-turned-CEO says, “the best survey possible is when a potential client opts to pay for something you’re providing.”

In more direct terms, skip the survey, get out and sell. Find out what an actual new client likes, doesn’t like, says they’d like to see. That is the best direct feedback to inform your iterations of features and upgrades.

It’s a common mistake that founders can easily make. Before knowing what the client really wants straight from the source, founders tend to brainstorm, dream, and ultimately iterate on what would otherwise have been a proper MVP, ultimately phasing into more of an MMP or “Minimum Marketable Product”. The issue here is that there usually isn’t any previous field feedback to back up the decisions that then lead to a more mature MVP. This now MMP can become more costly without the fundamental feedback to inform that spend. As a startup, you want to be strategic, stay lean, consider the options. Let the people tell you what they want and spend effort around capturing that type of feedback rather than brainstorming “nice-to-haves” with non-buying customers.

The point here is, your software is a living, breathing thing that requires maintenance, support, TLC sometimes, and you’ll always be considering what’s next for it. To begin though, your MVP should be a complete necessities-only prototype that does one sole thing well: prove the hypothesis of a potential problem/solution.

Another slippery slope is the age-old “exception to the rule” concept. As part of any business model, you try to find your toughest critics in friends or family, ask them to find every possible problem, and they do. With that “challenge-accepted” grin, they can lay in like a hailstorm. While these exercises are valuable, honoring the “exception to the rule” can truly help you qualify the magnitude of the potential problems or issues that they draw to attention. Often, this type of audit drums up a whole host of exceptions, those things that might happen once or twice in a blue moon or. Acknowledging that bugs and errors will happen is of course correct, but exhausting cash resources on fixing “exceptions to the rule” can quickly eat up your financial runway in this prototyping phase.

Before even getting to an MVP, you want to manually map out the workflow that you believe your software will streamline, automate, or otherwise bring efficiency to. As your stand-in CTO, we encourage a wonderfully intense whiteboard session to configure workflows, possible breakdowns, all the ins and outs. As time goes on and you intake more feedback, this working space allows you to see a clear cut picture of patterns in issues that maybe happen often, or consistently. Those items are the types of things you want to spend resources on to remedy in your necessity-only MVP.

Having said that, it doesn’t always make sense to get so lean but there is almost always a way to do so to prove a hypothesis out of your MVP before frontloading cash on products and features that may not even be high priority to your client base. At the very least, it’s a healthy habit to consider these steps before committing to any software development agreement; most necessary gets priority and iterations can come in following phases.

To talk tech with our team, reach out anytime!

‍