Dealing with Risky and Safe Assumptions

By Demetrius Madrigal and Bryan McClain

Published: April 5, 2010

“Assumptions are important and useful. However, if not managed properly, they can definitely lead a project down the wrong path.”

One of the most important aspects of product development is the process of predicting the behavior of a product’s intended users. I’ve participated in ideation sessions with companies where designers, user researchers, and engineers were making major assumptions about what users would and wouldn’t be willing to do with their product, without performing any research. Of course, assumptions are important and useful. However, if not managed properly, they can definitely lead a project down the wrong path.

There are many examples of products that have challenged established industry assumptions—finally, overcoming them through their own success. Assumptions like these: People wouldn’t want to own a personal computer. People wouldn’t pay more for a high-capacity electronic music player. People wouldn’t feel comfortable purchasing electronic media without getting a physical product. One by one, these assumptions have fallen by the wayside as innovators have moved forward and created products that redefined their markets.

When dealing with assumptions, the most important thing is to recognize that you’re making them and need to understand their potential consequences. Once you recognize you’re making an assumption, it’s important to determine whether it’s a safe assumption or a risky one. Then you can evaluate each assumption and determine its viability.

Risky Assumptions

“Risky assumptions are risky mainly because they can result in a product’s failure to perform in the marketplace.”

Risky assumptions are risky mainly because they can result in a product’s failure to perform in the marketplace. Risky assumptions often result from a company’s failure to recognize changes in a market. Sometimes, risky assumptions result from a company’s attempts to be innovative and different. But they always expose a company to significant risk. While a large corporation can usually absorb a product failure, smaller companies and startups are rarely able to do so. Even though a large corporation might be financially able to survive a product failure, the corporation still might suffer damage to its brand perception.

Risky assumptions often take such forms as these: Customers will be willing to pay for this. Or, everyone will perceive this product the way I do. It’s easy to see how such assumptions—lacking verification—could lead to catastrophic failure. Obviously, if these assumptions were wrong, they could result in lost sales.

If customers aren’t willing to pay for something, that doesn’t mean a product cannot have a future, but it could greatly affect a company’s strategy for bringing it to market. Today’s news media provide a perfect example: Newspaper publishers are struggling to deal with a transformed landscape, in which many of their customers are no longer willing to pay for their content. Many other publishers distribute free news content broadly—across the Internet, television, and even print media. One publisher’s content is rarely dramatically different from another’s, so the resulting loss of paid subscriptions and readership has also meant a dramatic drop in display advertising revenues. Plus, free classified advertising on the Web has taken away newspapers’ primary source of revenue. Together, these trends have placed newspapers in a difficult position, and their survival is by no means assured.

As a consequence, several promising strategies have emerged, including free, advertising-supported news sites and sites that provide some free content, while charging for more exclusive content. The newspaper industry has suffered greatly because of publishers’ out-of-date assumptions, but these publishers are working hard to develop new strategies to overcome them.

Safe Assumptions

“Though safe assumptions keep companies safe, they also tend to stifle innovation.”

Though safe assumptions keep companies safe, they also tend to stifle innovation. Safe assumptions usually arise in larger, more established corporations, in response to innovative ideas or concepts for products and services. When large corporations encounter opportunities for innovation, they sometimes choose not to act upon them. Startups tend to be less risk averse and move forward with innovations. Safe assumptions rarely result in wasted money or end up killing a business, but they can definitely result in missed opportunities. Sometimes competitors seize these missed opportunities and capture market share from corporations that play it safe. Safe assumptions tend to be statements like: People wouldn’t want to use that.

One of our favorite examples of safe assumptions and missed opportunities is the Xerox Alto personal computer, which Xerox developed at PARC in 1973. The Alto was the first computer to use a graphic user interface (GUI), a desktop metaphor, and a mouse as its input device. Though Xerox developed the Alto several years before the Apple II—the first commercially successful personal computer—came out in 1977, they never brought the Alto to market—despite its having features Apple was unable to replicate until it developed the Lisa in 1983.

