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 hundred percent confident or even like really confident that decisions you’re making are really good, you’re doing a great job?

Well, if you are you can leave this article. This isn’t 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 and not enough practitioners, it’s rotting this industry from the inside out.

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

It’s a type of cognitive bias when we create false dichotomies of choices and then think we have answered a question when we have really just choose between a limited set of options.

In reality, there are hundreds of different ways that you can go but we become blinded by our myopic view of an answer.  You create a false choice of what is there versus what you want to see happen.

We get stuck on 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 made 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 testing them!

Rigorously!

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

Why is it better?

You identify assumptions before you base your whole product strategy on them. You find out that 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 true generally with absolutely no evidence, it’s something we take for granted. There are things in your product development process that are not ok to make assumptions about without trying to invalidate them.

There are three basic types of assumptions that we see people make 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 this 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 be to implement that? What could possibly go wrong? etc. These are all incredibly dangerous.

Figure Out Earlier 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. So as the essence of MVP approach to startups is to save as much time as possible – you should test the riskiest one first. If they are 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, it’s ironically quite hard to put into practice.

Even though at the earliest stages of a product, you can start by tackling some universal risks that apply to almost every product. Such as making sure your customer/problem fit is real. Making sure these problems represent a monetizable pain (revenue stream) and 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! Be careful who you are listening to! Use them effectively! However, you can also get conflicting advice from them so always own your business model yourself and test your assumptions.

Don’t Rely on Opinions, but find Facts and Learn from them!

Diana Kander created a very simple method to try to 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 continued to let people know about the page, people continued coming and now, a small number were even 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 them via his personal email. All the work was being done manually with the help of third-party resources.

Case Study – Dropbox

So, one question what is the problem risk for a company like Dropbox, not right now think back to the dark ages before Dropbox existed. What was the problem risk? The problem was that they had to make sure that there are a large number of people who had the very specific problem and the very specific problem was that they have multiple devices where they wanted to access to same files okay that’s the problem they solve. Think about time and place where that wouldn’t be true

To answer the question of 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. So they created a 3-minute video for DropBox in order to walk people through the product. That video 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.

It is often that you cannot test all your assumptions with a single MVP. Do not build a complex system to test them both. Build two separate MVPs.

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 you are gonna go true and you’re gonna categorize your assumptions. Determine if each of those assumptions is a Problem, Solution or Implementation assumption. (P, S, I)

Sometimes you’re gonna have trouble figuring out which of them it is, but it’s generally pretty obvious. If you are having trouble it may be that is actually about both. So you really wanna separate it out. 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 a solution. And if you’re talking about action what do I have to do, you know do I have to solve a problem, that’s general implementation. So write those down.

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

Will Kill pail are 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?

Ok, you already have written your assumptions, but even the number you’ve written, you probably can’t validate all of them or even try to invalidate all of them, it would take forever. So we can assume a few things like people use the internet, except, what 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 something can be a risky assumption for Your product and it can 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 we’re talking about how bad it is going to be when it does.

BUILDING is NEVER your Riskiest Assumption!

The one thing you wanna do, the one thing it’s super fun, building something, writing code that’s the best part where you see your dream comes to life… that’s 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

One exception to this rule, If your name is Elon Musk, (which isn’t if you are reading this). So, if you build rocket ships or magical electrical cars this advice does not reply to you.

The riskiest assumption for You for 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 really kind of a smaller thing.

But even if you are Elon, and again you are Not, even then your riskiest assumption is going to change over your products life spam. For example, once you actually can figure out that you can build the magical instructable car, your riskiest assumption may be whether you can sell that car for a hundred thousand bucks. Again I want you to think back to Tesla, you know when electric cars were most wanted by hippies who frankly hadn’t a hundred gram to spend on something that looks like …

At some point whether or not you can sell the thing is a pretty big part of the risk. Then when you actually figure out that you can sell it, suddenly your riskiest assumption is “Oh my god can I make enough of this, can I make them fast enough, can I build them and 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 and I don’t know what it is for you. That is for you to figure out. And that is for you to figure out constantly because it can change day by day!

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 were right?

Here is a nice template that is stolen 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 design the way to 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 over, you can be wrong and you have to believe, you have to design your test that you believe that that is true if those are the results.

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 THIS HYPOTHESIS.

What they can do, is they can 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 and that you will believe and that you’ll think truly lowers the risk that your riskiest assumption is just a delusion.

How do you pick those numbers when it comes to quantitative when you are at the beginning where are those thousand people come from?

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

As your company gets bigger and as you do this more and more often you just be able to predict better what you see. One of the things that you have to think about is not how many people I would sign up to my service but what percentage of the people coming and signing up would I need in order to make this a Viable business? If I can sort of estimate (this is where you get to the accounting stuff) that it’s probably gonna cost me 10 bucks to find a new person to bring in I have to make some educated guesses about what lifetime values of that person and I have to figure out ok what percentage of people are coming in so I actually need to convert in order to eventually make a profit and that maths gets tough.

And that’s why you should read the book Lean Analytics.

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 derisk if you’re going to make it. You ‘re going to find out how likely it is to be true. And if you ‘re like now X percent more sure that this is true – suddenly that’s not your riskiest assumption anymore. So something else than becomes your riskiest assumption and then you do that exercise on the next thing. You can figure out that something is still somehow risky. Everything is risky! Right? Life is nothing guaranteed!!! You do this exercise with whatever the next riskiest thing is until you kinda feel it comfortable and also while you’re building things and shipping them and getting feedback from people!

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

Apparently, this is a huge problem, because I guess that most of the world doesn’t know about this stuff yet. But again the answer is that Most rational people will respond to demand! Will respond to proof! So if you can run some of this validation or invalidation test, if you want and you can start to show yeah this thing that you think it’s true, I got evidence that it’s not true suddenly it becomes less about well I think or you think which just turns into whoever gets paid is making the decision!

Suddenly it moves into – 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 makes 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!

What is your Riskiest Assumption?

Category: DefineTakeaways
0

Join the discussion

Your email address will not be published. Required fields are marked *