MVP is not another word for iterations - it's for learning

Posted by Marcus Hammarberg on May 13, 2013
Stats
In recent years the Lean Startup movement has really taken off. For a great reason as well. It's a really appealing and excellent described framework for how to get validated learning of your startup idea fast.  For me as a Lean-dude it all sounds very nice and fits nicely into my current understanding and beliefs.

But as always ideas like the ones presented in Lean Startup will be stolen, then tweaked "a bit" and then finally declared unsuitable for the things that it didn't was intended to solve in the first place. I've seen it again and again; agile, scrum, specification by example is just a couple of examples that comes out top of mind.

In this post I'll share some things that I've been thinking about around this recently. If I'm wrong about these things I look forward to your comments and further education on the topic.
In recent years the Lean Startup movement has really taken off. For a great reason as well. It's a really appealing and excellent described framework for how to get validated learning of your startup idea fast.  For me as a Lean-dude it all sounds very nice and fits nicely into my current understanding and beliefs.

But as always ideas like the ones presented in Lean Startup will be stolen, then tweaked "a bit" and then finally declared unsuitable for the things that it didn't was intended to solve in the first place. I've seen it again and again; agile, scrum, specification by example is just a couple of examples that comes out top of mind.

In this post I'll share some things that I've been thinking about around this recently. If I'm wrong about these things I look forward to your comments and further education on the topic.

MVP

The thing from Lean startup that many people seems to pick up on lately is the concept of a MVP - minimal viable product. To understand what that really is we need to step back a bit and put it into the Lean startup framework.

At the heart of Lean startup thinking we find the the scientific method. This ties in nicely with Dan North's ideas behind deliberate discovery. The main idea here is that we don't know what the finished product will look like when we start. Nobody does, not even the "customer".

You can easily prove this to yourself by asking yourself if you got to redo a recent project; would it go faster? Probably yes. But why? Because we learnt stuff, we did things wrong the first time around and we got new information later in the process that pivoted our thinking.
If we could try to eliminate uncertainty earlier in our process we could probably learn faster and hence make better decisions earlier.

The same goes for Lean startup - we want to learn what our customers wants as early as possible. We might have a hypothesis about what they want but until we've tried it out on real customers it only that: a hypothesis.

From http://lean.st/
In Lean startup terms we run experiments by creating a so called Minimal Viable Product - MVP. That is: the smallest possible thing that we can test on our customer to see how well our hypothesis hold of fall. Lean startup calls this the Build-Measure-Learn-loop.

In my understanding the main thing about this MVP is that we want to learn from it. We have a couple of unanswered questions that we want to get answers to from our customers.

Quite often, as I've seen it, MVP is used as a delivery package. That is - a thing we work on for awhile to then release. I've heard people talking about MVP-0, MVP-1 ... MVP-N or that this project is about 6 MVPs long.

I think we're missing the point with MVPs if we're starting to equate them to delivery packages. The main focus is on learning. What do we expect to learn from this? What do we think will happen? How can we change our thinking for the next thing we throw out there?

User stories, MMFs, Themes and Epics

Things that often get's intermingled with MVPs are user stories, epics and other things. They are not the same things and I even think that they cut across another axis altogether. There's a great post by Michael Cohn on what user stories, themes and epics are. Here's my thoughts:

  • A user story describes a functionality from an users need. It's usually small and typically takes around a week or two to complete for the team. It's not fully specified on paper but rather is a "placeholder for a conversation"
    • When the team starts to work with an user story they might break it down in tasks that needs to be completed in order to complete the entire user story. These tasks can vary in size from just a couple of minutes to several days. They are totally optional to create and can be viewed as the team check-list-of-actions.
  • Going up the scale there's something called an epic. That's a big user story. Bigger than the team wants to manage, which in other words translates to something that's bigger than 1-2 weeks worth of work. They can still be useful in early stages of planning, since we can leave big stories in there and break them down as we start to work with them. 
  • Theme is a term that I've never used and seldom heard about. It's a group of related user stories, like all the stories around buying stuff on our site.
  • MMF or Minimal marketable feature is yet another term that is used from time to time. I use this term as meaning: the smallest thing we would advertise on the site a 'new feature'. "And now you can also log in via Facebook", "In this release you can search on the first name of the customer as well as the last name" are some examples. An MMF can be part of an user story or several user stories. It really don't cut along the same axis.
That's how I have understood the terms and how I have used them during the years I've been talking about user stories. 

Eeeh - why did you write this?

The use of MVP is a mindset thing. MVP puts focus on learning and we embark on a discovery journey. I really like this idea and I think it's a powerful way to approach what you as a team do and plan for. Some examples:

Instead of asking "When will this feature be done" you can ask "What do we want to learn? What is the smallest thing we can do to learn that?"
The latter questions open up for discussions and invites people to come with suggestions and ideas, whereas the first one is an order that we have to adjust to.
It also meet the often used "we need to have all of this before we go live" or "we need to build the complete function". No you don't. You can fake it. You just need to build enough to learn from it in order to take a more well-informed second step.

When stuff is in production it's not done. It' just the next phase of learning. Following the build-measure-learn loop above we've just built it. Now let's measure and see what we will learn that will affect how we do the next lap around the loop.

In one team we threw around the idea of having a loop-shaped-kanban-board. That felt a bit cumbersome to handle on the board but the idea was really nice. We decided to put a stronger emphasis on learning when doing planning and follow-up instead
"How far have we come/What's left?" are replaced with "What are we learning now/What's next?" The difference here is again in inclusion and invitation  where the second type of questions are more inviting, focusing on WE and OURS rather than YOU and YOURS.
    I think this shift in perspective is very interesting and could prove rewarding as it put the whole team into the same mindset.

    Conclusion

    The difference between MVP and User stories/Epics is one of mindset. MVP focus on learning. An MVP can consist of an user story, a bunch of them (theme), a really big user story (epic) or part of an user story (a task). That's not important. What are we trying to learn from this. That is important. And a useful question to ask too. 

    My two cents.


    Published by Marcus Hammarberg on Last updated