Xerox finally acted on its innovations, creating the Xerox Star and bringing it to market in 1981. But, unlike the Apple II, the Xerox Star focused on office use and was part of a larger office system. Xerox required its customers to build an early version of an office network, purchasing a minimum of two Stars—at $16,000 apiece—along with other equipment. The Apple II flourished, as did its successor the Macintosh, while the Star was considered a failure, and Xerox soon exited the personal computer market. Rather than capitalize on the Alto’s innovations and develop a product for the consumer market, Xerox chose to play it safe and focus on the business market. As a result, they missed out on an opportunity that could have resulted in enormous growth for Xerox.

Testing and Challenging Assumptions

When testing risky assumptions, the goal is to verify whether they are correct.”

It’s important to test risky assumptions and challenge safe assumptions through user research. The great thing about testing and challenging assumptions is that both are win-win endeavors.

When testing risky assumptions, the goal is to verify whether they are correct. If an assumption passes its test successfully, a product has a much greater chance of succeeding in the market. If an assumption fails its test, there are two possible outcomes: The company can either adjust its market strategy for its product or cease development of the product. In either case, the company has an opportunity to save a substantial amount of money, in comparison to its following its original failed assumptions and bringing the product to market as originally planned.

When challenging safe assumptions, the goal is to defeat those assumptions and prove them to be incorrect. If a challenge is successful in defeating an assumption, a company has an opportunity to bring an innovative product to market. However, if a challenge is unsuccessful, a company can forego developing a product from its initial concept.

When challenging safe assumptions, the goal is to defeat those assumptions and prove them to be incorrect.

By interacting with a product’s intended users, a development team can gain a greater understanding of their needs, guiding the team’s future development of new concepts. Companies that have successfully challenged safe assumptions have disrupted markets and built large, successful corporations around their innovations. Apple was able to do so with personal computing by introducing the Apple II, then the Macintosh. Nintendo was able to do so with video gaming. Sony’s PlayStation was later able to replicate Nintendo’s success. Ironically, the PlayStation began as a joint venture between Nintendo and Sony, but Nintendo pulled out of the venture, because of their own safe assumptions. Toyota was able to do so with small, fuel-efficient cars and built enough of a following to become the largest automotive manufacturer in the world.

So, when you encounter assumptions in doing your own user research work, recognize whether they are safe or risky assumptions. Then decide whether you’d like to mitigate risk through testing assumptions or challenge the status quo and pursue innovation. Either path would be preferable to potentially wasting large amounts of time, effort, and money or missing out on a golden opportunity.

2 Comments

Risky/Safe is a nice simple approach to categorizing assumptions. It never ceases to amaze me how little attention people pay to assumptions generally.

Having recently been involved in a project where I was the only person registering and checking all the assumptions made by the project team—at least the ones I was aware of—including all technical and business assumptions, I know how important it is to ensure that an application isn’t developed on a foundation of toothpicks. Although it might be okay during the ideation and prototyping stages, while you’re working with toothpicks, once you move to real deliverables, you need to revisit the entire stack down to the foundations.

Another approach, if you need something a bit more rigorous, is putting assumptions into a risk-management framework and plotting the risk of failed assumptions on a consequence-likelihood matrix. What is the impact if we’re wrong about this assumption? How likely is it we’re wrong? Then you can serialize and prioritize the matrix into a prioritized list of assumptions to test from very high-risk assumptions down to low-risk assumptions.

Thanks, Nathanael. I’ve also been surprised by how often people treat their assumptions as fact and don’t realize they could be way off. As researchers, we’re a little bit more sensitive to what beliefs need to be verified.

In the end, we think that if we can help people to realize when they are making assumptions, as well as the risks of those assumptions, it would be helpful for everyone.

Join the Discussion

Asterisks (*) indicate required information.