3 Different Methods for Identifying Assumptions

Think about the last feature you launched that didn't work as well as you were expecting it to. Maybe you assumed users would take the time to fill out detailed profiles, or that they'd regularly check their notification settings, or that they'd understand your clever new interaction pattern.

Unfortunately they didn’t.

Every solution we design is built on layers of assumptions about:

• What users want to achieve

• How they'll interact with our solution

• What actions they'll take

• When they'll take those actions

• What information they'll have available

• How they'll respond to different situations

The more of these assumptions we can identify upfront, the better we can validate them before investing significant resources in building the wrong solution. But when you try to identify all of the assumptions underpinning an idea it can be challenging. This is where it is useful to use some techniques to to have a structured way to think about the problem.

Technique 1: Process Mapping with Swimlanes

One of the most effective ways to surface assumptions is to map out your entire solution as a process flow with swimlanes for different actors (users, system, third parties, etc.).

Start by drawing out each step in the process, being as detailed as possible. Then, for each action a user needs to take, ask yourself:

• Will users actually take this action?

• Do they have the necessary information to take this action?

• What might prevent them from taking this action?

• What might cause them to take a different action?

The power of swimlanes is that they force you to be explicit about who needs to do what and when. Often, just the act of mapping out these interactions will surface assumptions you hadn't considered. Pay special attention to handoffs between swimlanes – these transition points are often rich with hidden assumptions.

Technique 2: The Four Product Risks Framework (plus a bonus extra risk)

Another powerful approach is to examine your solution through the lens of five fundamental product risks:

1. Desirability: Will users want this?

• Are we solving a real problem?

• Is this problem important enough to drive action?

• Will users really pay for this?

2. Usability: Can users use this?

• Can users figure out how to use it?

• Can users easily navigate the subscription flow?

3. Viability: Does this make sense for the business?

• Does this solution align with our business goals?

• Does the business model support long-term profitability?

4. Feasibility: Can we build and support this?

• Do we have the necessary technical capabilities?

• Is the cost to build this prohibitive?

• Are we making assumptions about data availability?

5. Bonus: Third-party Risk: Will others do their part?

• What are we assuming about partner integrations?

• Are we dependent on third-party actions?

• What happens if a third party fails to deliver?

This works really well when used together with the process flow mapping. For each step in your flow you can work through each category to identify assumptions that might otherwise slip through the cracks.

Technique 3: The Pre-mortem Exercise

A pre-mortem is a reverse-thinking exercise where the team imagines the product has failed and works backward to determine why. Participants brainstorm all possible reasons for the failure, including overlooked assumptions, misaligned incentives, or unexpected user behaviors. Here's how it works:

1. Fast forward 6 months and imagine your solution has failed spectacularly

2. Have each team member write down all the possible reasons for failure

3. Pay special attention to:

   • Ways users might game or misuse the system

   • Unexpected user behaviors

   • Technical failures

   • Business model flaws

   • External factors

The beauty of the pre-mortem is that it makes it safe to voice concerns and surface potential problems. By framing the discussion around a hypothetical failure, you remove the psychological barriers that might prevent team members from pointing out assumptions and risks in a traditional planning session.

When conducting a pre-mortem, be sure to consider how bad actors might exploit your system. The ingenuity of some people to work around any cracks in your system is truly impressive.

Putting It All Together

The most effective approach is to use all three techniques in combination. Start with process mapping to understand the flow, use the five risks framework to systematically identify assumptions, and finish with a pre-mortem to catch anything you might have missed.

Remember, the goal isn't to identify all assumptions – that's impossible. The goal is to identify the most critical assumptions that could make or break your solution, so you can validate them before committing significant resources to development.

By making assumption identification a regular part of your product development process, you'll be better equipped to catch potential issues early, when they're still cheap to fix. Your users (and your future self) will thank you for it.