Avoid These Common Anti-Patterns

As you work to identify the hidden assumptions behind your ideas, be sure to avoid these common anti-patterns:

Not generating enough assumptions. Generating assumptions, like ideating, is intended to be a divergent exercise. The goal is to identify as many “gotchas” as you can to increase the chance that you generate the riskiest ones. However, many teams dramatically underestimate how many assumptions underlie their ideas. When I do these exercises, I often generate 20–30 assumptions for even a simple idea. If that sounds overwhelming, remember, you won’t need to test all of these assumptions. Most of them will be harmless. You’ll use the assumption-mapping exercise to quickly find the riskiest ones. However, if you don’t generate the riskiest assumptions, the mapping exercise won’t help you sort something that you haven’t uncovered. Use the five assumption categories and the exercises in this chapter to help you generate as many assumptions as you can.

Phrasing your assumptions such that you need them to be false. Generating assumptions can be a bit of a devil’s-advocate exercise. You are looking for what might go wrong with your ideas. As a result, you might be tempted to phrase your assumptions negatively. For example, if you need your users to log in to your service, you might phrase your assumption as, “Customers won’t remember their password.” However, this is backwards. You need customers to remember their password for your idea to work. When you are generating assumptions, always phrase your assumptions such that you need them to be true: “Customers will remember their passwords.” For many assumptions, you’ll find that this positive framing will make them easier to test.

Not being specific enough. I see many teams generate assumptions like this: “Customers will have time,” “Customers will know what to do,” and “Our engineers can build something like this.” These assumptions are not specific enough to test. What will customers have time for? What do you need them to know how to do? What do engineers need to build? Be specific. These assumptions are much better: “Customers will take the time to browse all the options on our getting-started page,” “Customers will know how to select the right option based on their situation,” and “Our engineers can identify the right subset of options to show the customer based on the customer’s profile data.”

Favoring one category at the cost of other categories. Most teams have a bias toward one or two categories at the cost of the other categories. Some teams conflate desirability and usability and forget that just because a product is usable doesn’t mean it’s desirable. For products with challenging feasibility issues, it can be hard to remember to first test and see if customers even want the solution. Most teams forget about ethical assumptions altogether. Remember: Use the categories to catch your blind spots.