Building MVP's and MMP's with Agile
Agile teams build strong and delightful products into the world: iteratively and continuously. Read more below.
Last updated
Agile teams build strong and delightful products into the world: iteratively and continuously. Read more below.
Last updated
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.
Define your long-term vision (MMP)
Define the first release (MVP #1)
Deliver the first release quickly
Gather feedback
Review the vision and adjust plans
Start building the next MVP release and repeat the cycle
Build as many MVP's as you need to before you launch at market
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.
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.
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.
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.
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.
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.
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.
