If you’ve been in the technology space for some time, you’ve almost certainly heard the term “minimum viable product” (MVP). It’s become so pervasive that “MVP” has become somewhat of a golden rule for product managers in some ways.

The MVP framework is excellent in theory. It prescribes that product managers should avoid designing massive, monolithic products that will take a long time to build and won’t yield actionable results for months and months.

Instead, it encourages them to come up with a minimum set of features that would make a product “viable”, start by building that and launching quickly, then rapidly iterate on that initial set of features in order to arrive at a truly awesome product that users love. The benefit of this approach is that it allows for failures to happen sooner, and it depends on actual observed usage of a product to drive product iteration, rather than guesswork and conjecture. This reduces the overall risk associated with the product, and makes it less likely to dedicate a lot of resources and time towards a product that ultimately may never be successful.

This all sounds pretty good, right? I agree with you. Except for one hiccup:

If you use the MVP framework, you’re still faced with a big challenge- what exactly constitutes a “viable” product?

Answering this question improperly can derail your product’s success, rendering the neat-sounding MVP framework ineffective. So is there an alternative framework that product managers can use to decide what features to start building first?

Yup.

Behold, the Hypo framework

At Kinnek, we like to use what we call the Hypo framework (short form of “Hypothesis”, because we’re so busy building awesome product that we don’t have time to say the full word).

The Hypo framework is based on a simple idea- in order for a product to achieve success (however you define that), there are multiple hypotheses that must be tested along the way. Rather than framing your product in terms of what features should be built and when they need to be built, you instead reframe it as a set of hypotheses that need to be proven true in order to reach the ideal product state.

Once you have all of your hypotheses laid out, you can see which hypotheses are most foundational and which are more dependent on other hypotheses. This should help you determine the order in which you’d need to test the hypotheses.

Now, you can use the MVP framework to craft your plan to test each hypothesis, if you’d like. But, you have a much more solid understanding of the “why” and “when” of your product development efforts.

A simple example

Let’s say that we are building a mobile app that helps users order Indian food delivery in New York City. Let’s call the app Delhicious. For the sake of simplicity, let’s assume that marketing/distribution of our app is not going to be a problem- everyone who would be interested in using the app is able to find out about it and download it.

1.) First, we think about the ideal product manifestation: Every person in New York City who enjoys Indian food would download our app, Delhicious, and use it at least once a week to order Indian food delivery to their home or work from a selection of many Indian restaurants.

2.) Next, comes the real crux of the framework: We have to break down this ideal product manifestation into a series of hypotheses that need to be tested.

• Hypo 1: We would need only a few Indian restaurants on our platform in order to be successful (as opposed to all the Indian restaurants in New York).
• Hypo 2: Restaurants would be willing and able to provide updated menu pricing in the app so that it wasn’t stale.
• Hypo 3: Users would search what they want to eat by dish, rather than by restaurant.
• Hypo 4: Users would want to explore Indian restaurants by neighborhood.
• Hypo 5: In order to get users to really be engaged, they would need to be able to revisit past orders and place the exact same order again.
• Hypo 6: We would not need special deals from restaurants to entice users; the workflow benefits and time-savings alone would be enough to get them excited.
• Hypo 7: Ordering food at home and ordering food at work would require the exact same workflow with no special circumstances for either case.
• Hypo 8: We could enable orders to be sent to the restaurants without fully integrating into their systems.
• Hypo 9: We would not need restaurants to “sign-up” to the platform. We could simply send them orders from users without requiring any additional workflow and still make money from this.

The list could go on and on, of course, but you get the idea.

3.) Then, prioritize the hypotheses based on which are most foundational and work your way up to the ones that are most dependent on other hypotheses. I won’t go through the whole exercise here, but from the hypotheses above, you can tell that Hypo 9 is probably more foundational and important to test out first before worrying about Hypo 7.

The takeaways

The Hypo framework has helped us a lot at Kinnek, especially because our product is extremely complex. There are non-obvious solutions to our most pressing user challenges so it’s often difficult to decide what features to build first. As with any similarly complex product (especially marketplace-type products), it’s dangerously easy to get caught in the never-ending downward spiral of building feature upon feature and not really making any concrete forward movement with your product.

When our product team started using the Hypo framework, we were able to launch large-scope products more quickly and more successfully than ever before. Additionally, by framing our product development efforts as a series of hypothesis tests, we’ve been able to transform what were previously considered “product failures” into opportunities to learn. The psychological implications of the Hypo framework are pretty cool—when hypotheses fail, that’s neither a bad nor a good thing—it’s simply a learning that can be used for future iteration. It’s helped us further our effort to be a learning organization.

Ultimately, the specific framework you use for product management is not going to be the main determinant in your product’s success. Don’t get too dogmatic about it. At Kinnek, we’ve found that the Hypo framework has helped us build products that our users love and that solve real pain points for them, and we’re able to do this in the shortest possible period of time. Your organization may find something else works for you and that’s great! If you want to learn more about how we measure product performance here at Kinnek, you can read this post.

If you want to help us test more awesome hypotheses while we build the most powerful B2B marketplace, we’re hiring. Check out some of our openings at kinnek.com/jointeam.

‍