When and how to move from an assumption to a hypothesis

Working at pace often means you need to work on assumptions.

The current team I’m leading. I’ve had to make some assumptions clear that we would have to work to. Some about our users. Most though, about the organisation. We had to believe certain things will be true to unblock our focus.

As you define what feature, service or product you need to build. A team will have assumptions about how their users work. Or what their stakeholders want.

The power of an assumption is it gets you somewhere fast. You act on belief, on faith that something is true. The problem is, they’re not based on fact. And can be very optimistic.

For the business assumptions I asked my team to work under, I set out to make them true. Gaining support or buy in for certain approaches. Or confirming shared priorities and expectations. Where things needed adjusting or there was nuance, we worked that though.

For the assumptions about our users and how a new thing would work. It’s a little trickier.

You can’t normally hold a workshop or two or have a side chat and clear the approach. There isn’t a steering group or senior leader to clear things with. What 1 user tells you might be contradicted by the next 4.

Rather than working on assumptions, which can be useful to get some momentum, it’s worth turning things into hypotheses.

An assumption is a guess or thing that you work on with the belief that it’s true. A (good) hypothesis doesn’t come with any belief. It’s an idea or statement you use as a starting point to prove or disprove a position.

This way you’re framing things to remove the risk of working on a belief that can be false. And the work that you do gets more agile and clear about what decision you’re trying to make.

I remember working in a team who often assumed a certain feature of a rival company worked. Rather than set out to prove or disprove the idea. They just acted as it was true and designed and built accordingly. What the team found out often was all the reasons things didn’t work, far too late. And often a few versions behind the rival company.

The company was always playing catch up working on the assumption that the bigger rival knew what they were doing. And what was public was the most optimal version of an idea. But if you’ve ever built anything you know the path to live is full of compromise and promises to fix things later.

And if it sounds dumb to work on the assumption other companies know what they’re doing. Well, that’s most organisations.

Part of this is again, that assumptions are so powerful. A bit of faith and it unlocks the ability to act. But when it comes to your users or customers. It gets risky.

When an assumption turns out to be wrong. You’ve built and acted on something that’s false and potentially going to be bad. If a hypothesis is wrong, you’ve got an opportunity to act differently.

To turn something into a hypothesis is pretty easy. It’s basically a statement that can be proven true or false. I like to use certain formats but there are plenty of options. The key for me is to state how you expect to judge a statement is right or wrong.

You can do this on your own or as a team. And many formats exist to map your assumptions as a team

The beauty of assumptions are that they can come from lots of different people. Which means they can be useful to start with to help define an early visions.

You could also use something like ChatGPT to help you if you’re struggling. Do that by stating your assumptions and ask it to turn it into a hypothesis. Give it a format. And ensuring to tweak the output to ensure it’s not a sack of rubbish.

Taking my mind back to the team that copied their competitors, if we had just stated some of the assumptions as hypotheses. We’d have realised we didn’t rate the idea.

Should everything be a hypothesis? I don’t think so. Time is short. You need to spend your time experimenting and learning on things that make an impact.

If:

• something is outside your direct control
• relies on users or customers (including internal users)
• there is a real risk of something goes wrong or doesn’t work

and the cost of finding out by building it is higher than faking it, then treat it like a hypothesis. Else, take a view on whether an assumption is safe to make and proceed from there.

To state it another way, what’s the cost if what we believe isn’t true? Start there.

If it’s an internal set of teams you need to work with. It’s an assumption and whether you act on it depends on when you’re able to make a decision with others fast enough (and the risk of doing so).

If it’s a user, customer or wider community facing thing, work out the risk. And if it’s at all worrying or impactful, treat it like a hypothesis.

By translating your assumptions into hypothesis you reduce risk. And build a pattern of learning into your process. And being clear when you create hypotheses or act on assumptions you will balance risk and speed.