Planning & Launching the MVP

[00:00:00]
>> So, in particular, what I wanted to move on to was this idea of well, okay, so we know that an MVP is valuable, that it brings a lot to the table, but how do we identify what should be in our MVP? And partly, that goes back to the question that was asked about, well, hang on, if we've got an existing product, are you saying we go right back to only one thing from that existing product?

[00:00:29]
No, I'm not saying that. I'm saying, you need to define your MVP within the context that you're working on. So what do you consider when you're doing that process? Well, there's kind of different ways you can approach this, but my personal preference is that I look at the following things.

[00:00:49]
The first is the user need, right? So, what's the absolute core task that users need to complete in order to achieve their goal, okay? So depending on, if you've got an existing product, you've got an existing user base, and so you need to accommodate all of those existing requirements for those different audiences to achieve their goals.

[00:01:19]
So as a result, your MVP is probably gonna be a lot bigger than it would be if you were starting from scratch. If you're starting from scratch, then you might define just one small audience, right, and focusing just on their needs. So user needs is one kind of obvious area that you can use to define your MVP.

[00:01:42]
The second one is your value proposition. This is a little bit of a different element here, because your value proposition is about how you're positioning yourself in the market and how you're selling yourself in the market. And there is often functionality that has crept into an app over time because people have requested it, that isn't really in line with how you're trying to position yourself, what kind of thing you're delivering.

[00:02:14]
So let's take something like Figma, for example. Figma, you could use for print design. It's not designed for print design, it's not part of their value proposition, right? They're a digital design tool, but you could use it for print design, and I suspect there are people that maybe do a bit of print and a bit of digital that use Figma for both, okay?

[00:02:37]
And what will happen is over time those people will start saying, can I have this feature, which would help with my print design work? Well, no, we don't want to include that, even if it's a user-requested feature, because it's not a part of who we are and what we do.

[00:02:53]
And then the final aspect to it is time and effort, right? So as you're thinking about your minimal viable product, which features can be built relatively easily? Which features, if we've got an existing product, can we carry across easily? If it's really easy to carry them across them, why not?

[00:03:11]
Presuming it's still in line with our value proposition and user needs. But if something is more complicated and it's gonna take more time, then obviously you probably don't wanna include it initially. So this idea of identifying your MVP is really a useful starting point to bring clarity to the chaos of what could be done with this app.

[00:03:35]
And then, once you've kind of defined what you want your MVP to do, then what you wanna do is start trialing it, trying it out. And prototyping is always a great place to start. I'm sure that doesn't blow your minds, that I'm gonna suggest that you prototype your MVP before you actually build it, cuz it's a lot cheaper than building it straight all in code.

[00:03:58]
Prototyping obviously allows you to test by running usability testing with a small number of users on your initial prototype. But you can also prototype in code as well, and that's okay to do. Sometimes it's actually as quick and easy to throw something together in code than it is to build it in Figma, right?

[00:04:25]
Especially if it's got a lot of interactive components, because Figma sucks at interaction prototypes. It's full of bugs, annoys me, sorry, I'm making you laugh for my, [LAUGH] so I shouldn't say that out loud. So sometimes I will actually go, well, let's just kind of throw this together in code, in which case you can even do something like a soft launch, right?

[00:04:50]
And you can actually expose that initial prototype MVP build just to a small number of people on an invite-only basis. And say, we know this spits rubbish and it'll break and all the rest of it, but we'd love you to try it out. And then eventually you get to the point where your MVP becomes mature enough that you can actually launch it and then you can start monitoring it.

[00:05:19]
But all of this is really a kind of prototyping journey of developing this minimum viable product through stages, a bit in Figma, an initial rough build, and then something that's a little bit more mature. And each of those stages allows you to gather user feedback and understand their needs a little bit more.

[00:05:37]
And of course, once the MVP is live, then you're getting heat maps and session recordings and analytics, and all these kinds of monitoring stuff. So gathering feedback on your MVP is so incredibly important. And again, this is a another problem with MVP, so I often see, is that people go yes, we're gonna build a minimum viable product.

[00:06:00]
And then they launch it, and then they just move on to the next feature that they want to add. Well, hang on a minute, pay attention, right? Pay attention to what you've just put out into the world and what are people saying that they want back out of this?

[00:06:15]
Cuz they might not want any of the things that you've got planned in the pipeline. If you've got an MVP and then a backlog of features, you're doing it wrong, right? Because, how do you know what that backlog of features should be until the MVP is in the world, right?

[00:06:32]
If you're making assumptions about what your backlog of features should be, I mean, I'm not saying you shouldn't have a collection of things that you've got in your head, right? But they shouldn't be all scheduled, ready to go out after your MVP, because otherwise you've not listened to anything that you've got from the MVP.

[00:06:48]
So gathering MVP feedback consists of listening, monitoring social media, looking for reviews, reading every message that you get sent, this is invaluable stuff. If people are talking to you, pay attention to it. Then you watch, I use session recorder like a Microsoft Clarity or a Hotjar or something like that that allows you to watch users using your app.

[00:07:11]
And then you need to ask as well, are you sending out surveys? Are you arranging interviews? Are you creating feature suggestion polls with things like poll unit, where people can say, I'd love this feature and then others can vote it up? I was talking to Mark, who's the founder of FrontendMasters, and he was saying he spends a big chunk of his time arranging back to back user interviews of people that are using the platform.

[00:07:45]
So he can talk to them and he can understand what it is that they want added to the platform, and that's exactly how we should be operating, especially after you launch an MVP.