How to sell an MVP

00:00 Hello and welcome to Perspective. This is a show by founders of small indie creative agencies giving our perspective on starting and running our own companies. The aim is to provide some useful advice and inspiration to others as well as learn from each other and others we get to come talk on the show.

00:13 This is our 14th episode. My name is John Dark. I'm a director at Every Interaction and with me again today I have Dan Ghent from Lighthouse London. Hello Dan. Hey John, how's it going? I'm alright. How are you doing?

00:25 Yeah, not bad at all. You still worried about Brexit? I mean nothing's happened. No. So as far as I can tell. Not a lot really. No, I think we're in the stalling scenario.

00:38 I'm very comfortable with that. I recognise it as a sort of like procrastination. That's a zone I'm very much familiar with. Yeah, I think that's the idea right? They're just trying to let everything settle in and everyone's minds are eased to stabilise the situation and not let things get too emotional.

00:57 It's probably wise. Yeah, completely. So what's this week? Let's move on from Brexit. This week we thought we'd go back to talking about how we sell stuff again and in particular we want to cover MVPs.

01:13 So this is quite a hotly debated topic in the startup world and it would be quite interesting to cover it from an agency perspective. So as a sort of neutral starting point, according to Wikipedia, the official definition, in product development the minimum viable product MVP is a product with just enough features to gather validated learning about the product and its continued development.

01:37 Gathering insights from an MVP is often less expensive than developing a product with more features which increases the costs and risk if the product fails. For example, due to incorrect assumptions. And to me that's a pretty accurate and straightforward description of what an MVP is.

01:53 A little stale, not one I'd use in a new business meeting, but yeah. Yeah, so I guess when we do sort of sell in MVPs and we talk about them a lot and say to our clients and I would say we can get a little flexible with those definitions.

02:13 But to us I always sort of think of it more as just a way to prove a concept. Just the minimum amounts of stuff that you have to do in order to try and validate an idea that would make you want to invest further in it and progress the idea to get it more developed.

02:29 Yeah, sure. It's one of those kind of phrases like HTML5 and Ajax before it. It's like it does mean something but actually it kind of means whatever the person who you're talking to thinks it means.

02:42 And once enough clients think it means something else then actually it does mean that new thing now. You have to roll with what the people who are buying are calling it even if you yourself kind of sort of squash your protest at the fact that it's not actually what you think an MVP is anymore.

03:04 Yeah, kind of like user experience in a way. Oh yeah, exactly. Yeah, so I mean we always talk about, we always emphasize the V to people and we talk about an MVP. That word viable is always the important one to us in that you can go minimal but viable to us usually means something that has value to the end user.

03:27 I often hear people, well a lot of people do say that it doesn't actually have to provide any value to the end user. It only needs to provide value to the business and that's a perfectly legitimate statement.

03:39 But just with the way that we work and the types of things that we do, we prefer to get real user results from it which really means it needs to have some viability in order to be picked up by users and used in the first place.

03:52 And from user experience design perspective the viability of the MVP is always one of the more important factors. Yeah, I mean I think an MVP that doesn't provide much value to the end user, I suppose that there would be scenarios maybe if you're testing out a new kind of way of annoying people with pop-ups or something, you could do that.

04:14 But I mean I suppose most in the startup world that the value to the end user is the value to the business. Like understanding what the end user wants, that piece of learning is the value to the business that's doing it.

04:28 So yeah, I mean I don't see many that don't provide any value to the end user but I suppose it happens. Have you ever worked on an MVP where it didn't involve any code? Perhaps it's just like an Envision prototype or something similar and would you define that as an MVP?

04:46 No, I think if we're going to actually have any lines drawn in definitions, like when we talk about this stuff and like as we point out everyone uses different definitions, I would call that a prototype. So if I was showing how something might work, then I would call that a prototype.

05:08 I actually think a minimum viable product, it has to actually solve a problem for the user. It can solve it in a kind of clunky way, it can solve it in a roundabout way, a way that wouldn't ever scale.

05:20 But it does actually have to solve that problem. If you don't actually do that, then you're not kind of actually validating anything are you? And if the point of it is to be an experiment, not everyone sees it as that, but if the point of it is to be an experiment, then you have to prove something.

