🎢Building MVP's and MMP's with Agile

Agile teams build strong and delightful products into the world: iteratively and continuously. Read more below.

Video Version

Credit: Tech Fleet https://youtu.be/5N3OqDBCMDo

Agile Product Development

If someone comes to you and says, I want to build a scooter, you have to determine what that long term end result looks like in the end, vaguely. The thing that you're trying to make money with and put into the market is called the the Minimum Marketable Product (MMP).

Then you work your way backwards and you say, what is the first thing that we should be doing that helps us validate the direction and is the most valuable thing that we could deliver first? The first release, and the incremental releases after that, are called Minimum Viable Product (MVP).

The way that agile product development works is you start with a cycle, working your way past the MMP to the MVP.

  1. Define your long-term vision (MMP)

  2. Define the first release (MVP #1)

  3. Deliver the first release quickly

  4. Gather feedback

  5. Review the vision and adjust plans

  6. Start building the next MVP release and repeat the cycle

  7. Build as many MVP's as you need to before you launch at market

MVP: Minimum Viable Products

At every point, you should be determining the bare minimum to deliver, the MVP that you should be working toward.

MVP is just a concept, but it's an important concept to know whether you're doing UX work or discovery work or development work.

The MVP itself is a concept that constitutes something that is simple, valuable, actionable, and testable.

The MVP is something that is very simple. Something that is valuable, usable, and testable.

MVP Build Cycle

You build and validate the MVP quickly. You deliver it. You adjust your plans, and you go back to the drawing board, back to step number one, and say how does that change my long term vision? Let's do another one, and then you build another MVP, and then another MVP, and then another MVP, and you just keep going through that. until maybe one day you release the thing to market.

Maybe you never release it to market. The process that you're going to learn , whether it be through research or design or strategy or chores or vacationing or accounting work, is how to scope a plan in the beginning, determine the highest priority for that, deliver that thing quickly, analyze it, and adjust.

The cycle of progress towards the MMP: You build, you evaluate, and you re-prioritize continuously. Credit: Tech Fleet https://docs.google.com/presentation/d/1xStUc5Gg_o6tjYAu-cwE_j6kXESscoRD_sI10LKWgDE/edit#slide=id.gc8ac60c30d_0_541

You iterate, you release it, you evaluate, you plan that thing for the next release based on your priorities at the time, and then you keep going. Meanwhile, the thing that you're trying to build may change, and you have to go back into what you were working toward to then change it.

MVP Requirements

And when you're gathering requirements, you don't do it all at once. If you're building an MVP, you have to talk about what it must have. So, sorry, cat. Can't take a cat chariot around in the first MVP because that's not the most important priority. I apologize, cat. I know that that's disappointing for you, and that's really hard to hear.

But what the scooter must have is that it must drive in the city. Can't go off road. It must be able to drive a reasonable speed. It must have one person seating Because it needs to meet the basic needs of getting around and then once we have delivered that thing We've delivered the must have through one to many iterations.

MVP requirements focus on the "must haves". Sorry cat, no cat chariot for you first. Credit: Tech Fleet https://docs.google.com/presentation/d/1xStUc5Gg_o6tjYAu-cwE_j6kXESscoRD_sI10LKWgDE/edit#slide=id.gc8ac60c30d_0_308

Responding to Change

We evaluate that thing as we build and after we deliver. We plan the next release And what that release looks like, we start it over again. Over time, what you're doing is you're building more value to users. You're not delivering all the value only at the end, like in Waterfall. So by the time you hit market, you've got a really strongly validated and really usable, really refined experience.

Over time, Agile teams deliver more value to customers iteravely through MVP development. Credit: Tech Fleet https://docs.google.com/presentation/d/1xStUc5Gg_o6tjYAu-cwE_j6kXESscoRD_sI10LKWgDE/edit#slide=id.gc8ac60c30d_0_473

Building the Scooter with MVP's

Here's how you would build that motor scooter with a cat chariot through Agile. Each time you do it, you build something usable and valuable and minimal. So to meet the basic needs, I'll build a skateboard. It'll take me three months out of the 18 months, but I'll get something quickly out the door that helps me validate the direction, and then I'll say, okay.

That validates the direction. Let's keep going. What is the next basic need that we can meet that kind of adds to the previous one? Well, we can add more stability. We can build a scooter with a handle. Not motorized. It just goes fast enough to get around, but it offers a little bit more stability and it meets a little bit more needs.

Building the cat chariot scooter with MVP's and MMP's starts with something simple like a skateboard to validate direction and need. Credit: Tech Fleet https://docs.google.com/presentation/d/1xStUc5Gg_o6tjYAu-cwE_j6kXESscoRD_sI10LKWgDE/edit#slide=id.gc8ac60c30d_0_450

And then you work on the fast things. And only if you have validated the direction of those MVPs, you know you're headed in the right direction with the MMP, and you start building the MMP. Notice how it takes 18 months still. But the things that we build in the first two MVPs are something completely different than what the end result should be, because they focus on basic problems that we're trying to solve.

What happens if your requirements change? What happens if you build that skateboard and you determine, okay, everybody just got a smartphone because the smartphone came out.

So we don't need a cat chariot scooter with a GPS. We need a bike. Oh, all right. That's cool. Pivot, change your direction, change your vision, change your scope, respond to the change.

Agile teams are expert "pivoters", responding to change over following the plan they had in place. This builds much stronger products at market because they have adjusted to the highest priorities. Credit: Tech Fleet https://docs.google.com/presentation/d/1xStUc5Gg_o6tjYAu-cwE_j6kXESscoRD_sI10LKWgDE/edit#slide=id.gc8ac60c30d_0_320

Head to the Next Lesson

Last updated