Hackernoon logoProduct Vision and MVP: A Toolkit by@beti213

Product Vision and MVP: A Toolkit

Author profile picture

@beti213Betina Evancha

I’m not always there, but here’s a picture (hint: it’s in Brooklyn).

It sometimes feels like I have two product managers in my head.

The Visionary Product Manager: If we’re going to make something lovable, we need to handcraft every detail. Great products don’t feel like a compromise.

The Practical Product Manager: What are all these bells and whistles? If we can’t figure out how to cut scope, our competitors will beat us or we’ll never launch anything at all.

I spend bad days flip-flipping between these two perspectives.

I have good news: innovation and practicality need not be enemies. By changing the conversation to revolve around what’s important, you can satisfy both sides.

Things are going to get cut — your job is to make sure that the core value survives, uncompromised. You don’t have time to handcraft every detail — your job is to focus extra attention where it is most vital.

What follows are some ways to think about where to invest your effort.

Goal Rank Lens

“Why?” is the hardest, best question to ask yourself as a product manager. Why are you building this product? What is it trying to accomplish in the world?

These are not user stories — this should be about what the product is, not what it does. Your iPhone does a wide range of functionality, but it is your connection to the world around you.

Make a list of goals, and force yourself to rank them. Then grab your list of feature ideas and consider each feature relative to each goal. Does it help with the goal? Hurt? If you don’t know, it may be time to do some research (or see The Learning Lens below).

After this exercise, I feel like I’ve hacked my way through undergrowth with a machete: exhausted, but with a clear path forward. Invest in the features that address your most important goals. If your features don’t address your goals, abandon them and find some new ones that do.

Persona Lens

Another strategy comes from the world of user empathy. If you’re lucky enough to have personas for your product, dust them off. If you don’t, consider taking a little time to create them.

Then go through each persona one by one and ask yourself: what features are most important to this person? What features could she care less about? Is there anything she needs that we’re not giving her?

Make a ranked feature list for each persona.

Then use these lists as north stars. Double down on the top features for each persona, favoring the primary personas. If a feature doesn’t make any persona’s list, consider cutting it or scoping it down.

Voila, empathy.

Learning Lens

Some products have so many unknowns that wading through features feels pointless. You’ll know this is happening when you try to ask yourself whether a feature accomplishes a goal and you get stuck. And then you get stuck again, and a third time.

In this case, it helps to change your question from “How do we build good stuff?” to “How do we quickly figure out what’s good?”

Using the learning lens involves another ranked list (I know — I’m kind of a list person). What questions are stressing you out and holding you back from making decisions? Rank them from most to least urgent.

Now start with the top question and think about how you might answer it. Can you do some research? Can you talk to some users? Or can you build something cheap that will give you the insight you need?

This may sound like I’ve given all the power to the “Practical” PM, reducing scope and launching something low quality. Give me a minute. You’re not launching a product — you’re running an experiment. Once your experiment answers your question, its purpose is complete.

If it serves the new product well to build on top of that experiment, great. If not, you can throw your experiment away with good conscience — it’s a learning feature, not a user feature.

And one MVP trap: The Effort Lens

As a former engineer, I sometimes get frustrated with the squishy uncertainty of problem definition. The world of problem-solving looks so shiny in comparison. But using development effort to choose features is a trap that can get you in two ways.

First, you can build the easiest solution to the wrong problem. If you consider a list of features without a thoughtful lens, it feels natural to rank from easiest to hardest and start building from the top. But at best, these “low-hanging fruit” are incremental, unlovable changes. At worst, they clutter up the experience while ignoring real pain points.

Second, you can build the most interesting solution to the wrong problem. There are many interesting problems in the world, and solving them is satisfying, innovative, even noble work. But if you want to build something useful, you need to stay focused. By all means, make an easier juicer, but don’t worry about whether it can apply 8,000 lbs of pressure.

Early ignorance about development effort lets your team imagine the ideal solution together. Then the act of building might surprise you. Faithfulness to that ideal solution sometimes inspires problem-solvers to find creative low-effort solutions.

Just don’t choose features by effort, promise? Good.

Go Forth and Fight

Unfortunately, understanding what’s important is often not the end of the story. Stakeholders have pet features. People and resources need gathering and protection, and skeptics need convincing.

But having clarity on what’s important will help you cut through the noise. My wish for you: may you quiet the fighting in your head and build something beautiful, timely, and with limited bells and whistles. Cheers.

P.S. For the record, I’m not an expert at building great products or getting this balance right. Thank you to everyone who’s showed me one of these methods or stopped me on a particularly MVP-focused day and asked me “why?”. Here’s a gold star for making me better: 🌟.


The Noonification banner

Subscribe to get your daily round-up of top tech stories!