Written by: MVP Workshop

What is your Riskiest Assumption?


Do you find yourself thinking about decisions you’ve made? Were they right? What exactly defines them as such? What was your riskiest assumption?

Are you in charge of making Product decisions at work? Are you one hundred percent confident that decisions you’re making are really good? That you’re doing a great job?

Well, if you are, you can stop reading. This article is not for you.

Challenging Your Current Mindset

How to figure out what hazardous ideas you have in your head about your product?

There are many theorists but not enough practitioners and it’s rotting this industry from the inside out.

First, let’s take a brief review of something called Congruence bias.

It’s a type of cognitive bias in which we create false dichotomies of choices and then think we have answered a question. In reality, we’ve made a choice between a limited set of options.

Even though there are hundreds of different ways that you can go with we become blinded by our myopic view of an answer. We create a false choice of what is there versus what we want to see happen.

We get stuck with the things we want to see win and, as such, we get trapped in this bias on an almost hourly basis.

Product Management Is All About

Helping your team to ship the right product for your users! How to be sure that you’ve done it?

Well, It’s a little bit hard. Every step of the way, you should be challenging your current mindset, challenging your assumptions, recognizing what your assumptions are and test them!

Rigorously!

Learning whether or not you are wrong As Early As Possible!

Why is it better?

You’ll identify assumptions before you base your whole product strategy on them. You’ll find out if you are wrong before you spend a lot of resources. (Remember, Time & Money are equally important resources for the product.)

Where Your Most Risky Assumption Lies – That’s The Place Where Your MVP’s Hiding!

What is an Assumption, Anyway?

An assumption is something we believe is generally true with absolutely no evidence. It’s something we take for granted. Certain things in your product development process are not ok to be a part of your assumptions without trying to invalidate them first.

We see people make three basic types of assumptions all the time:

  1. Problem (Is there a problem?)
  2. Solution (Is this the right way to solve it?)
  3. Implementation (Can you build it and sell it before running out of money?)

Don’t be Afraid to Take a Step Back to Take 2 Steps Forward

Unsuccessful companies make key assumptions about all of these things. They just say: Oh, of course, there’s a problem for that! I have that problem! Everybody has that problem! I have the right solution! What other solution could there possibly be?! How hard could it be to implement that? What could possibly go wrong? etc. These are all incredibly dangerous.

Figure Out Early That People Don’t Need Your Solution for That Particular Problem!

Every innovation is based on a set of assumptions. Many of them will be right and many of them will be wrong.

Obviously, some of these assumptions are more likely to be wrong and break your business model. Since the essence of an MVP approach to startups is to save as much time as possible, you should test the riskiest ones first. If they prove to be wrong you still have time to go back to the drawing board and pivot or move to another project. While tackling what’s riskiest is a simple enough concept to grasp, ironically it is quite hard to put into practice.

Even at the earliest stages of a product you can start by tackling some universal risks that apply to almost every product. Like making sure your customer/problem fit is real. Making sure these problems represent a monetizable pain (revenue stream). Making sure that you have a path or can build a path to customers (channels).

Identifying the right riskiest assumption is the most important first step.

One of the best steps to get your first assumptions right is to talk to domain experts. Have good advisors! Use them effectively. However, be careful who you are listening to! You can get conflicting advice from them as well so be sure to own your business model yourself and test your assumptions.

Don’t Rely on Opinions. Find Facts and Learn From Them!

Diana Kander has created a very simple method to try and measure the risk of your assumptions. After you go through each of your assumptions and assign values, you can prioritize them based on the total risk level number. Always test and validate the riskiest ones first.

Case Study – Zappos

Instead of building a complex and expensive eCommerce platform, Tony Hsieh wanted to test if people would buy shoes online. He went out, took photos in a local shoe store, and posted them online. Once the first sales came, in he bought the shoes in the same shop to ship them to his customers.

Case Study – Buffer

Joel Gascoigne created a simple landing page that described what Buffer “did”. If people were interested, they could click the Plans & Pricing button and be taken to a page that said “Hello! You caught us before we’re ready leave your email address & we’ll let you know when we’re ready”. He carried on letting people know about the product updates and after a while small number of people started clicking on paid plans.

Case Study – Groupon

Andrew Mason founded Groupon by setting up a WordPress site where he posted a deal for a local pizza shop, each day. He generated PDFs manually as orders were received and emailed via his personal email. All the work was being done manually with the help of third-party resources.

Case Study – Dropbox

What was the problem risk for Dropbox? The problem was that they had to make sure there is a large number of people who had a very specific problem: multiple devices with which they wanted to access the same files.

