Doing the minimum

 The concept of a minimum viable product (MVP) has become so mainstream that now even vice presidents are misusing the term. People have been bastardizing the wonderful notion of an MVP for more than a decade, so I suppose vice presidents butchering it was inevitable. Yet the splattering of bloody bites of bogus, bloated blueprints still sickens my stomach as I swallow our senseless schedule. Why are the simple ideas often the hardest to heed?

Given how everyone always seems so overwhelmed and understaffed, you’d think that doing the minimum necessary would be desirable. Instead, individuals, leads, group managers, directors, and vice presidents continue to push bold, big bets instead of iterative, incremental improvements. I love big bets, but bringing them to life is best achieved through iterative increments.

Which brings us to the real meaning of a minimum viable product. It’s not a means to ruthlessly prioritize and whittle down a plan until it is deliverable in the desired timeframe with the fewest resources. An MVP is a means to deliver a new experience in small, fast increments using customer feedback to improve and shape each iteration. You always deliver the minimum necessary to receive the next round of valuable customer feedback. Think that’s what you’re doing or that such an approach is impossible for your super special something? You’re wrong.

Too much

Many teams think they are shipping a minimum viable product, when actually they are shipping too much, too infrequently, with, ironically, too little coherence.

• It’s too much because all kinds of unessential features, buttons, and options are included. Ask yourself, your program manager (PM), or your product owner, “What would we deliver if we had half the staff, budget, and/or time?” Focus relentlessly on the fundamental customer experience and value you’re delivering.
• It’s too infrequently because instead of reacting to differentiated customer feedback every day, every week, or every month, teams iterate once every quarter, year, or even less often.
• It’s too little coherence because the delivered scenarios are fractured or incomplete, preventing customers from providing useful feedback even after investing all the excessive work and time.

People love Henrik Kniberg’s wonderful MVP illustration of the stages from a skateboard to a car. Unfortunately, the first MVP that many teams deliver is a skateboard with motorized, interchangeable wheels that only goes straight. It’s so disjointed, confusing, and dysfunctional that getting any kind of coherent customer feedback is hopeless. The extra time creating those motorized interchangeable wheels is wasted, and customers can’t even guide the skateboard. Pathetic.

Remember: The whole point of delivering an MVP is to receive useful customer feedback that’s differentiated from the previous iteration. You can only do that if the MVP delivers complete (at times limited) scenarios.

Ask yourself, “What’s the solution or experience we’re delivering?” “Does the current iteration provide that solution or experience?” “Is there enough that’s new since the last iteration to learn clear lessons from customer feedback, yet not so much as to confuse those lessons?” Each iteration delivers just enough to learn something valuable; then you adjust and ship again.

Eric Aside

More on using data in Data-driven decisions.

You’re special to me

Many teams think delivering their new experience in small, fast increments is impossible, when what’s actually too hard are their heads. They say, “But our project is special! We have multiple layers that all must work at scale before we can provide the full experience.” Wrong. Every project has multiple layers that all must work—you’re not special.

Delivering in small, fast increments requires you to break your project down into the basics, then follow up by offering ever-increasing capability shaped by customer feedback. Hard-headed, old-fashioned engineers only see work breakdown one way: structural (layers and components). However, you can also break down work by experience, by customer segment, and by scale unit.

When you break down a project by experience, you build the full experience one piece at a time. For example, instead of designing an entire game at once, start with a single room, and expand from there. “But we need to tie the story together,” the gilded game designer guffaws. Fine, but what will the critical elements of gameplay turn out to be? If you started with one room and game-tested it, you’d receive the customer feedback you need before investing in the rest of the experience.

When you break down a project by customer, you provide a solution for one customer segment before moving on to the next. For example, instead of designing for all customers of an online store, start with US customers that know what they want. “But then we’ll miss global customers, third-party suppliers, social mavens, upsellers, regulators, gift buyers, and bundlers,” the store manager moans. Fine, but how will you know what layouts, visuals, and flows most effectively ease your customers through a sale? If you started with the most basic customer segment, you’d receive feedback with the critical information you need before investing in the other segments.

When you break down a project by scale unit, you handle the smallest unit of scale, and then expand one unit at a time. For example, instead of designing a new kind of service to handle millions of transactions per second across thousands of VMs, start with handling five per second on one VM. “But we’ll make all the wrong assumptions,” the agonized architect argues. Fine, but how do you know what the right assumptions are? If you started with one VM and gradually expanded your new kind of service to more customers, you’d know the right patterns and adapt your design to real load.

Eric Aside

More on iterating your way to success in The value of navigation.

Unimpressed

The griping group manager groans, “Where do we find time and resources to deliver small, fast increments? Our current plan is already understaffed and overbooked.” I’m unimpressed. Since when does it take a huge team to deliver something small? How did you get overbooked delivering the minimum? It doesn’t and you didn’t. You’re playing the old game of schedule chicken instead of embracing MVP.

Creating a minimum viable product allows your teams to stay small as you create something big. “But I’ve got to deliver the big burrito in time for the whole enchilada convention!” Guess what? Doing it wrong all at once is slower than doing it right a piece at a time. There’s less wasted design, wasted code, wasted validation, and wasted rework.

As a bonus, delivering an MVP means your product is always in a deliverable state. The variables are how many experiences are ready, how many customer segments are served, and how much scale is available at the time of the enchilada convention. All those variables are manageable, and meanwhile, you’ve delivered a product customers already appreciate. Tasty.

Eric Aside

More on right-sizing teams in Span sanity—ideal feature teams.

Customer obsession

I know you have a beautiful vision for your product, with a gorgeous design and a pure architecture. Unfortunately, customers have a way of muddying your vision, finding gaps in your design, and exposing faults in your architecture.

Instead of building the whole product at once, build it a customer-engaging piece at a time. Ship small increments fast, gather the actionable customer feedback you need, adjust and improve, and then ship again. Restrict your customer audience as you iterate by considering the scenarios, segments, and scale appropriate for each release.

You’ll still deliver your full, big, beautiful vision. The difference is that you’ll deliver it faster, with fewer resources and better targeted functionality, to customers that already love it. I know it sounds scary and radical, but give it a try, and then do it a little more, until you and your team love MVP.