So, you’re pretty sure you have one of the best product ideas ever. Let’s say it’s a cooking app for gourmet food lovers. We’ll call it … CookTastic. But it’s not just any old cooking app: This one does everything. It learns from the user’s favorite dishes and preferred flavor profiles and makes recipe suggestions accordingly. It posts completed meal photos -- with filters that put Instagram to shame -- on all of the user’s favorite social media platforms. Not only that, each recipe contains embedded tutorials to teach users advanced cooking techniques. In short, it pretty much does everything but cook the food.

And so what you’re most likely thinking right this minute is: “I need to build this asap. I need to get this in front of the public … I want my MVP!”

After all, that’s what most people do, right? Build, measure, and learn is the commonly accepted Lean/Agile loop at this stage in the game, after all. How else are you supposed to find out how successful your great idea will be?

But hang on a minute. You’re about to take a big risk -- without ever testing a single assumption.

Take a step back for a moment. What if … bear with us here … what if you build it and find out your assumptions are all wrong? How much money and time will you have wasted on that MVP?

Remember, the “M” in MVP stands for minimal, not “most every possible feature plus the kitchen sink.” And the “V” in viable doesn’t mean “very crappy” or “almost kinda sorta works.” Frankly, viable should really be replaced with “awesome.” As in: Minimally Awesome Product. But how can you possibly know which feature(s) is most important in order to convey that value and awesomeness if you haven’t actually tested anything? And how will you determine what to measure if you rush out an MVP of dubious value or functionality? After all, if you don’t build the right product, you can’t measure the right things and you won’t end up learning anything.

Besides the fact that you’ve potentially wasted a lot of time and money on a dud MVP, you’re now looking at even more time and money wasted because it’s much harder to tweak and change a product once the backend functionality has been added. So wouldn’t it be better to reduce all that risk before you build?

Well, you can reduce your risk -- in a timely, cost effective way. And by now, maybe you’re starting to see why we maintain that there’s a very important step you should take before you rush out that MVP.

We call it the Reverse Loop. Before you Build, Measure and Learn, you should first:

• (Set yourself up to) Learn
• (Decide what to) Measure,
• Build (an experiment)

Think of the reverse loop as a crucial pre-step. At such an early stage in the life of your product, you owe it to yourself to learn as much as you can and reduce as much risk as possible before you commit to your MVP idea. By reversing the standard build/measure/learn loop, you’ll be able to gather important data that you can put to good use when it’s actually the right time to build your (tested) MVP.

Here’s how the reverse loop breaks down in practice:

(Set Yourself Up To) Learn:

Begin by setting yourself up to learn as much as you can by making a hypothesis -- or, if you like, placing an educated bet -- on one key part of your idea. What’s the most important or riskiest assumption you’re making? Ask yourself: “What do I need to know at this stage?” For example “I think the advanced technique recipe tutorials in my cooking app will help people successfully complete the recipes.”

(Decide What to) Measure:

Now that you have a hypothesis, you can decide what you need to measure in order to prove -- or disprove -- your assumption. Ask yourself: “What do I need to know to validate (or invalidate) my assumptions?” For example: “If someone is able to successfully complete an advanced recipe with the help of a tutorial, then my hypothesis is valid.”

Build (an experiment):

Experiment by building a lifelike prototype. Ask yourself: “What’s the cheapest and fastest thing I can build to test if my hypothesis is valid?” Did your potential user understand how to click on the tutorial? Did the tutorial confuse them? Were they able to complete the recipe? If not, it’s a good thing you didn’t spend the time and money on the current proposed functionality for your MVP. Or maybe a potential user found the tutorial to be valuable, proving your assumption and indicating that feature provides real value.

Once you’ve built your MVP, you’ll then continue this pattern: Minimizing risk with a reverse cycle, followed by a build cycle -- until your product reaches its full potential and delivers the maximum value to your users.

Let’s look at another example of why this reverse cycle is so important. Imagine you have figured out how to build an actual hoverboard, just like the one Marty McFly had in Back the the Future. Only your hoverboard is going to be even better: It looks like a spaceship, it can go incredibly fast, navigate up mountains, hover as high as tall buildings, stream music, guide you with GPS, and has room for two people on it at once. Wow! You can’t wait to rush this out because you know people are going to love it.

But what if you skip right to the build/measure/learn loop and spend a ton of time and money on the MVP ... only to find no one cares about or understands the value of your product? Or maybe you rush it out so fast the tech is off-puttingly janky. Or you’ve misunderstood where the value would lie for your users. Oops.

But ... where did you go wrong? You thought everyone wanted a hoverboard! Well, maybe they do … but maybe that’s not what you actually gave them. Maybe all those extras you piled on obscured the core value of your product. Maybe nobody cares about GPS in a hoverboard. Or maybe it looked incredible but the actual hover capability was so shaky that it set up too many impediments to success and you scared people away from even standing on it. Where’s the value in that?

But if you’d begun reducing risk and by reversing the loop -- learning through a hypothesis, setting your success measurement, and then performing experiments -- your process would have looked very different -- and probably been more successful.