Between 70 and 90 percent of all new software products fail (the numbers vary depending on which study you read). 42% of startups that fail don’t reach their goals because of a lack of market fit.
Whether you’re launching a new SaaS startup, building a custom enterprise system for your team to use, or creating a portal for both customers and team members, you need to validate that your idea will do what you think it will do.
As you’re launching a new project, it’s important to identify, test, and validate the riskiest areas. This is known as testing your riskiest assumptions, and it’s the very foundation of building a successful MVP.
Why We Test Riskiest Assumptions First
Any new custom software project comes with a bunch of assumptions. You assume what users want, what they need, what’s highest priority, what they’ll pay for, how they’ll use the system, and so much more.
You also make assumptions about which frameworks, languages, plugins, and integrations will work for various features and functionality.
Out of all your assumptions, there will be a handful that could make or break the project. These are your riskiest assumptions. You want to identify them, test them, and validate that your assumption was right. Or, if your assumption was wrong, you learned
that early and can adjust accordingly.
How to Identify Your Riskiest Assumptions
The first step in testing your riskiest assumptions is identifying them. The goal of this process is to figure out the parts of your project—features, user behaviors, technology—that could derail the whole thing.
Step 1: The Backlog
Even though you don’t need (or want) a full backlog to start your riskiest assumption testing, you’ll need some idea of what you’re looking to build. Otherwise, what would you test?
Start with a high-level backlog or roadmap of your MVP.
Step 2: A List of Assumptions
What are all the things you’re assuming you know about your project that you haven’t validated? These could include:
- Your target market
- Top-priority features
- 3rd party components
- Workflow processes
- User expectations
- And so much more
Identify your assumptions and list them out for the next step.
Step 3: Find the Riskiest Assumptions
For this step you need to identify the riskiest assumptions from your list. You’re looking for a few things that signal “risky.” Assumptions around mission-critical items—again, those parts of your project that can make or
break success—are some of the riskiest. File any of those in the risky category.
You should also look for areas of the system where there’s a lot of uncertainty. That uncertainty can be around product-market fit, functionality, workflows, UI/UX, or any of a dozen other things. The more uncertainty, and the more mission-critical
the functionality, the riskier the assumption.
The comprehensive list you created in step two, regardless of how many made it to the “riskiest” category, will help you throughout the rest of development process.
Testing Your Riskiest Assumptions
Your testing process is going to depend on the type of assumption. If a 3rd party component is a risky assumption, then a prototype of the integration might fulfill testing requirements. If feature workflows are a risky assumption, then user research
and testing may be the route to take for ironing that out.
The test should fit the assumption and either validate or give you direction for a pivot.
Keep in mind that identifying and testing riskiest assumptions can be done at any point in the custom software development process; it’s not limited to the pre-MVP stage. For example, when you’ve already launched and you’re planning
to add new functionality, you can test and validate the riskiest integrations before starting development to make sure things will work as expected.
Start with the Riskiest
Verifying your riskiest assumptions first can save you a lot of frustration and money. There’s real power in validating ideas and features and going into your software project with earned confidence.
We start with the riskiest assumptions because those are the ones that can wreak the most havoc and would require the most re-work (and money) if our assumptions are wrong.
Want to talk more about the riskiest assumptions and why you should always validate them? Reach out!