Five questions to ask before building anything
The greatest risk in any project isn’t going over budget, delivering late, or changing the scope. The greatest risk in any project is building something people won’t use.
This isn’t just a high-magnitude risk, it’s also highly probable. Failure to deliver value to users happens more often than many people realize. Unlike blowing a budget or timeline, weak adoption often hides itself. The data is usually there for anyone who wants to check, but most people are already trying to push the next idea through, and those who do pay attention to the data generally aren’t motivated to question the success of their own work.
When someone does take a more rigorous look at value being delivered they usually find that “nearly everything fails.” In one internal review of test results, Microsoft engineers found that only about ⅓ of feature ideas had statistically significant positive results when tested with users. Another ⅓ of the ideas had neutral results, while ⅓ of the assumed-to-be-“good” ideas actually produced negative results. Studies of software projects show varied but similarly discouraging results — especially as they have looked more closely at value in recent years — with large, traditional projects in particular hovering around single-digit success rates.
Even where Agile methodologies are used to mitigate waste, preliminary work leading up to new products and features generally heaps assumptions on top of guesses. Too little time is spent identifying — not to mention testing — the guesses on which estimates and requirements are based. Identifying and testing these assumptions doesn’t need to take a lot of time. More often than not, a bit of research saves more time than it costs.
To get started, here are four questions to ask:
1— Who will use this?
2— When will they use it (or what will cause them to want or need it)?
3— What value or benefit will they get as a result of using this?
4— Is this really the most efficient and effective way to deliver that value?
The fifth question is the most important — though it often requires asking a few different ways before getting a good answer.
5— How do we know these answers? How are we testing our assumptions? What results will tell us we’re right or wrong?
Questioning a few key assumptions doesn’t need to turn into analysis paralysis or months of rigorous research. Spending a few hours reframing assumptions as testable hypotheses might be all you need to turn three months of discussion into a week of user research to arrive at the same agreement on priorities. You might avoid multiple development sprints by doing one design sprint that produces the same lessons and decisions.
Avoiding tough questions only delays inevitable answers. Skipping research doesn’t actually reduce research costs, it turns the whole project into a research cost. When approached openly, early questions and answers lead to more successful products.