In this episode, Henry Reohr and Adam McGowan discuss the concept of the minimum viable product, how its meaning has evolved over time, and the risks of confusing assumption testing with product development.
United States


00:00:01Wait Seven adventures of tech brought to you by fire field This is adam a gallon and i'm today's show We're going to discuss the concept of the minimum viable product or m v p and the risks of mistaking assumption testing for product development I'm again being joined by
00:00:26my colleague from fire field henry v r who we got in today's check and with that i'll let henry take it away and start environment The term minimum viable product gets thrown around a lot It also seems out a number of definitions can multiple meanings of m v
00:00:44p i'll be correct Well if you like to be a bit of a purist which i think of myself as when it comes to this i would argue that you go back to the source and in his book the lean startup eric reese create what's probably knows popularized
00:01:02version or least what was initially the most popularized version of a definition of this m v p and he said that a minimum viable product is that version of a new product which allows the team to collect the maximum amount of validated learning about customers with the least
00:01:19amount of effort now that left a ton of room for interpretation and i would argue that the industry has really taken a bunch of liberties with it and i think i do as well like what What kind of liberties Well my first one is to question whether or
00:01:35not the m v p is really a product so if you dig into it it seems more like a learning loop this idea that you build you measure you'll learn something and then you get a read on that i actually do some mentorship and do some teaching on
00:01:52the lean startup approach and on the idea of mvp creation and this is what i talk about what i do that this idea of this narrative loop and you know i think it's something that sometimes gets a little confused given that product is actually right in the name
00:02:06of the m v p i also hear a handful of other names thrown around and people talk about early stage products there's clickable prototypes proof of concept alphas betas and several others don't even seem to be used interchangeably with mvp how did they all lie to each other
00:02:30this is a place right so i get a little bit frustrated and i do that or feel that way because i feel that there's really a necessity to separate out the concept of creating a product from actually testing your assumptions and i think the descriptions and the names
00:02:45you just shared tend to commingle those two concepts some cases in pretty material ways so if i think about the stages surprise development i'd argue that the proof of concept happens at the earliest of stages and this tries to help you determine if something can even be done
00:03:04he then kind of movinto what would be more of a prototyping phase which describes and helps to illustrate how it would actually be done and then when you end up with his various versions of completeness and then you can evolve those overtime and i think that you ask
00:03:21ten different people about the definition of one particular term that you share they might give you ten different answers when i think about this idea of product testing one example that was what i would consider the alfa test for the alfa version of a product this typically means
00:03:37the product is not fully functional there's like the bugs in the product but really what's happening is that the owners of that product are looking for some feedback that involves into another phase which is much more commonly used what's called the beta beta test of the beta release
00:03:53this is typically a highly functional version of a product but it is not yet fully tested and it requires more feedback but something to think about here is that all of these both alpha and beta are still beyond proof of concept and they're beyond prototyping you are actually
00:04:09just dealing with what's the level of completeness of your actual product and you're not testing your assumptions here you're testing whether after probably works you're testing whether or not there's bugs it's a different thing but sometimes they get lumped together with the m v p i think they're
00:04:23very different things separate and apart from that is this notion ofthe assumption testing so again as i said this above stages that they're they're about building and about testing the actual product once it's passed this proof type stage and at that point you're not really having any left
00:04:41any requirements left to need to test the prize underlying assumptions something's still can attempt to do two things which is to both go about building product and then also go about testing assumptions and i think that's what the m v p tries to accomplish but most early versions
00:04:59of product you know best conserved in one of these two things either assumption Testing for private development there's even a few cases where i think attempts to conserve neither of those purposes Neither How can something that the founder is going to share with the users Be neither product
00:05:18nor assumption test i think usually happens when something attempts to be a test it's attempting to go by testing assumption so this means it was never intended yet to be a product It's not fully functional It's not ready for market but the problem is that the actual mechanism
00:05:36that used to test isn't very good not very scientific They don't control for a bunch of variables or even worse it does attempt to make a pretty scientific test It just goes about testing assumptions that air the long things to test What do you mean that how could
00:05:54you how do you know whether or not you're testing right thing how could there be a wrong test Well for a start up money often times seems or in reality is their most scarce resource but the reality is in the vast majority of cases not money that's the
00:06:14most scarce resource it's time and so you go back teo eric reese you're trying to quote unquote maximize learning over the shortest period of time and so let's say you had hypothesis you're trying to test and it wass can i get ten customers to commit to purchase over
00:06:32the next two week period and let's say that you actually about achieving that you do get those customers over that time Well what if in reality finding small numbers of paying customers is extremely easy but that those customers represent a market that's way too small to actually sustain
00:06:50your venture So what you've done is you've created test you controlled for it you got a result you proved it to be true the problem is it's not meaningful at all it was too easy to achieve it doesn't address the bigger issues you're trying to accomplish and so
00:07:03what could have been the right test would have been trying to determine how well this product could attract customers outside of this initial market outside of this sort of easy picking if you will when it comes to customers those subsequent markets might be necessary to make the product
00:07:19of success But yet you just fulfilled a positive result to attest that could lead you down an inconclusive or in some cases problematic path So how do you first identify and then conduct the right test Well i thought about this quite a bit and i think that it's
00:07:39a pretty complicated lengthy yet sir but then i actually found a piece of content somewhat recently that i think articulates the concept really really well i saw earlier last year it was in a post on afternoon written by someone reaching him and he proposed something he calls a
00:07:57rat rat all right like who wrote it Yes our eighty but it stands for riskiest assumption tests on these are assumptions that if they're not proven true have the most sizable negative impact on adventure so let's take that past example we had getting customers to commit assuming the
00:08:22entrepreneur ask herself a question is the idea that i confined ten customers the riskiest of all my assumption so that's a modification of the prior question which was can i get ten customers in two weeks now it's can the act of getting those customers be easy or hard
00:08:40right How risky is that assumption I think that assessing whether or not getting ten customers is the riskiest possible assumption you could have it's pretty clear that the answer is no that is not the riskiest assumption that you should be testing and so what it does it forces
00:08:57the founder to them in rank and then break these problems and questions and concerns down into smaller and more explicit components often addressing issues that they haven't look at him death yet so now that we've added another acronym to nick's what's the biggest takeaway you want to share
00:09:18with founders who have products that are at a very early stage Well i think the first thing i want to do is to suggest that people try to forget about buzzwords one there by their very nature very much a fad they can come and go to their open
00:09:36for interpretation you ask ten people you get ten different answers and i just don't think they get they cut to the core of what you're trying to deal with So i think that what's most important is for founder's to really focus on moving their ventures forward as efficiently
00:09:51as possible almost in sort of a fanatical way be consistently asking yourself is this the most efficient use of my unbelievably limited time and potentially extremely limited money and capital And if the answer is no henry figure out what it is that you're supposed to be doing that's
00:10:11more uh efficient i think another point that's very very t is to really think hard about distinguishing this idea of assumption testing from product launching again the mvp kain tries to do both but they're pretty distinct things with pretty distinct objectives for no two companies will they be
00:10:29the same But they're pretty distinct for most every company that i've seen i'd argue that the priority here should be mostly on the assumptions first and then product second and so if the most important tests that you need to address first if they don't translate into an m
00:10:48v p they don't build the m v p s this another major miss that i see all the time which is ideas that are not fully baked they are not fully validate that they don't necessarily they aren't necessarily even a product yet they're just still a concept people
00:11:05will come to us and say i need you to build my empty people first of all you don't build a new vp right you generate on m v p you use it as an assumption tests but i think the term is thrown around in the wrong way and
00:11:15then the product gets put in front of the assumptions can i think that that's backwards so well that said i think there's really malak to this idea off the rack even if the acronym isn't particularly all that attractive so what does it do it helps you to uncover
00:11:33these risks assumptions it helps you to validate them in the smallest and most iterative test that you possibly can and if the performance of such test requires the creation of an early stage product then you think about creating one but if it does not don't so i think
00:11:51this idea and this assumption that some form of product creation is always the early answer is a very sort of commonality in the startup environment and hi rollback this concept of test first validate assumptions come up with the notion that there's a product that should be built and
00:12:10then go about doing it And so i think that often times the notion of the m v p while in its purest form When reese talked about it made great sense It's played a game of telephone over the course of the years And now i think it seems
00:12:25like an m v and a capital p and that the product seems to get brought to the front And i think that that's something that it found its way more thoughtful about it They find themselves being able to validate earlier and probably find a little bit more successful
00:12:39products Thanks adam that's All we got for today i've had to reorder from fire fields and you've been listening to another episode of adventurism

Transcribed by algorithms. Report Errata
Disclaimer: The podcast and artwork embedded on this page are from Firefield, Venture Strategist and Catalyst, which is the property of its owner and not affiliated with or endorsed by Listen Notes, Inc.


Thank you for helping to keep the podcast database up to date.