05:36 Someone has to have their problem solved by it. Yeah, I definitely agree with that. That's pretty much our philosophy as well. Which I guess in its strictest sense being user experience design specialists and not really doing any development in-house, then we never directly produce an MVP ourselves.

05:53 We always sort of just contribute to the process and work with other partners who would help us get the client to an MVP state. Sure. Yeah, we would usually just refer to other things as prototypes as well, and they just have their place in the process either for validating, testing or just being part of the evolution of the UI and UX to something that would go into a later stage of development.

06:20 Absolutely. But I mean, that's us, people that have actually thought a long time about what an MVP is and isn't. I find the term getting used for all sorts of things. And I suppose that's one of the things we'll come on to is the danger of both you and the client calling something an MVP, but your actual belief about what that is being quite different is normally a problem.

06:47 A plus side to the misunderstandings about it can be that if someone actually wants a product built and you introduce them to the concept of an MVP, you can actually be quite different to the other people they're looking at working with often.

07:04 Yes, that's very true. Yeah. What would you say to a client who came along and asked for you to help them produce an MVP, but what they were asking for the scope was so much larger and it didn't really feel like an MVP to you?

07:22 Yeah, I mean, it is a big challenge really to sell someone an MVP to start working with someone on an MVP because unless we're not a dev house, like a pure dev house.

07:32 So I can see that if someone came along to you and said, here's my MVP and they had a scope that you might just turn around and go fine, I will build that for you. You know, I will build your MVP. You're the one that's called it that I don't really care. What we're trying to do is think about it in terms of is it going to perform the tasks that you want an MVP to do?

07:54 And to get to that often requires a lot of back and forth, dare I say, innovation without being too cheesy. But, you know, that I suppose that is probably the definition of one of the things you're doing because what you're doing is you're saying, OK, you've got this problem you want to solve and we've got to try and work out the smallest thing we can release to provide some value to prove that people want this.

08:17 And finding that out actually takes effort and thinking and, you know, design basically. So often you instantly have to kind of break down that barrier of trust and say, look, you know, great, you've got this idea.

08:34 But if we are going to do an MVP, here's what we think an MVP is and we're going to need to reduce the scope of this, not because we can't build this whole thing, but because that's our advice for how you get to MVP.

08:49 It can be quite difficult because if they have passed this brief round to other agencies, you've got a chance to be different because you've got a chance to challenge them and say, don't build this, build something else. And if you get that right, it's incredibly powerful way of winning the work. But what you've got to remember is you can't disregard what they've done, especially if they're entrepreneurs.

09:09 I mean, they're often the person that's going to come to MVP. But even if it's someone in an established company who's got this new idea, you know, they're living thinking a lot about this.

09:21 Document, you know, they spent a long time on it. And entrepreneur may well have sat on the train every day thinking, oh, how am I going to solve this? And dreaming big on this product they're going to make in this business, they're going to build.

09:32 And you can't just take their document and go, do you know what? This is wrong. One thing I kind of like to try and define it with people is saying features that make it into a product are different to features in a brief.

09:47 So like features in a brief, like there's no cost to them. They're just a line you write down on a brief. They take no time to put there. And those features are actually someone explaining to you their understanding of a problem.

10:01 So by saying the features they use to solve it, they're kind of explain to you what the problem is. Like it's like a language to define a problem. They're telling you something there.

10:13 Like you've got to you've got to use that feature set as as a way of communicating. But then I always say, you know, that's a very different use of features to actually using features within a piece of software.

10:24 Like they're two different things. Like so I sort of often say this is brilliant. You know, this this brief explains so much to me through the use of the features you want to build.

10:34 What I want to do is work out what the features are when built solve this problem. What you don't want to do because they'll go safe. You don't want to be a difficult option.

10:46 What will happen is when the chips are down and people are about to invest money, the thing they thought off on the train every day for the last three months, even if you get them quite far down the line of, oh, read the lean startup and I'll look at, you know, if you get them quite far down that line, the safe option, even though, you know, as we all know, it's it's it's not safe to build big.

11:05 You know, it's riskier. The safe that's not you know, you've got to have a bit of empathy with them and see what this document actually means. It's not someone being stupid and writing down so many features. It's it's someone kind of showing you what they're thinking.

