On Chasing the Minimum Viable Product

I’ve spent the last couple of years working in an environment where the phrase minimum viable product (MVP) was tossed around a lot, mostly in order to push a launch date up. I’ll admit to some guilt: I actually introduced the concept when I introduced an Agile approach to getting things done, but the thing about building an MVP is that you need to be clear that you’re still meeting the needs of the business: it’s not just a random concept designed to let you shorten a deadline.

Properly used, it’s a real tactic for delivering a quality product. Improperly used, it’s a ticket to long term failure.

The real trick to success is to make sure you properly define what needs to be included in your minimum viable product.  This means taking a wholistic view of the problem you’re trying to solve, clearly defining its components and identifying which ones are necessary for both your customers and your business to succeed with the product.

Sounds easy, doesn’t it? It’s not.

Understand your MVP vs. an Incomplete Product

You can’t launch an online reservation system that allowed customer  to book time without also  building the component that allows your staff to see the bookings. The two are fully dependent on the other.

Let’s consider an example. Imagine you start taking reservations in February but your first event is in May. That’s three months where all that matters is customers being able to book! Let’s launch the web site!

Good strategy, but a couple of points to ponder

  1. You’re not launching an MVP. You’re launching an incomplete product. Your staff still can’t do their jobs.
  2. If you’re not 100% confident that you’re going to meet the May deadline, you’ve severely escalated the risk of your project.

We Can Build That Later

Moving functionality to a post-launch sprint can work, but needs to be balanced very carefully against the risks of your launch

It’s a strategy that requires considering the second point we made above very carefully. You’ve created a hard, inflexible deadline. That’s fine as long as you’ve scoped it properly but what if your project’s goals shift even slightly between now and then? That could lead to new and urgent requests. What if there are unknowns in there that become unsolvable? What if the business learns about a competitor and the launch suddenly moves up a month? That might be a case where it would have been better not adjusting the schedule in the first place.

All of this is disruptive and points towards one of the biggest risks of this approach: burning out your team. This shouldn’t be glossed over. Your people are your biggest asset. Helping them to succeed is your job as a leader. Deadlines are important but they’re not arbitrary: work with them to define them, keep them visible, use a Kanban board to track your progress towards them, and don’t arbitrarily change them without consultation.

Everything is an MVP

Even in a mature business, every technology launch is an MVP. It may not seem like it, but you’re going to add new features and tools over time–very few technology projects don’t continue to evolve over time. This is one of the reasons its important to get this right–if your foundation isn’t strong, everything you add afterwards is on shaky ground.

There’s an old maxim about project management that says:

You can have it done well, on time, or on budget–choose two.

Agile’s not a miracle cure for this. It’s a framework that helps you make better choices, and hopefully helps you deliver higher quality solutions to happier customers. I’m a big believer in the continuous delivery model that Kanban supports, but remember that continuous delivery doesn’t mean continuous releases. Release your product when it’s ready what’s needed to work properly. That’s your minimum viable product.

Make it complete, and you’ve got a solid foundation. Go the other route and you could be in for some bumps in the road. The choice is yours.

Leave a Reply

Your email address will not be published. Required fields are marked *