(playful techno music) - Hi everyone.
Thanks for having me.
Thank you John.
Yeah sorry I couldn't be here yesterday.
I have made the transition from designer to entrepreneur and started Founder and got some good news yesterday which is exciting, and as I was reflecting I guess on sort of what both those roles have involved to me thus far, this thing sort of kept coming up.
This sort of notion of ideas.
There's a really powerful statement I guess, which is nothing is as potent or as powerful rather, as an idea who's time has come, but what I've been feeling recently, particularly in sort of the startup world, is that nothing is sort of as dangerous or destructive as an idea who's time has not yet come and so that's what I'm going to be talking about today or ways to sort of avoid that and sorry to Johnny, there probably is gonna be a little bit of nuance here around definitions.
Really I'm not that interested in necessarily kind of the words we use, but rather the intent that we have behind them and so that's what the next 20 minutes is gonna be about. Ideas seem to have this sort of insidious, exponential kind of element to them.
They seem to grow like viruses.
We start with one idea and then someone bounces off another idea off us and then it sort of just grows and I sort of feel like before we can really isolate and validate each idea as required, we have become really attached to them or rather they're attached to us and I find it really hard to let go.
There's a really sort of high cling factor about them and what generally ends up happening in my experience and you know I've done this probably too many times early in my career than I'd like to admit, is that we end up sort of planning and wanting to build and wanting to release all the things in the hopes that that's gonna maximise our chance of success and even if customers don't love all the things that we're creating, at least they're gonna sort of engage with some of them. That can be our approach sometimes.
We usually end up here, right? Where we do really really well, the thing that shouldn't be done at all and we end up in Uselessville, but I probably hear some of the inner voices inside of you say, well that's not us, that's not my team, 'cause we go about it by starting with an MVP, right? And that becomes our mantra, that we're not gonna fall into that trap, because we're gonna go and undertake, the pursuit of a Minimum Viable Product and that makes a lot of sense.
I think in product management that's obviously a really good approach.
you wanna sort of minimise risk and so forth, but as I started reflecting on this I got to thinking, what does this term actually mean? I've had teams that have banded around it a lot. We would just throw around willy-nilly, 'cause it just felt like such an obvious term. When you actually sit with it and start to unpack that for different people it could mean different things, I think you actually run into a lot of trouble. So I was this guy thinking what the hell does it actually mean? And I'm actually gonna use maybe a couple minutes of our time here.
I'd like you all to pull out your phones.
I'd like you to go to Menti.com if that's okay.
I think we all have wifi or cell service in the room. Hopefully this code is still working and if you go to Menti.com, M-E-N-T-I.com, then you should be able to punch in 1777, I'll just give it maybe 30 to 40 seconds.
You don't have to sort of do this now.
What I am gonna do is, I'm gonna hopefully have all your answers come in, find me on LinkedIn and I'm gonna post the results of sort of what the audience in this room thinks the answer to this question is.
Hands-up if that's not working for anyone? Hopefully this code is working.
Good? Thanks.
So take a look, I'll give it sort of 30 seconds, and like I said, after the talk, I'll post sort of where our answers lie.
Like I said, so I'm gonna move on, just because I've only got 20 minutes.
Hopefully that's an interesting sort of exercise for you to reflect and I really press upon you to complete that before sort of the day is out and do it during lunch. Here is from a previous community of 55.
I haven't got their answers up there, I've jumbled them up, but this is the results we got and this to me sort of just proves that we're lacking alignment on what the term MVP actually means. Hence sort of the genesis for this talk.
To be fair it's not even just us as a product or a design community that don't align.
Even the proponents of the term.
So you might be familiar with Steve Blank, Eric Ries, author of "Leading Startup".
Steve Cagan from Silicon Valley Product Group. Ash Maurya who wrote sort of "Running Lean". They all can't even align on what the term MVP even means anymore.
What this exercise really tells us is that words matter.
They're what we hear, they're how we derive meaning, and I think that it's really important for us to make sure that a teams we're aligned on what we mean when we use these sorts of terms. Recently you know there's blogs and articles abound, and Tweets abound of people who want to tweak the term MVP, rename the term MVP, kill it all together, I've heard of Minimum Lovable Product, Minimum Awesome Product, SDC, Simple Delightful Complete, if anyone's seen that, it's a new one that's popping up.
I'm not here to sort of create my own terminology around this.
I really just want us to reclaim the term.
I don't want to rebrand it.
I think that if we unpack sort of the intent behind it, it's a good enough term as long as we can all align on it and my approach to doing this actually is that the best way for us to align as teams and to make it sticky, is actually to align first on what a MVP most definitely is not.
And that's what my intent is over the next 15 or so minutes. What I should also say is, disclaimer, is that I've built, or have been part of building, way more shonky products than I'd care to admit, so I'm not a guru here, I'm really just sort of, dove into the literature and to my own experiences and spoke to the community and put this together.
We may disagree, maybe not on intent, but on the words that are used.
My sort of, my call or ask I guess, is feel free to just use this as a shortcut. I've sort of unbundled and re-bundled everything in this space.
I'd love for you to sort of go back with your teams and say let's sort of start to rally around what this really means.
If this is how we're gonna drive our product development process.
So I'm gonna start with, in order of priority, the things that it's definitely most not that we could probably agree on and I'll sort of be laddering up into territories where you'll probably start to feel like, I kinda thought that's what MVP was this whole time. So the first one is that an MVP is most definitely not a proof-of-concept. We've used that term at my design studio to maybe mean the same thing on occasion, but really I think the best way to think about a proof-of-concept is that it helps us test our technical feasibility.
So can the thing the we imagine in a particular way actually exist IRL.
Let's create a proof-of-concept to test whether the functionality as we imagine it, can actually be created with the resources we have at our disposal.
Some people in the industry sort of start to call this an MVPT, or a technical MVP.
Really the tell for us here, or how to tell when someone's talking about a proof-of-concept, but using the term MVP, is when they say things like let's just hack it together and see if it functions as needed and that will be our MVP.
So that's a red flag.
That's not MVP, that's a proof-of-concept.
The second one is a profitable product.
An MVP is not equivalent to this and I probably don't need to tell this audience that, but I think that particularly in the startup world or those of us who sort of maybe in new ventures as part of the companies we work at, we've got some key hypotheses that we need to test out and the most essential of them is that the product or the feature that we're creating can actually sustain the business or sustain the metrics that we're going after and it's a really key sort of business hypotheses that sits under product development.
But just in order for what we're developing to sustain the business, does not mean that it in itself as an MVP needs to be sort of raking in cash from day dot. What it does mean, it means to promise that.
Then you need to bake in some financial assumptions into your pursuit of an MVP and you also need to bake in measurement tools to understand that what we're actually creating is giving us some signals that in the future if we were to do X-Y-Z or A-B-C, it can actually lead to revenue for example or other important business objectives, but in and of itself at the beginning, an MVP doesn't need to be raking in any money and if you hear a phrase like my MVP failed, it's not making us any money, that's another tell that person's not talking about MVP what they're after is a profitable product. The third one, stakeholder must-haves.
So for any of us that works sort of in big enterprise or work in consultancy is where you bring a lot of people together and I think this is a you know, very very easy trap to fall into.
I've seen sort of the enterprise world ruin MVPs, because we start to treat them as the M in Moscow, so if anyone's familiar with must have, should have, could have and won't have, that's sort of the Moscow frame work and generally MVPs just start to become everything that we shove into the M-quadrant and whenever you say we're gonna go after an MVP with an enterprise, in my experience, a stakeholder stampede ensues, everyone sort of starts to give their two cents, we have a stakeholder workshop, we've got a bunch of different ideas and we put a whole, you know 60% of them in the M-quadrant, 'cause that sort of feels like that's over halfway and just good enough and then we as a product or design team circle them and say, cool that's gonna be our MVP and it's really not the right way to go about it. That phrase marinates for months in corporate culture and it either becomes what I call an MVIP, so a Minimum Viable Impressive Product or an MVPTICSMB, which is Minimum Viable Product That I'm Comfortable Showing My Boss (laughing) and that eventually becomes a bloated, a bloated first release.
So if ever you hear things like, you know what, let's just start with these eight requirements from our c-suite, that can form the basis of our MVP.
Again you're in trouble, that's not an MVP, that's your stakeholder must-haves.
The next one is a minimal product.
So on us removing the concept of viability here and this one's an easy one to fall into, because we start to think of our Minimum Viable Product and I'm giving I guess away an answer in the Menti poll, but we start to think of our Minimum Viable Product as the smallest, least costly thing we can build, that represents a version of our final product and some questions I have for you there are, well who knows if your final product is actually the right product? What does the final product ever actually look like? And so we end up thinking that if we just build something small and it works well enough and it looks pretty good, then that will suffice as our MVP, but really what you're doing there is that your extracting the viability element of this entire concept and we end up having something that works pretty well and people can use it, but ultimately we're not really cared whether people can use it, what we're interested in is whether people have use in it. I'm mean that's a really important distinction. I guess you know we should all know that in the room, but I think that if we sort of have an itch to scratch whereby we just wanna get something out the door that works fairly well, just so people can use it, that's fine, my ask of you is sort of let's not call that an MVP, because I think that's confusing our industry again. And so if you hear phrases like we're just gonna start small with this one simple feature, it's gonna work well and our MVP will start from there. Again you're not looking at an MVP, you're looking at a minimal product.
This next one is my personal favourite and I think probably almost everyone in the room is gonna identify with this so, what an MVP is most definitely not is the bare minimum deliverable or minimum releasable crap. (laughing) and I've seen this happen a lot.
So an MVP is indeed meant to be the quickest version of something, but when we talk about the quickest version, what we're really meaning by that is reducing the feature set, not reducing the quality and I see this happen far too often, where we have teams basically come around and almost treat the bare bonesness of the thing itself as a badge of honour and MVP ends up becoming a battering ram for designers and product teams and engineers that actually want to round out the completeness of the soul of that feature for example and we've got potentially leaders who are short on time saying things like, you know, it doesn't matter, it's just an MVP and what ends up happening is that we end up in a world where we're sort of releasing what we think is the minimum and while our customers can actually accept something that doesn't work completely as intended and is missing features that we think might be important in the future, they can accept that, but what they won't accept is the core thing that we're trying to address done really badly.
If anything MVP shouldn't mean bad UI, it should potentially mean bad code.
What's important to consider there is what viability means in your context.
So if you think about a new note taking app that's been released to the app store, you might think that it doesn't need to work beautifully and have seamless interactions and so forth, but actually the way that that note taking app feels, the delight that it brings to the user that's interacting with it, that can be the very difference between viability and not being viable and so actually a beautiful UI for example, and beautiful interaction design, could make all the difference for that product. So I would challenge you to sort of keep the soul and keep the completeness of the UX, that quality is really important.
If you're going to do anything, actually have some bad code in the background, because if your not sure if the product that you have in mind is gonna find any traction in the market, then don't spend you're time on the stuff the customers can't see.
All the architecture that sits in the back. Really just focus on making their experience as good as possible.
So the tell here is you know, if you hear people say, don't worry, it doesn't have to work properly, we're just hacking it together, get it out the door, that's our MVP.
That's your MRC.
Who in the room has heard of minimum marketable product? Okay so a good chunk, maybe just under 50%.
This is an interesting one.
So minimum marketable product sort of became a term as MVP started being taken to mean sort of experiments and learning vehicles and people wanted to understand, well if MVPs are learning vehicles then what's the thing that we actually give out to customers and minimum marketable product basically was born I think what's important to understand here is are you in a position to release what you think is your MVP, SO the thing that some customers are using and I'll finally get to the definition of MVP in a little bit, but are you in a position to release your MVP to market? Well I think it depends.
So if you're a startup, you have no existing brand, you're solving something that no one's really solving well right now, the thing that maybe isn't as well parsed as you might like, it might be a little bit buggy, the brand might be a little bit off, I think that's fine to release as the product that you would end up marketing.
If you're an established brand with established customers who have expectations already about the sort of products and services you provide, then I think a minimum marketable product is a step up from a Minimum Viable Product and it's up to you I guess to make the decision of where that lies.
The minimum marketable product, if you think about it, is the one that can be packaged up and promoted in some way an example I like to think of is Spotify.
So Spotify had a bunch of key hypotheses and what they ended up doing was putting a whole bunch of tracks on a local server, they gave it to their friends and family, so those friends and families could use a desktop player to access that music without having to sort of rip music off albums or download music, but what Spotify couldn't do in terms of releasing that to the broader set of the market was leave that product as is and what they ended up having to do was to bring in album art for example.
So there was no album art in the MVP that Spotify's friends and family were using, there was enough value for those people in not having to download songs, but for the sort of broader base of the market, Spotify needed to sort of add a couple bells and whistles and package it up into something that could be a minimum marketable product.
And the last one is whether an MVP is a learning vehicle.
So is an MVP a prototype that really just represents a way for us to maximise our learning? If you're Eric Ries, and you're proponent Eric Ries, so he's the author of "The Lean Startup".
He defines an MVP as that very thing.
So he says that an MVP is that vehicle which maximises our learning and gets us through the build, measure, learn cycle as quickly as possible, and so in Eric's world, if you had a key hypotheses about whether your customers felt a certain way, you might conduct an interview.
If you had a hypotheses that customers are interested in your product at a particular price point, you might have a splash page with different you know, pricing variations on it.
In Eric's world all of those are MVPs, because they really are just maximising our learning, and he'll start obviously, with our riskiest assumptions, the riskiest hypotheses and work back from there. There's an opposing school of thought however and I guess the camp that I sit in and that's the school of thought that's headed up by Steve Cagan and Ash Maurya, who I mentioned earlier, and they sort of say look, prototypes are really important.
You know we might have feasibility prototypes that help assess sort of the technical elements of something.
We'll have usability prototypes that help us assess any interaction design issues.
We also really need to have live prototypes. Live working prototypes that help us understand not just the promise of something, but whether our users and customers actually really are interacting with our product and what sort of value they're getting from it, but for those gentlemen and I guess for this gentleman up on stage, I don't see those things as MVPs.
They key thing that those things are missing, is that their not products.
They're not products in the sense that users can't actually use them.
So if we think about a landing page, that's great.
We could find something great out about our product and our value prop and the pricing, but the only value that is being created there, is value for us.
Value for us is a product thing to learn, there's no value that's actually being created for the user there and so again this is sort of giving away I guess, something that was in the poll, but I would like us to sort of move away from the idea that an MVP is simply a vehicle to learn from in Eric's world, and actually move towards the definition that I'm going to be talking about now.
I should say I haven't, you know I'm trying to I guess clear up the mess that our community industry has got itself into and the reality is that two of the key proponents in this world, have diverged around what they think and rather than me going off to create a whole, or third schema, I'm sort of just aligning with one and the one that I align with is the definition that's coming up and you're probably all wondering with only five minutes left, what is the definition of MVP already or what could we take back to our teams to get us out of this mess? The definition I've cobbled together is the one that I'll show first and there's a much more elegant one that comes after, so no need to furiously scribble any notes. I would call an MVP a down payment on a larger vision that delivers the minimum feature set needed to provide some value to "earlyvangelists" and indicates it can support a sustainable business or at least a part of that business, right? The thing that's important here to call out is "ealryvangelists" and as someone who's worked in design and product for a while now, actually really truly understanding recruiting, getting close to those people, who for a new product or a new feature are the people that we, the people that we want to satisfy.
Not necessarily the whole market from day one. It's a challenge, but one that I can't sort of stress that you conquer soon enough and I think as sort of nice little cheat, the way to think about who these "earlyvangelists", these visionaries are, they're people who are going to accept that things aren't right, they're gonna accept that the product isn't completely rounded out.
What they're on board with is the vision for what you're building, because they feel the pain very very deeply and they have the personality to sort of experiment with something that is gonna solve that for them and some of the markers of the "earlyvangelists" that you might like to think about, the following sort of five elements, so they have a problem, the problem that you want to solve.
They are aware that they have that problem, so that's really important, they need to be, have some sort of level of awareness that they're struggling in some way.
They have been looking for solutions to that problem already, so that problem that they're facing, sort of is grinding them up so much, they've gone to market to look for solutions. They've potentially actually, as a fourth element, started to piece their own solutions together and the fifth one, the most important or as equal important to the others rather, is that they have or they can acquire a budget. So that you know, what we're actually building out for them, the viability that we want and we can actually capture some of that value from them. So you need to make sure that when you are building out your MVP, that these are the sort of people that you're targeting, because you'll know when you reach your MVP, it's these sort of people that are pulling that product or that feature out of your hand. Ash's definition is much more elegant.
He says it's the smallest thing you can build that delivers customer value.
That's it.
The smallest thing you can build that delivers customer value and as a bonus captures some of that value back, i.e. gets you paid, has the promise of getting you paid, has great engagement metrics that point to something in the future and the thing about it is when you think about the term Minimum Viable Product, you've got minimum right there in smallest, you've got viable in the sense that it's delivering some customer value and getting that back and the product suggests it's a thing you can build, right? It's a thing that that customer is actually using. Now I guess I probably lied a little bit earlier when I said that I'm not here to develop a whole new lexicon.
I don't want to redefine or rebrand what an MVP is. I think that we should take a definition like that back in to our teams and at the very least make sure that we are all aligned when we're throwing that term around, because I know for many projects and many years I simply assumed that my teams were aligned with me and really what we were there for, of doing, collaborating at some moments and not collaborating at others, was clearly not in the same direction and as tight as it could've been.
What I think is nice to think about is.
Particularly if you are sort of conducting experiments towards or in hopes of getting to that minimum viable porduct, you might like to think about the MVE, the MVP and the MMP.
So the MVE is what I'm renaming Eric's MVP or what I know Steve calls an MVP test and I'm calling it a Minimum Viable Experiment. So you can run those interviews, you can run that landing page, you can run sort of a Wizard of Oz test, you know we're gonna start doing that with the startup that I'm a part of, you know the vision for something is, for our product is that it's an automated check-in for employees, but in the early days it's just gonna be us that are sitting behind that slack interface as humans like Wizard of Oz chatting with our employees.
Now we don't know yet whether or not what we create there is gonna be an MVP.
That's just a Minimum Viable Experiment for us where we're learning from some of our key hypotheses that we've mapped out.
Once we know that that's actually working well enough, we can sense that we're providing enough value that people start engaging with it, we know that we would have hit the MVP and if that's something that in it's current form we wanna then take to a broader market base we're gonna be able to package that up in some way, you know maybe make it easy for some companies to self on-board and start having this employee check-in and that becomes our minimum marketable product. The other way to think about it, is that, I guess the other thing to consider is that, most customers never liked the concept of minimum, what they really want is early and most people can't really go forth properly with the term viable, because it really just becomes a synonym for passable or at times even horrible.
So another way of thinking about it is, what are the earliest testable products? And I'm using products very loosely there, prototypes, interviews, landing pages, concierge tests with an advance et cetera.
What are those earliest testable products that you can put together in order to get to your earliest useful and usable product? And when I talk about usable here, I don't mean it in a term, in a way that a UX designer might hope something is as usable as it can be.
I simply meant that the customer can use it, right? So it's not a landing page that promises something. The customer can actually use this product and then your earliest marketable product.
And so with only a couple of minutes left, I'm not gonna go through this actually.
These are some techniques for Minimum Viable Experiments that you might like to think about in order to get to your MVP.
I've mentioned some of them.
You maybe would have seen DropBox invented in New World for online cloud document storage and they simply had an explainer video on their website. You know Zappos basically had an online shoe store and the head of Zappos would go down to the local mall and buy all the shoes that he posted on the website instead of having an inventory, so that was a Wizard of Oz type approach.
There's a lot of techniques we can use to run these Minimum Viable Experiments.
I guess my final ask for everyone is it's the very first thing, align your team on language.
That was the whole sort of intent of the 20 minutes that I've spent up here, just to make sure that you aren't you know going in different directions and without realising it.
Be clear in what it is that you want to measure as you're running those experiments in pursuit of your MVP.
Don't adopt the "visionary complex", the idea that we know what this needs to be, we don't need to go and speak to customers. Don't be too busy to learn off those customers. I'm definitely feeling that right now as, you know here I am sort of preaching all this stuff and I definitely think that I could be doing a better job in my team of practising what I'm preaching and actually getting closer to our customers rather than just running with a bunch of assumptions and the most important thing, you know the thing that I think hits me the hardest is the design of the team working products teams for while, is this idea that MVP becomes a synonym for that minimum releasable crap that I spoke about and really you need to limit scope if you want to reduce the impact of poor quality, because what your MVP really is about, is about speed and minimum and that minimum being the feature set, sort of not the quality that you release to your customer base.
Thanks very much for your time.
(playful techno music and applause)