11:19 You can't just disregard that. So other than reading and interpreting a brief that you've been given, what other methods do you guys use to draw that information out of the client in order to define a brief that you can actually start working against?

11:32 Yeah, we use workshops and things. You know, we've got a couple of like if someone's serious and we kind of qualify them as, you know, being someone we want to work with. We've got some nice workshops like just we do like an hour before they've made the decision where we sort of start that process of how we can decide what goes in and start that work.

11:52 So just to show them the value of that thinking. Yeah, you only need to expose one or two. Hey, how will that email notification system work? Are they going to get a notification and then is it going to send to the rest of it?

12:05 You know, you start unpacking the complexity of what they're trying to do. You don't have to say we're not going to do it. That's what the magical phase two is for. You kind of just shift them off towards phase two.

12:18 So, yeah, so in that scenario, I think it's about being very careful about how you bring someone around to what is, you know, in my opinion, because that's why we do it.

12:30 So what is the way to start building a product with an MVP, a true MVP, not just a kind of like, hey, I'm saying MVP because I read it once.

12:41 Yeah, yeah. It is really important to go through that process and hear everything they've got to say and what they want to put in to a fully featured product and then recognize that feature, like you say.

12:54 And you just got to rank it in a priority order, really. You got to do your you could have your must have. Yeah, you should have your point to have and categorize these things and give them a priority.

13:05 And then you get an idea of really how how big this minimum part of the viable product really is. Yeah, and it's very difficult because the other thing that you haven't got, which anyone just going for the work based on the brief is you haven't got anything really to quote against because essentially what you're saying to them is we're going to change this strip it back.

13:29 How far are we going to be able to strip it back? Well, I don't know, you know, and I need to do some work to get to that point. So, again, that you become a bit of an unknown that way. I mean, we we we definitely struggle with that one.

13:41 I think I normally just try and ballpark people with a quite wide ballpark. I think quite a good thing to say to them is, look, if you're spending more than X, have we kept it simple enough?

13:52 Have we taken this seriously in bringing the feature set down something? Yeah, that's a good double double edged sword, isn't it? You're saying you've got to cut it down and you're also saying, hey, you know, if you go with us, we can almost cap the spending.

14:06 I mean, the one thing I've been just about the way you do it is like a feature to you like, OK, I'm not saying there's no complexity in design. But but you're closer to just that extra line on the brief, right?

14:18 A button, a mock up of a page or a proper piece of design on a feature. You know, the temptation just to design it and say, cool, it's there.

14:29 You know, when you don't have to build it, do you find that? It's hard for you to argue. Don't do it when you're actually not going to change the cost much. Yeah, you mean like making a making a custom design for everything and not having it having a direct correlation on our output.

14:46 It's necessary like it it affects it affects the build more than it affects what we're doing. Yeah. And and you can't you know, we we have the kind of motivational thing of like, oh, you want it to work like that.

14:59 Well, that's going to take us X, Y and Z more time. And that can be big. It can be months. Whereas for you, I suppose it's like, OK, we can design that feature.

15:11 It's going to take a few days more. Not you know, not a huge impact on your spend, but you shouldn't do it because it's a complex feature. You know, it's it's not MVP.

15:22 Yeah, well, these things are nearly always much easier to design than build. Yeah. And yeah, the design in the U.S. It's important to get right. But the implications of implementing that is often a much larger conversation.

15:36 And we just got to make sure those conversations are happening as a team. So whenever we're working in an environment in a sort of agile workflow alongside some other developers who might be responsible for delivering the MVP and building it, then they've got to be involved in all those conversations.

15:51 We've got to get agreement as a team what's going to be going in. So I guess it's no different, really. We're just not all in the same room at the same time all the time. Sure. More often than not, when we're doing this type of thing, we use one of our preferred partners to get the front end done.

16:06 So we'll be building the front end codes and that's quite often bespoke as well. Not using any frameworks. It depends on the project, but just the types of projects we tend to get tend to need that extra level of polish at the same time.

16:21 Obviously, the the actual functionality will be being built and then connected up to the front end once we commit that. I suppose actually in that regard, the cost of the extra features is actually just as high.

16:34 Yeah, having another party involved just means that you feel like you need to keep the communications a lot higher, a lot more frequently and get the client involved in those conversations as well.

