Iterating on the MVP

[00:00:00]
>> And then once you've got that feedback, then you can start iterating, right, you can start improving it and adding stuff around it. And it's basically, I mean, we've all seen this kind of cycle before, so the whole thing goes something like this. You start your MVP with discovering the needs, understanding the users, setting your value proposition, all that kind of upfront discovery work.

[00:00:24]
Then you prototype your MVP, which you do a bit of internal testing on. And then you iterate on that MVP and do some more prototyping, and maybe the prototype moves to code and you test a bit more, and then you iterate on it. And maybe you do a soft launch with a small number of people, and you test with those and you iterate upon it and go round and round.

[00:00:45]
Now, eventually, you'll then launch your MVP. Now, once you've launched your MVP, right, then you start monitoring and you look at how people are using it, how people are interacting it. And then you refine based on what you've learned from them, of suggesting different things you could do, which are then implemented and then launched.

[00:01:08]
But then you monitor again, you refine again, and you keep going round and round in this loop. So essentially, you're never done when it comes to product design. And maybe that's another big difference between product design and some very informational websites like a marketing website. A marketing website, you can launch and yeah, okay, maybe update some content, etc.

[00:01:34]
But if it's mainly informational, there's not a lot of design work to do long term. When you get into the middle of that line that I had, and you get into e-commerce and those kinds of things, then yes, post-launch iteration becomes more important because you can improve your conversion rate through iterating and improving.

[00:01:53]
Once you get to a SAS app or a web app or product design, then it is the heart of what you're doing. It's the majority of what you're doing, and there's so much that you can iterate upon. You can iterate upon your MVP as a whole, but also when you launch future features, those features themselves need to be iterated upon, right?

[00:02:19]
And this is another thing that often goes wrong when it comes to product design is there is such a focus on pump out a new feature, pump out a new feature, pump out a new feature, one after another after another. And nobody's going back through the system iterating upon those features that have already been launched.

[00:02:40]
Cuz the chances of you getting the perfect feature first time that works seamlessly and everybody just gets and understands is frankly zero, right? There is always room for improvement about anything that you put into the world. Now, you've got a problem of mine. Because, well, hang on a minute, if we can endlessly iterate on our MVP and we can endlessly iterate on our features, how do we ever get new features out into the world, right?

[00:03:11]
There's a balance to be struck there. And this is where there's almost a little bit of project management stuff that needs to come into our role as product designers, okay? And obviously, we'll be working with the rest of the team of this, that we need to actually essentially start building backlogs, right, of work and we need multiple backlogs, right?

[00:03:34]
So I always find if you give it a fancy name, people are impressed, right? So I tend to have an optimization stream and an innovation stream cuz that sounds cool, or does to senior managers who love that kind of stuff, right? So the innovation stream, that's where you have your new features, right?

[00:03:57]
We wanna do something completely new, so we're gonna have this stream of work that is new features, right? And then we have an optimization stream, which is where we're iterating upon existing features. Now, how you split and deal with those two different streams will depend on so many factors, right?

[00:04:16]
If you're a one-man band, by yourself, you might spend half the week working on innovation and half the week working on optimization. If you're a team, then you might wanna split the team, and half the team works on innovation and half works on optimization. And then you might have separate teams that work on this different stuff.

[00:04:39]
But the principle of having two streams, two backlogs of work dedicated to new things you wanna put in the world and the stuff that you wanna optimize is really worthwhile. But obviously, there is another element to this which is, well, how do we decide what we wanna focus on first here?

[00:05:00]
What get at the top of that, right? Because traditionally, the way that these streams, these backlogs are organized in a lot of organizations is which is the most urgent, right? Which comes down to, have we got a big client that is screaming that this has to be there, otherwise, they're gonna abandon?

[00:05:25]
Or, well, this idea was suggested by the CEO, so we have to do that one next, that kind of logic, or we promised we'd launch this by next week, so we need to prioritize it, all of which suck, right? What you need is some kind of point system, some way of establishing the value of related products or jobs as they come in that decide where they go in the backlog.

