All Blog Posts

How to Identify and Test Riskiest Assumptions in Custom Software

Software riskiest assumptions

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.

Start with Riskiest Assumptions

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!