16:44 Because when two separate parties are having a conversation about something, you want to make sure that the client is also involved because they feel like they should be in the know. Whereas if the team is all in one place and the client is now with them, then perhaps lots of conversations are going on without them.

17:01 That's I don't know, maybe just doesn't keep them as involved as much all the time. So there are some benefits to spreading the work out amongst different teams, other than just having perhaps a greater specialism in each of those those different teams who are involved.

17:18 But then you got to make sure that everybody on that team is in agreement about what the definition of that MVP really is. So you can help keep it in scope and on track as well.

17:30 Yeah, you've really got to approach it with a clear thing in your mind of what an MVP is to you. Like it doesn't have to be that definition, but it's got to be what you're trying to do and almost have some like values around it.

17:43 Because you've got to communicate that very early and very well to the client. You know, I'm always trying to come up with new ways of explaining the problems, you know, and I think trying to get them into the idea of complexity, like get a language going of why you don't add all these features like, you know, the cost of complexity.

18:03 I give every client a big lecture on it, you know, and how it's not just money spent on development time, but it's the fact that the whole thing starts slowing down.

18:15 And and really, especially when they're startups, the only thing they've got over someone who's an established startup is the fact that they haven't got any complexity. You know, they haven't built anything yet. And there's a cost of trading that in.

18:30 You know, the moment you can't build something because you think it's a good idea, like when you trade in that flexibility for the complexity of having a code base, having a product, even having some wireframes is still, you know, it's very hard to get some wireframes done and then just go, I'm going to rip these up and never think about them again.

18:49 Like the moment you start doing anything, you're like losing other options and it's kind of trying to explain to them that, you know, you won't meet someone that's now got a startup that wouldn't put a price on having that flexibility, you know, and wouldn't say to you and a load of people that have failed at startups that wouldn't say I'd kill to be back in the position you were having not put down any routes and still able to move in any direction.

19:18 Because that's eventually what will kill a startup is the inability to move to where the market wants it to be. And you won't have that problem if you've got no product yet. You can move wherever you want. You can change industry, change anything.

19:37 So it's kind of trying to get them into the idea of that cost, the cost of actually the cost of doing this beyond the money, because they see the money is very much that's what they think they're spending and they don't realize that actually, you know, in the long term, whatever they're spending, even even those tens of thousands, you know, I'm not saying they shouldn't be careful with that money.

20:01 But again, go to an established startup. You know, you don't stop spending money ever like so because that's if you stop spending money, it means it's gone wrong.

20:11 You know, it's failed. So so it's kind of about trying to just get them into this idea that it's about it's about learning and working out where their product should be without showing too many of their cards in terms of the amount of complexity they have.

20:26 So that's the trade off. It's like, how much can I learn for how little complexity? And so when you say, like, you know, would I show something that's not even developed? If it if it learns something, then then maybe prototypes can do that. So but I always just think a prototype is also for learning.

20:44 I think once you're talking about MVP, you probably need to be turning that learning into someone has actually tried to solve the problem, not just looked at a prototype and said, oh, yeah, I'd use that and actually gone.

20:57 Yeah, I did it. You know, it it worked. I went from end to end and got some value out of it. Because then because then you learn learn if they're going to come back, if they're going to share that kind of thing.

21:10 But prototypes, exactly. That's a prototype. You can just you can take learnings from it and it's a useful exercise to go through. It's not a product. And it's an MVP, something that is out in the wild.

21:21 It is being used by real users on a day to day basis. And you can't do that with a prototype. Prototype is just a simulation. It's a charade designed to allow you to take some learnings or progress your projects and little else more.

21:36 You know, I do believe that something like, you know, there's the concepts of Wizard of Oz MVPs and and things like that, where actually you have something that is very close to just being a prototype on the front.

21:49 But you are providing that back end legwork. You know, you're kind of you're accepting an email through a contact us form. You know, your your amazing software has an algorithm that's going to plan your night out.

22:04 You know, that's something like that. Just just drop, you know, click two buttons to tell us what type of music you like and what you like eating. And our algorithm will will work out where you should go tonight.