[00:05:53]
So what happens then is as new things come in, they don't just go to the bottom of the list, they get pointed up and slotted into the appropriate place. So there will be some features or some things to iterate upon which never make it to the top of the list cuz they're rubbish, right, because they're not particularly worth doing.

[00:06:17]
So, fair enough, it's survival of the fittest. The things that matter the most wanna get to the top of the backlog and everything else can languish at the bottom. So how do you decide on this point system, right, in order to judge that? Well, we've kind of already covered it, really, when we identified our MVP.

[00:06:37]
We can apply points based on user needs, based on value proposition, based on time and effort, it's largely up to you how you wanna organize it. There's no magic way of doing it. But often, I tend to have two user-orientated criteria and there may be two business criteria.

[00:07:00]
So to give you an example, the business criteria might be the goals of the organization, what the organization is trying to achieve. Are they trying to achieve market growth, are they trying to customer retention, whatever? And then based on those goals, I will then rank it from one to five.

[00:07:20]
So it gets five points if it really nails the big goals of the company, and one point if it's, well, it'd be nice to have, but not essential. And then time and effort is another one that I often use. So with that one, it's like, really, it's gonna be really easy to do, then it gets five points.

[00:07:40]
If it can be really hard to do and it gets one point, okay? And then we might have user groups, would be another criteria you might have. If it's our primary audience that we're trying to reach and this new feature has been requested by our primary audience, that gets five points.

[00:07:58]
If it's been requested by a secondary audience and one that we don't really care very much about, then it costs one point, gets one point. And then there's also user needs. How important is it to those users, right? So if users are saying, we're gonna quit if we don't get this feature, then that gets five points.

[00:08:19]
And if they're going, well, this would be nice to have, then it only gets one point, and then you can put it in its place in the list. Yes, question.
>> That's similar to what happens in sprint planning, right?
>> Yes, but sometimes there is a danger. Well, you say it's similar to what they do in sprint planning.

[00:08:39]
There are so many different ways that agile and sprint are done, that it's very hard to definitively say it's the same or not. I've seen companies that supposedly do sprints, who don't do any of that whatsoever. And I've been in other organizations that have massively over-engineered it and their point system is so complicated, it takes about a week to work out whether anything should be done or not, right?

[00:09:08]
And there's committees involved and debates and discussions. I'm just saying, you need to find a simple, clean system to prioritize your work that works for you. Doesn't have to be the way I've just described it, but avoid it being over-engineered and avoid it being based on who shouts the loudest and what's most urgent.

[00:09:28]
That's what I'm driving at, really. Yes, go for it.
>> So I have a question on a lot of large enterprises will have a data science or business intelligence kind of organizations within them that are evaluating the success of certain metrics or features. And I wonder how designers can collaborate within those kind of organizations also not stifling innovation?

[00:09:56]
Because I know database decision-making is a very hot topic these days, and so how can you collaborate within larger enterprises while also making sure that you're producing something that is valuable and innovative?
>> That's an extremely good question because a lot of the people, a lot of the organizations I've worked with have business analysts who are going over data and that kinda thing.

[00:10:23]
I tend to switch my approach a little bit in those kinds of scenarios, and I shift to becoming more the voice of the customer, right? So I try and offset, that data is absolutely valuable, and I'm not in any way criticizing it, right? But it needs to be balanced with qualitative data as well, a more empathetic approach and a more qualitative approach.

[00:10:51]
So that's where my other course comes in really useful, where we talked about user research, and user testing, and those kinds of things, with a particular emphasis on the more things like user interviews, usability testing, facilitated usability testing, things like that. So I basically will lean more into doing that kind of work and making sure that feeds into the business analyst side of things.

[00:11:24]
And in a large organization, some of the stuff that I've been talking about here tends to happen more on the business analyst side than it does the product design side, and that's fine. That's okay, if they wanna set the roadmap, I'm entirely supportive of that. But then it's my responsibility as the product designer to feed into them the additional context that they need to know to make an informed decision because they have this bias towards the data over time.

[00:11:50]
Which is fine, but it's not the whole picture.