Q: Your MVP is neither M, V, nor P. What gives? The Minimal Viable Product (MVP) is every product manager’s favorite punching bag these days — most writing on the subject these days is a feverish attempt to come up with a new acronym with less baggage. Much of that dissatisfaction boils down to the fact that the concept of MVP has been co-opted by non-Agile types to define a Phase 1 of a larger project. Phase 1s often get defined by the features that happen to survive a radical pruning of scope to meet a deadline — you took out all the fat and here’s what’s left, so it must meet our customer’s need, right? Phase 1s usually don’t feel like real products — they put a lot of effort into building things “the right way” but focus more on the quality of that output than on delivering business value. MVPs are a whole different beast — by definition they are full featured enough to solve the customer’s problem, but rough around the edges and rarely built to last. If someone has to hand crank an Excel sheet and mail it to a third party vendor every time a user clicks a button, you’re probably on the right track. Sometimes even a successful MVP gets thrown away — what minimally meets your customer’s need may not be a part of the solution that fully meets it. And that’s OK! Agile teams tend to be OK refactoring their code, but refactoring the entire product concept can feel wrong, even when it’s the right thing to do. Why is a true MVP such a hard thing for most teams to execute? A: It’s hard to be Agile! The problem lies in the structure of most companies (ironically, except for their product teams). In orgs that are centrally planned and budgeted, calling your Phase 1 an MVP has real advantages. You get to use Agile language, tease its benefits and create a little breathing room for you to improvise without really forcing changes to the larger process that all teams have to follow to get funding. Creative budgeting can enable Agile teams to iterate by hiding complexity and uncertainty beneath large line items. This can be a really good thing for those teams. But it has also led many otherwise Agile people to believe that if they are iterative and flexible when they write code, the rest of the product process can be rigid and sequential, as long as their milestones aren’t too big or far apart. Even if they know this is wrong, most teams just aren’t up for the fight. Building product is messy and hard, and you need air cover to do it well. Frequently, that air cover comes from hashing out a lot of unknowns up front and buying support through a rigorous design process and internal sales job. But that approach has real consequences, especially for the breadth of ideas you are able to consider and the degree of agility you retain at each stage. One popular metaphor for how to think about iterative product development is skateboard-to-car: There’s a lot to like about this. The thing is, if you sold your stakeholders a car during the design and ideation process, your skateboard MVP may not actually be viable, especially if your actual implementation of two wheels and a plank deviates from the expected. Your stakeholders may be willing to humor you as you build towards the thing they actually want, but you sold them a car and they are not going to shut up until they get one! Maybe they don’t feel like riding a skateboard, because they are not 14 years old and would prefer not to die today. And if you change your mind and decide a rocket powered skateboard is a better destination than the car, you have to reset expectations on the fly. Non-Agile design and discovery mated to Agile dev produces a lot of these unsatisfying moments. Building sales collateral and selling the end product to reference customers also tends to Waterfall-ize the product concept such that your MVPs seem unfinished and inadequate. Of course they are! But it’s not your customer’s fault or stakeholder’s fault that they were sold something else, which you don’t appear to be delivering. That’s why a new approach is warranted. Hype your vision, not your wireframes! I believe the core issue here is how we talk about our products and what promises we make about them. Most teams specify and build much more than they need to, especially for their MVPs, because they are afraid to leave details to be worked out just-in-time. PMs fear that their devs will complain about a lack of specification, that their executive sponsors will think they haven’t thought things through, that customers or salespeople will revolt if anything less than what you promised shows its face in public. All of those fears are completely reasonable, but good product managers are willing to take that kind of heat, and spend political capital when needed to buy themselves and their teams the time and space they need to experiment. Teams who buckle under this kind of external pressure are much less agile, especially upfront, than they think they are. Agile tech teams spend much less time up front estimating and specifying than their waterfall brethren — the same should be true of Agile product/tech/design cross functional teams. In most cases, it’s the opposite! Product and UX work overtime to put together polished concepts and prototypes that can then be disintegrated and iteratively developed. It’s wasted effort, and often prunes your opportunity tree before you can see what is really going to bear fruit. The solution is to focus on the vision for your product and the outcomes that you want to be measured by — those deserve the attention. Your vision and goals should be big and bold and polished, and well understood by all — the vision is what you use to buy the space you need to create the product. The rapid cycling you do in design and discovery is for your eyes only. There’s a reason sausage makers are vegetarians! And aligning your eventual product to a vision is much easier than aligning it to a specific feature set that you sold your stakeholders a year ago. There is a huge difference between “We are going to build a website, as detailed on pages 23–78 of the attached spec” and “We are focused on satisfying customers a, b, and c, and we think we can do it by moving metrics x, y, and z, and here are a few ideas on how we might make that happen”. This is not easy, and we all make compromises in trying to get buy in from others who aren’t comfortable working this way, but it’s so important for us product people to emphasize that it’s the outcome, not the output, that matters. Just do less Writing code in a thoughtful, iterative, test-driven way is a wonderful capability to have — and a lot of great dev teams out there have figured that part out. But it’s a whole different thing to be agile about the rest of product development — ideation, concept, design, and planning. Aligning everyone on a vision, doing just enough to remove impediments, and defining iterations in a way that is not prescriptive about next steps and about the ultimate deliverable, doesn’t come naturally to most teams, or product managers! Many PMs succeed by being really good at details, but the best ones are big thinkers who know what’s in the weeds but choose not to live there. Your job as a product manager is to be clever, but lazy — you manage the vision and stakeholders while allowing your teams to breathe, and locking onto successes as they happen so they can be productized. It’s easy to do too much and narrow the realm of possibility. Give your teams breathing room by giving them goals and boundaries, but not answers — they need leeway to move fast and come up with creative solutions to problems, rather than a pre-baked plan that they can break down and sprint. I’m sure I am not alone in considering Paul Rudd a national treasure. I leave you with his words of wisdom (h/t ) below. Channel your inner surf instructor, enjoy the ride, and try a lighter touch to make your teams more Agile. Just do less! Forgetting Sarah Marshall Senior, Lead, or Principal developer in NYC? ! Want to level up your tech team? ! Stride is hiring See how we do it www.stridenyc.com Originally posted on the Stride Blog . Author: Dan Mason

Discovery

Funding

Too Long; Didn't Read

Developers: Build Less. Deliver More. [Learn how]	

You are doing too much. Do less!

Too Long; Didn't Read

Companies Mentioned

Stride

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

You are doing too much. Do less!

Too Long; Didn't Read

Companies Mentioned

Stride

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

RELATED STORIES