22:15 But actually, that just sends an email to someone who frantically Googles and gets back to them with an email, you know, like if because that then provides value back to the person. As long as you limit a number of people who can sign up. Well, you do. But I mean, I often again, that is I love it when people do that, because I think it's actually it's probably the truest way to do this kind of thing.

22:38 And even though obviously often it means not actually using an agency, so I don't meet as many of these people as I'd like to, but actually just going, look, I'm going to I'm going to with sticky tape put together a product.

22:51 So, you know, say that example we've just had. Yeah, they might not. They might have to ask what they're doing this weekend and it's not going to be tonight because I need to get back to them.

23:02 If you start trying to do that, you know, two things happen. One, you learn very quickly which parts of your process need to be replaced with technology, as you say, as long as you don't get too busy.

23:13 Well, what does too busy mean? Which part scaling is a very hard thing to work out when you're going to need to scale. You know, you're going to need to scale because everyone asks you the question of a Friday night.

23:26 You're going to need to scale because you get asked from hundreds of different cities over the course of the week. And there's lots of reasons to need scale. So something like that will show you exactly where your pain points are and the bits that you should first invest in.

23:41 Yeah, the bit you should invest in to produce the product, I think that to me, that's more of a simulated MVP. It's not much different than creating a marketing page for what looks to be a finished product with a.

23:54 But your email address here and we'll let you know when it launches coming soon. Absolutely. And then throwing some marketing at it. It's to validate the idea rather than actually test it and get something that's functional and improve it.

24:10 But if you offline solve that problem, like if you do send that email of a night out and that person goes and does that thing and comes back and says, great, can you plan my next plan plan next weekend for me?

24:22 You know, that's that's when you can start learning about, OK, cool. Well, that works, but everyone loves the restaurant recommendations. No one actually makes it to the nightclub.

24:32 Well, maybe I maybe I just dropped the nightclub stuff, you know, and basically you can start learning without spending anything. And I always think that the other great thing about that is you and the customer are literally emailing each other like, you know, the again, something that a big startup would kill to have is an actual honest report with someone whose problem they were solving.

24:56 That's why you get all these like drip campaign email things and the amount of start the amount of companies that give you plug ins for your for your site to like help you get user feedback.

25:07 You know, at that early stage, you can actually just be having an email conversation with someone and that that insight you get off that will be greater than anything you do. Yeah. But then equally with a product like that, the human touch of the email interaction is actually the thing that might be driving the conversion and the stickiness of the product.

25:26 And if you were to replace that with technology, then maybe that can't actually be done. It was the human aspect that made it so appealing. So there's always dangers of leading a client down these roads sometimes.

25:41 Yeah, sure. We do meet those people sometimes and it's all it's a bit of a long game with them. You're almost like, right, you know, you're ready to actually do that, which means you should go and do that.

25:51 If you can learn things without spending money, I can't honestly turn around and tell you not to. You know, you hope then that when the time comes to build, you're the one that said that to them, you know, this is how you should do it.

26:02 And they come back to you. We've got a bookshelf full of the lean startup. So anyone that comes along that's not heard of an MVP or hasn't read it, just give them a copy of it.

26:13 Just say, you know, that's yours. Doesn't matter if they potential to work with us or not. You know, copy the lean start doesn't cost very much. And what you're doing there is you're like leaving a little time bomb. I always think of like one day they'll pick it up or one day someone will go, oh, have you read it?

26:26 And they'll go, no, I haven't read it, but you know, you gave it to me. It's almost like you remember who gave it to you. Probably more than the name of the person that wrote it. It's like a business card. They're not going to throw away.

26:36 It is. I think definitely with something like this, where you're trying to change the way people think about stuff, you know, you're really trying to say, look, this is how we do it. I think things like that, like having some assets to do with it, like write blog posts on it, you know, called podcasts about it.

26:53 And if you've qualified that they're worth talking to and worth trying to work with, then then really just kind of push that content at them, like drip, drip feed it to them. Like, so, you know, have have a meeting them with you, introduce the concept.

27:07 Say, you know, we'll chat again in a few days, but then in the days in between be like, you know, this is what I'm talking about. Here's an example of an MVP is a case study is here's some books you should check out.

27:18 I think we found really good success with that in the people would come and say, oh, yeah, I read the startup MVP page on your site. And I listened to the podcast you linked to.

