Avoid The Software Sinkhole

This is a complete guide to avoiding the software sinkhole by building a business hypothesis.

In this in-depth guide you’ll learn:

• What is a software sinkhole
• How to avoid the software sinkhole
• Why you need a business hypothesis
• How to build a business hypothesis
• Plus more

If you’re ready to answer how to increase your odds of success, this guide is for you.

Let’s dive right in.

Avoiding the Software Sinkhole

The Software Sinkhole is a term we use to describe a series of circumstances in which first-time founders often find themselves.

It’s a sad state of affairs and, unfortunately, it’s also very common. In most cases, we find that founders end up in the Software Sinkhole for three main reasons: 

1. They’ve spent most, if not all, of their budget building their product but it’s either not finished or doesn’t work. Or both.
   
2. They’ve finished building their product and have launched it to the world, but no one seems to want it no matter how much they spend on advertising.
   
3. They’ve built the Frankenstein of digital products by including every “good” idea they and their friends could think of and now nothing about the product makes any sense. 

How to Avoid the Software Sinkhole

1. Create a Business Hypothesis: Businesses and products are built on assumptions that need to be tested and confirmed!
   
2. Customer Discovery: You’ve got to know who you’re building your product to serve.
   
3. Prototype Your Product: Test for demand and value by creating “fake” versions of your product that you can test with users.

Best Practices

There’s a distinctly different set of tactics and methods used to develop digital products. There’s a very good reason for this. 

You see, with digital products like mobile apps, websites, or web applications, there are almost always more unknowns than knowns. Unlike, say, a sneaker which we have a very well-defined process and archetype for building, the software just doesn’t come with a manual. 

In a sense, the promise of software is that there aren’t many limits on what you can build. But that’s also the curse of software for founders. If there aren’t any guides to follow, we often end up building the wrong thing, things that don’t work, things that are too big and clunky, or things that no one cares about.

In the next two articles, we’ll cover two of the most important, early steps founders can take to de-risk their projects and help increase the chances that they’ll build the right thing for the right person. 

But for now, we want to leave you with this: 

Building software is hard. It’s complex and complicated and you’re usually starting with far more unknowns than knowns. While this can be really intimidating, you should know that there’s hope to be had and that, yes, you should build that mobile app you’ve been dreaming of. 

Thankfully, despite the relatively young age of software development as an industry, plenty of people have gone before us and charted out best practices that we can follow to help us find success with our digital products. 

Stay with us as we unpack a couple of key steps you can take right now to start your project off in the right direction. 

Creating a Business Hypothesis

One of the first things founders should do when they first have an idea they think may turn into a product creates a business hypothesis. 

This may sound a bit odd at first; after all, the last time you heard the word “hypothesis” was probably in high school. But a hypothesis is an important and usually overlooked tool for a would-be founder. 

The easiest way to understand why we need a hypothesis is to think about that early-stage concepts are made of Assumptions. 

Before we have a product in the market, all we can do is assume a problem exists and assume that we can build a solution that we then assume someone will care enough about to pay for. 

And you know what they say about assuming.

To determine whether our assumptions are true or false, we need to test them. And to run a test, you have to have something to test against. 

That thing we test against is a hypothesis, a testable statement designed to confirm or deny the assumptions we make about our products.

Building a Hypothesis

Hypotheses come in many shapes and sizes, but for our purposes, we’re going to follow these steps: 

• Write down all of the assumptions you can think of related to your concept.
  
• Identify what you believe to be the riskiest of these assumptions.
  
• In other words, which assumptions, if proven incorrect, could invalidate the concept entirely?
  
• Create a statement that you can use to test each of these assumptions.
  

The simplest format for a hypothesis you can test is an “if/then” statement or a “because/then” statement. 

“If I shorten the account creation process, then more people will create accounts on my website.”

“Because my customer hates going to the bank, they’ll find value in a mobile banking app.”

These are super simple examples, but you should start to see where this is going by now. Perhaps a better example of a strong hypothesis we used recently with a client would be: 

“If we make in-home catering easier to schedule and more affordable, more middle-income families will use these services once per quarter.”

In real life, this hypothesis allowed us to test the central risky assumption about a client’s concept: would middle-income users engage an in-home caterer on a semi-regular basis if we made it easier to schedule and afford? 

If we couldn’t prove this true, we knew we’d have to rethink the entire business concept. 

One more thing…that whole “rethink the entire business concept” thing. That’s not so bad! In fact, it’s a pretty good outcome. Better to change course than to continue in spite of the evidence. This is called a “pivot,” and is so commonplace in software development, it’s often held up as a sign you’re doing things right, rather than a point of failure.  

Building digital products is expensive no matter how you slice them. It’s better to know early that you’re on the wrong path so that you can do the work to get on the right path quickly and cheaply before you have to rework an entire product.. 

Have you heard about Foundations by AppThink?

Interested in joining a group of entrepreneurs working toward their MVP? Join our flagship cohort-based course, Foundations. 

Foundations is perfect for an entrepreneur with an idea but who is unsure of the steps to take to attack the problem and build a business. Do you have questions before you join? Send us a message, we’re happy to help.