Theoretically, this should have been an opportunity to learn, tweak, and improve the product, but Electroloom\u2019s lack of pre-work was their undoing. As the aforementioned Engadget article relates, \u201cRowley didn’t really know what Electroloom was for, or who would wind up using it.\u201d After the early hype and a promising first funding round, Electroloom failed to scale and ran out of funding.<\/p>\n
Another company, Standout Jobs, sought to revitalize the job recruiting industry via a customized platform. They were so sure of their product that they didn\u2019t do much (really any) customer research. It resulted in their first release being a big flop.<\/p>\n
What do these two very different failed businesses have in common? They both failed to do their due diligence before releasing their MVP. Instead of launching a minimum viable product based on data-driven decisions combined with evaluative user interviews with potential customers, along with a clear measurement of success, they went with their gut. For Electroloom, that meant addressing the wrong market segment. In the case of Standout Jobs, there was no understanding of the customer. In the end, they both lost the opportunity to provide value and learn about the viability of their products before it was too late. When things went wrong, they didn\u2019t know why, so they couldn\u2019t try to fix it. Ultimately, they failed.<\/p>\n
Both of these products may have been successful\u2014although we\u2019ll never know\u2014if the MVPs had been built and released only after<\/em> the proper amount of \u201cproduct viability testing\u201d to determine if these ideas could achieve product\/market fit.<\/p>\n Before we discuss what \u201cproduct viability testing\u201d is, we should acknowledge that these founders operate in an environment that favors execution over exploration. The traditional business plan pressures investors to fund ideas that look like good bets. In this scenario, money is the only thing keeping this idea from hitting the market and being a huge success. These plans include revenue targets and dates. Founders and CEOs raise capital by showing some evidence that their ideas are worth funding, along with a plan they are asking to be funded. This is the single biggest source of failure for new products because it overlooks the fact that this product idea is still a hypothesis. The riskiest and most expensive way to test a commercial hypothesis is to build it and hope customers buy it.<\/p>\n There is an alternative.<\/p>\n Even product development industry professionals frequently overlook the different types of \u201cviability.\u201d There is commercial viability: Will customers buy it and pay a price sufficient to support a thriving business and, at some point, contribute to profitability? There is feasibility: Can we pull this off from a technology perspective? There is production viability, otherwise known as scalability: Can this product stand up under real-world scenarios? There is user adoption: Will users choose to use this product over the alternatives?<\/p>\n Before you get into building an MVP, you need to confirm that your pitch to investors or internal stakeholders is true and that if you spend the money to build it, users will use it, and customers will buy it. (Note: In business-to-business products, the user and the buyer can often be two very different groups with different agendas.) Beyond just confirmation, however, you need to understand these groups better. How does your initial target segment self-identify? What words do they use to describe the need? What motivates them to action\u2014particularly to seek a solution, purchase it, and use it? If such a product existed, what would they expect to see? What would they need to buy it?<\/p>\n The fastest and cheapest way to explore these questions and build a mental model of your users and buyers is rapid prototyping. The most common format is working with low-fidelity wireframes. These are easy to produce and easy to change so that you can test multiple hypotheses. You cannot do this with working software. You may decide you need something higher fidelity, like a website where customers sign up for a service that seems automated but is actually being done manually behind the scenes. The format that your prototypes take is irrelevant as long as they:<\/p>\n Note that I said \u201cprototypes,\u201d plural. You should be doing these in short rounds because you are trying to provoke a response. Users and buyers can\u2019t tell you what to build, but they will<\/em> tell you when you\u2019ve gotten it wrong, and this approach allows you to see patterns. While product viability testing aims to bolster confidence that the product will indeed deliver commercial results, the real value is in the insights. Armed with these insights, if the MVP doesn\u2019t get the response you hoped for, you\u2019ll have a rich set of knowledge to base your hypotheses on how to tweak it to get the adoption you were aiming for. Without these insights, a flop on release can mean death for a company as it did for both Electroloom and StandoutJobs. Investors can tolerate a pivot if they think you\u2019ve learned something that can make good on their initial investment.<\/p>\n To avoid the dangers of confirmation bias, we recommend setting out success criteria for the product viability testing phase before starting the tests. You\u2019re looking for proof that people in your target market value a solution that looks like your product or service concept. You can deviate from the original success criteria, but be honest with yourself about why you\u2019re doing so. Is it because you\u2019re getting impatient and love your idea even when the data suggests there isn\u2019t a market for it? Or do you have a legitimate competitive threat that is pushing urgency and the need to take a bigger risk?<\/p>\n Often, the biggest challenge people face is figuring out the right assumptions to test\u2014in other words, coming up with the proper hypothesis. In scientific terms, a hypothesis is a data-based starting point for further investigation and measurement. In other words, if you can\u2019t measure it, you can\u2019t improve it. So if you don\u2019t nail the hypothesis, along with your measure of success, your learnings will be less concrete and harder to use as a justification to increase spending.<\/p>\n Hence, you must ask yourself some important questions:<\/p>\n The answers to these questions must be informed by data gleaned from market analysis as well as prototyping, user research, and interviews. Sussing this out directly impacts how you\u2019ll scope which features to include and the extent of those features for the MVP. There is a fine line between lacking, good-enough, and overdoing it, but the impact can be the difference between success and failure. Answering these questions before building your MVP is foundational to getting the MVP in the sweet spot between too much and not enough.<\/p>\n So how do you arrive at the proper hypothesis? Simply put, you need to begin in the right place: Seek to understand your market segment, and more specifically, your users and buyers. The Pragmatic institute explains, \u201cFor an MVP, each feature must be tied to tangibly solving a top customer problem.\u201d Then, it makes sense that you can\u2019t find your MVP\u2019s sweet spot unless you understand what those problems are and the minimum required for a segment of your target market to consider your product a solution.<\/p>\n To that end, the Pragmatic Institute<\/a> coined the acronym NIHITO, which stands for \u201cNothing Important Happens in the Office.\u201d Their point is, getting out into the real world and collecting data about real people is the proper way to understand their needs. In turn, this data informs how you can scope your MVP properly.<\/p>\n With that in mind, let\u2019s look at the top-level issues that lead to an MVP that teaches you nothing.<\/p>\n As Javier Trevino, Director of Technical Services at 3Pillar Global, says, \u201cCompanies and organizations may think they know what the end-user wants. If there is no real data, like that obtained from executing market research or from surveys\/polls, then the MVP could be missing the mark.\u201d<\/p>\n To avoid missing your target, start with market segment identification. Segments are discrete groups of users connected by qualities such as age, gender, profession, location, and other distinguishing demographics. The Chron.com<\/a> offers this example: \u201cIf you own a local pizzeria with a sit-down restaurant and delivery, two key market segments might be families and college students. For a forensic consulting company, market segments include trial lawyers, in-house counsel for businesses, and law enforcement agencies.\u201d<\/p>\n You identify these segments by conducting quantitative research. The research allows you to segment customers and prospects into high-level groups based on specific markers, such as demographics, buying habits, affiliations, etc.<\/p>\n This is a more granular and personal category than market segments. Segments can help narrow down the big-picture \u201cwho,\u201d while user personas help you understand the underlying \u201cwhy.\u201d Keep in mind that users and buyers may not always be the same group. B sure to differentiate users and buyers in your research.<\/p>\n This research involves identifying and understanding the problems you\u2019re solving and the pain points people face. Because you want to make data-informed decisions, perform a combination of quantitative research (drawing on behavioral analytics) and qualitative research (including user interviews and surveys) to understand the pain points, underlying motivations, and problems of users and buyers.<\/p>\n Creating user journeys involves mapping out steps people take as they try to solve a problem. It can further reveal the emotions, pain points, and motivations involved and illuminate where your solution fits into their lives.<\/p>\n A user journey map can also help you clearly visualize the minimum number of steps (or features) needed that will also provide the maximum value in relation to your MVP. These help you understand where your product fits into their workflows.<\/p>\n Creating data-informed personas and mapping user journeys will naturally lead to the creation of your problem statement. Using the pizzeria example, a problem statement might be, \u201cCollege students who are gluten intolerant need an affordable gluten-free menu option so that they can enjoy pizza with their friends.\u201d<\/p>\n Avoiding all of the problems we\u2019ve mentioned in this article, as well as doing the right preparation, will help you form your data-driven hypothesis to test, along with the measure of success. This will, in turn, inform your scope.<\/p>\n It\u2019s challenging to whittle down features. However, it is an essential step that must be done and done thoughtfully. As Michael Rabjohns, User Experience Practice Leader at 3Pillar Global, explains, \u201cYou really need to understand which features and functionality are most important\u2014if there\u2019s not enough \u2018there there,\u2019 users won\u2019t adopt it. You need to be able to live with that decision; [It\u2019s] harder for product owners when we know about all these other great features under consideration that users would love.\u201d<\/p>\n However, if you\u2019ve done the due diligence discussed above, then you can let go of your \u201cwant to haves\u201d and focus on the \u201cmust-haves.\u201d In other words, you\u2019ll be empowered to make data-driven decisions about what realistically falls into that \u201cjust-right zone.\u201d Why? Because you began by understanding your users and buyers. You now understand their problems, where and how they encounter these problems, and you have assumptions to test regarding how your product can solve the problem and deliver value.<\/p>\n Think back to the failed startups we mentioned at the beginning of this article, Electroloom and Standout Jobs. While it\u2019s true that hindsight is 20\/20, it\u2019s easy to see how they could have given themselves much better odds of success if only they\u2019d done their due diligence. Had they entered the market with a data-informed understanding of their potential target market and a clear hypothesis to test, they would have understood how to iterate and improve their product when things went wrong. Instead, they were unable to make any data-driven decisions. As a result, they failed.<\/p>\n Just about every MVP-related problem can be traced back to improper preparation. For your MVP to be the valuable learning tool it\u2019s meant to be, set yourself up to learn BEFORE you ideate and build it. Do your due diligence in the form of quantitative and qualitative market- and user-research. This will lead to data-driven decisions about your hypothesis, measure of success, and feature scope.<\/p>\n To learn more about 3Pillar Global\u2019s services and how we can help you create a minimum viable product to test and validate your assumptions with real customers, contact an expert today<\/a>.<\/p>\n Special thanks to these members of FORCE, 3Pillar’s expert network, for their contributions to this article.<\/strong><\/p>\nWhat Kind of Viability?<\/h2>\n
\n
Measuring Success<\/h2>\n
\n
The Main Problems With an MVP<\/h2>\n
Problem: There is no proper market research and validation<\/h3>\n
Problem: There is no target user defined<\/h3>\n
Problem: You didn\u2019t generate user journeys for your personas<\/h3>\n
Problem: There is no problem statement defined<\/h3>\n
Problem: Features aren\u2019t scoped\/prioritized properly (as in there aren\u2019t enough or there are too many)<\/h3>\n
Conclusion<\/h2>\n
![\"LinkedIn\"](\"\/wp-content\/uploads\/2014\/08\/linkedin_25x252-1.png\")
Angel Almada<\/a><\/p>\n