27:28 And because you really need a lot of trust to get an MVP done properly. Where it's fallen down for us before is where both parties have been saying, let's build an MVP. And then you get into building it and they're asking for weird and wonderful features.

27:42 And and you realize that you never define what it was to them. It just meant let's do it on the cheap and yours and yours and yours. And you're like, you're stuck there then you're having that conversation way too late.

27:54 So, yeah, I think it's I think MVP is incredibly powerful. You've sort of got to own what your own version of them is and you've got to communicate that so that people become comfortable with this idea of basically we don't know what we're going to build for you.

28:08 But please work with us. That's a tricky thing to sell. It is. It's very undefined and fuzzy, isn't it? Yeah. And to me, these MVPs, they're all compromise is always a big, big word that you need to use quite a lot in order to communicate what it is that that's going to happen.

28:24 Because it isn't about setting things in stone and it isn't about drawing a line in the sand. It is about compromising. And that applies to the client and it applies to you as well. I mean, as designers, you've got to be flexible.

28:34 You've got to get stuff done quickly. You've got to be able to let little details slip and make notes of them and put them in the backlog and come back to them at later stage when you can justify the effort.

28:46 To fix that little detail. But if it works, ship it, get it out there as quickly as possible to try and make some learnings from it. And as you say, the less you build at the beginning, the better you are.

28:58 I think flexibility is the other big word for us that we use when talking about MVPs a lot. And I think building as little as you can puts you in the most flexible position. And that flexibility is a massive competitive advantage in any market.

29:11 And if you were to speak to someone who's been building a product now for several years, they would probably say to you that flexibility is something that they really miss. And now that they built so much, it's very hard for them to change the direction of the ship and start doing new things.

29:27 They can't, they don't have that flexibility anymore. So completely. I suppose the one more thing that just came to mind that I'd say about it is you've also got to decide what you're actually delivering.

29:38 Because if we're saying that the point of an MVP is to learn enough to find that product market fit, then is that what you're delivering?

29:49 Is your deliverable product market fit? By that I mean, along the way, you've got to be working out what they're going to track. You're going to be working out how this experiment gets judged.

30:01 Success metric. Completely. And I think that is really difficult. I mean, it's something that I think sort of belongs with the founder, if it's a startup. That instinct around whether what they're doing is working.

30:14 I don't think it's healthy to have to ring up an agency and go, "Is what we're doing working?" You know, as a founder, you've got to feel that and know it.

30:25 So we talk about it a lot, but you've also got to draw that line of like, "Who's responsible for that?" And really, at that point, you can help them with the strategy. But I always feel like if you lay down a strategy for like, "Here's the five things we should track," and you get blank looks, it's almost a case then of saying, "Okay, do we actually do that part of the work?" You know, and it's also something you should build in almost decide first before you actually design the thing.

30:51 I often find like half of our MVPs, that side of things is a little bit fuzzy. Everyone knows it at the beginning, but then when it launches, does anyone check those metrics?

31:01 I don't know. Someone's got to take responsibility for that. But it's important to have goals, and those success metrics help define the goals, and then they help shape the decisions you make along the way to try and hit those goals.

31:14 It's important to have them. From our perspective in particular, it's important not to take too much responsibility for them as well, because there are lots of conditions way outside of our control that will affect those metrics, most of them in the marketing camp.

31:30 You can build the best thing in the world, but if no one knows it exists, then it's money wasted. And that's something to also always make people aware of, especially if it's their first time around, so that they need to be thinking about the budgets for scaling this thing and getting it out there.

31:46 And marketing, and if they haven't got that in their plan, then they definitely need to take a very lean MVP approach to make sure some of that budget gets assigned to that.

31:56 I was about to say, I think there's almost a second podcast in that post MVP, how you then drive it. Because I know we've both got startup clients who have built their thing and are now trying to run it and trying to steer it. And how an agency can fit in there, I think is also quite interesting.

32:16 But that's probably a separate conversation. Yeah, we'll save that one for another time. Bank it. Bank that one, absolutely. Yeah, I mean, the other important thing to cover here, I think, is the value of an MVP.

32:29 As a sales tool, you can express to clients and what you can say to try and help sell it in in the first place and try and convince the client to use you to do that process as well.