To answer the question whether customers would want to use and pay for their file sync solution, Houston and his team had to “get out of the building” and put their proposed user experience in front of real users for feedback. They created a 3-minute video for DropBox in order to walk people through the product. The video alone drove hundreds of thousands of people to the website. DropBox beta waiting list went from 5,000 people to 75,000 people literally overnight.

At Startup Lessons Learned, Drew summed up his experience with one single slide that says:

  • Biggest risk: making something no one wants
  • Not launching > painful, but not learning > Fatal
  • Put something in users hands (doesn’t have to be a code) and get real feedback ASAP
  • Know where your target audience hangs out & speak to them in an authentic way

Case Study – AirBnB

There was a design conference coming to town, so Brian Chesky and Joe Gebbia decided to open up their loft as cheap accommodation for attendees who had lucked out on nearby hotels. They took pictures of their apartment, uploaded them on a simple website, and soon they had 3 paying guests: a woman from Boston, a father from Utah, and another man from India.

There is no need to reinvent the wheel. You’ll find plenty of existing resources to keep efforts low.

Often times you won’t be able to test all your assumptions with a single MVP. Build two separate MVPs instead of building  a complex system to test them both.

Write down as many assumptions about your product as you can. Here’s a template:

For Product to succeed it is necessary that ____________. (people have multiple devices where they can share their files.

Ruthlessly prioritize – Build momentum Fast!

When you are done writing down assumption you’ll have to go through them categorize them. You’ll have to determine which of those assumptions is a Problem, Solution or Implementation assumption. (P, S, I)

Sometimes you’re gonna have trouble figuring out which one is which, but, generally, it’s pretty obvious. If you are having trouble it very well may be that is actually about both. So, you really wanna separate it out. If it is about the user and the problem you’re solving its a P. If it’s about how you’re solving it, if you’re talking about features, detail of it, that’s gonna be an S. Finally, if you’re talking about the action what do I have to do to solve a problem, that’s an I assumption. Be sure to write those write those down.

Divide them into “Will Kill” pail and Other (Will Not Kill) pail

Will Kill pail holds things that are literally going to kill your product. If this isn’t true your product goes down the drain. (If pets can’t work, jobs for pets are going down to water)

What Makes an Assumption Risky?

If you’ve already written your assumptions the sheer number of them shows you probably won’t be able to validate all of them as it would take forever. While we can assume a few general things, like people use the internet, what happens if you’re making a mobile app that’s gonna be used in National parks? Then you’re gonna have to validate whether or not people will actually have access to the internet.

So what You need to do is to identify the characteristics of something that makes a Risky assumption for You.

Because as I just pointed out while something can be a risky assumption for your product, it can also  be a totally assemble assumption for somebody else. So What’s Yours?

When we say something is risky we are talking about two separate factors. We’re talking about how likely it is to happen and how bad it is going to be when it does.

BUILDING is NEVER your Riskiest Assumption!

Building something ie writing code and seeing your dream coming to life is never the riskiest assumption, whether you can build it or not.

So, if that’s one of your assumptions get rid of it!

Ok, almost Never.

There is one exception to this rule, if your name is Elon Musk. If you build rocket ships or magical electrical cars this advice does not apply to you.

The riskiest assumption for you at the very beginning is whether or not you can actually build a rocket ship. Can you launch something into space before going broke?! Whether or not you can sell it is not that big of a deal at the moment.

But even if you are Elon your riskiest assumption is going to change over your product lifespan. For example, once you figure out that you can build the magical instructable car, your riskiest assumption may be whether you can sell it at a price of a hundred thousand bucks. I want you to think back to Tesla and times when electric cars were most wanted by hippies who frankly have never spent a hundred grand on something that looks like that.

At some point, whether or not you can sell the product, becomes a pretty big part of the risk. When you finally figure out that you can sell it, suddenly your riskiest assumption is “Oh my god can I make enough of them, can I make them fast enough, can I sell them out to people, am I out of money…”.

The point is that sometimes your riskiest assumption is about the Problem you’re solving, sometimes it’s about the Solution and sometimes it’s about the Implementation. It is on you to figure it out constantly because it can change day in day out!

Now, that you’ve identified your riskiest assumption you should turn it out into Hypothesis statement.

A hypothesis statement should contain:

  1. What do you believe?
  2. How will you know if you are right?

Here is a nice template from Janice Fraser.

Problem Hypothesis Example:

We believe people like customer type have a need for (or problem doing) need/action/behavior.

We will know we have validated this when we see quantitative/measurable outcome or qualitative/observable outcome.

Solution Hypothesis Example:

We believe people like customer type will solve their problem by solution behavior.

We will know we have validated this when we see quantitative/measurable outcome or qualitative /observable outcome.

Implementation Hypothesis Example:

We believe our company can provide a solution by implementation method.

We will know we have validated this when we see quantitative/measurable outcome or qualitative /observable outcome.

Now you try It!

Build your Test Hypothesis

The goal is to think of a way that can help you decrease the risk that you’re building on top of abandoned mind shift. You have to be open to the idea that you might be entirely wrong and you might have to start all over. You have to design your test in such a way that you’ll believe that the results are true even if the results shows you you are wrong.

There are various types of tests, but none of the tests are 100% reliable!

NOTHING CAN TELL YOU THAT YOU ARE A HUNDRED PERCENTS RIGHT.

NOTHING CAN TRULY VALIDATE ANY OF THESE HYPOTHESIS.

What they can do is significantly lower the chance that you are wrong and that is incredibly important!

Identify the Best method of validation. Find the method that works best for you, that you will believe in and that you’ll think truly lowers the risk that your riskiest assumption is just a delusion.

How do you pick those numbers when you are at the beginning of your work? Where are those thousands of people come from?

There are two answers to this. There is a great book, The Lean Analytics that you should read. It talks in depth how to pick those numbers. The truth is that often we have to make a guess and we have to draw the line in the sand that says this is what I’m predicting and this is what I think will happen.

As your company gets bigger, and as you do this more and more often, you’ll be able to make better predictions on a count of what you see. One of the things that you have to think about is not how many people you would sign up to your service, rather what percentage of the people coming and signing up would you need in order to make this a viable business? If you can make an estimate (this is where you get to the accounting stuff) that it’s probably gonna cost you 10 bucks to find a new person to bring in, you will also have to make an educated guesses about what lifetime values of that person and you will have to figure out what is the percentage of the people that are coming in you actually need to convert, in order to eventually make a profit.

Maths and Guessing – Science and Art!

Once you validate your riskiest assumption do you do that exercise again every time?

You’re not actually gonna validate if you’re going to make it. You’re going to de-risk if you’re going to make it. You ‘re going to find out how likely it is to be true. If you end up X percent more convinced that this is true – suddenly that’s not your riskiest assumption. Now, something else becomes your riskiest assumption and you repeat the exercise on this next assumption. You can figure out that somehow, something is still risky. Afterall, everything is risky! Right? There is no guarantees in life!!! You repeat this exercise with whichever the next riskiest thing is until you kinda feel comfortable. All the while you’re building and shipping things and getting customer feedback.

How do you convince others in your company that they are relying on unverified assumptions that could very well be wrong?

This is a huge problem, being that most of the world doesn’t know about this stuff yet. The simple answer is that most rational people will respond to demand and proof.That’s why you’ll have to  run some of these validation or invalidation test. Suddenly, it all becomes less about “I think” or “you think” and more about “we have evidence, watch these users, look what they’re doing, look at the metrics”!

If you work at a company where people are not convinced by things like listening to users and looking at what your users actually do in real life you need to quit! And you need to find someplace better to work you can only spend so much of your life convincing other people to that truth is the truth!

People feel empty when they get a result that goes against their biases and beliefs, that goes against conventional wisdom so they inherently starting searching for why. In some organizations, executives don’t care about the results, only the way. Beware anytime you or anyone else ever starts explaining why something happened!

When you already have a product and sort of analytics you have a lot more things you can try something like A/B testing as we wrote about in our previous post. You actually have more way to test more things when you have the real product! The important thing is to knowingly state what your assumptions are getting them written down because everybody is as pedant about what changes as soon as they have data to figure out what your assumption is written them down and figure out the way to invalidate them if possible!

Make an assumption – test that assumption – then make changes!

So with that in mind, ask yourself this:

What assumptions am I making about my business and what information do I need to test those assumptions?

Feel free to comment and share your experience with product decisions you’re making! Thank You!


Guides, articles, and news
Uncategorized

FHE Project comparison

As the adoption of this transformative technology continues to grow, so does the emergence of innovative projects harnessing its capabilities.

Miscellaneous

Deep Dive into Scalability Solutions: A Comparative Analysis

The blockchain ecosystem is a vibrant and ever-evolving landscape, home to numerous platforms each promising unique benefits and innovations. In

Uncategorized

Potential of Homomorphic Encryption: Exploring Use Cases and Challenges in Web3

You have probably heard of homomorphic encryption, a new buzz word in web3 space, but what is it and does

get in touch