32:40 So I mean, we always talk about the flexibility angle and just trying to avoid too many preconceptions that they may have around their idea and their solution to the problem that they found.

32:54 Because until you've actually validated it in the market, it's very difficult to fully predict what's going to happen or what people's reactions are going to be to it. Yeah. And so starting small, obviously, puts you in a position where you can have that flexibility to adapt to change as you learn. And then, as we were saying, the bigger it is, the more you build, the harder it is to change. So if you spend too much time and effort building all this stuff up front, then you might put it out in the market and then realize you've got to change loads in order for it to be a success after seeing users actually use it. And then that's much harder to do because you've taken it further. So the less distance you travel, the easier it is to turn that ship.

33:39 Completely. It's just about de-risking the project to a large extent and just trying to make their investments go a lot further. And that's a good thing to do for you as an agency as well.

33:51 So if your approach saves the money and time in the medium to long term, then they're going to be very grateful for that and keep coming back to you to continue to progress the idea and take it into the next iteration, evolve it and hopefully turn it into a successful product that will be well known in its market and do a good job of the problem it's trying to solve.

34:16 Absolutely. And in trying to sell it, don't ignore all the proof. Show people what Dropbox looked like when it first launched. Because this I think is one of the things that people are reluctant to do it is because they're like, "No, I don't want to look crappy. I don't want to look half baked." Show people what the big startups that they think just appeared looked like in the early days and what they were doing and tell those stories.

34:40 Just look at Twitter. It was an SMS service when it first started. And even when they did get a web service up and running, they couldn't keep it stable. It fell over nearly every day. And remember the farewell? Yeah, exactly. Completely. Show people that this is how the big boys and girls do it.

34:57 This is how you do a startup. And there's plenty of material out there from the best in the business telling you to do MVPs to keep things lean as it were. Try and help them visualize the process by which you're going to get there. I think as I say, we do a little workshop, but tell a story about a client that built too much and tell a story about a client that didn't and get them visualizing themselves within that process and let them see how it would be successful because it's not a switch. MVP is the way. Or at least keeping things simple is the way.

35:43 And it's just sometimes hard to convince people to do that. So that's where your creativity comes in. Use those design skills to get design work.

35:55 Excellent. And I'd add, just don't oversell it. It isn't always the right answer to every problem. There are often times when you're given a brief or a problem to try and solve and an MVP isn't the right idea. Maybe a prototype is the right idea in some scenarios. A pre-MVP or sometimes it could be that an MVP just isn't going to cut it. And there's already a lot of competition out there and this is just a different take on that. And so you need to take a bigger step forward in order to have a chance of making a splash at the market. So there are all types of scenarios and MVP is not a one size fits all solution. Yeah, have it as a tool solution to the right problem. Exactly. And I'd also give clients a bit of leeway with it. I mean, we've got clients, bless them. And we did do a genuine MVP with them a long time ago and we're working with them many years later as they've grown the project. And every time we add a new sort of feature or a new application to the suite of applications that now exists, they call it an MVP again. Each time it really isn't, but I'm not going to knock the ice cream out of their hands.

36:08 Everyone's guilty of doing this stuff and they can call their product whatever they want and I'm not going to knock them down for it. I'll put MVP on the invoice, that's fine. Yeah, you're billing the same. So yeah, I don't mind what people call them as long as we get paid for it. Nice. Well, hopefully that's been of use to some people. If you've got any further comments on this, you can hit us up on our websites at www.perspective.fm. You can leave some comments there. And on Twitter we are underscore perspective FM. All the other links are on our websites. If you're listening to us via iTunes, please go in there and give us a rating. It helps us a lot. Also, if you haven't done so yet and you like the show, please tweet about it. Tell your friends. Referrals are some of the best ways to get other people hearing our podcasts and share things in our industry. So we'd appreciate that very much. I've been John Dark at Dark John on Twitter from Every Interaction @EveryInteract. And Dan, where can people find you? Personally, I'm @GentusMaximus on Twitter. It's a long story. Work stuff is @WeAreLighthouse or WeAreLighthouse.com. Yeah, absolutely. Any feedback appreciated? Good stuff. Thanks very much and we'll see you all next time.