What’s Missing From Your Software Development Process?

It’s no secret that building software is difficult. In fact, nine out of ten software start ups fail, and as many as 85% of internal software projects never realize meaningful ROI. So what’s going wrong? Why do smart business people build ineffective software? Often, it is because they fail to consider their customer early and often enough in the software development process.

“Customers don’t care about your solution. They care about their problems,” Dave McClure, 500 Startups

It is imperative to consider your customer’s problem before trying to develop a solution. A CB Insights study of more than 100 startups found that the number one cause of failure (42% of the time) was “no market need”. Making assumptions about a customer’s needs without validation or developing a product with only features in mind can leave you with a piece of software that may function well, but have no customer base. How can you gain an understanding of your customer’s needs without sacrificing timeline or budget? Here’s our recommended approach.

Problem Identification Framework

(adapted from Lean Problem Identification)

Step 1: Form Teams

Form two core teams: a Problem Team and a Solution Team. We recommend that teams be as small as possible (2–3 people is ideal), and contain individuals from a variety of disciplines.

Step 2: Market Development Session

The Problem Team should work to define two key hypotheses: what will be the product’s area of focus, and who the target customer is. To help discover a potential area of focus, consider the following questions:

• What tasks do people want to avoid?
• What work-arounds have people invented?
• What surprising uses have customers invented for existing products?
• Where do you see non-consumption?

Once you have established an area of focus, it is time to consider who your target customer is. In other words, who do you think will be your early evangelists? Consider both their demographics (gender, age, income, location, etc) as well as their psychographic characteristics (circumstances, common behaviors, buying triggers, fears, etc). Try to identify and agree on 5 characteristics of your early evangelist.

Stuck? Try sketching your early evangelist to get started (What do they look like? What are they wearing? What kind of tech do they use? What car do they drive? What do they read?). You will want to keep from getting too specific about your target customer at this point, but it can be helpful to begin to think about their larger circumstances beyond their habits in your area of focus.

Step 3: Problem Identification Interviews

Chances are you’ve heard of the philosophy of “failing fast”. It is vital to test a specific hypothesis with potential customers as early as possible. This will provide invaluable feedback and confirm if you are on the right track. If your assumptions are off, you will want to know immediately, so that you can pivot and try again. Begin by identifying five early evangelists who meet your target customer description, then ask them for five names each of people you don’t know who would also fit as a target customer. Interview and document their responses to the following questions:

• What are your top 3 problems with __(functional area)__?
• Are you solving that problem today?
• If so, how are you solving it?
• How much are you paying to solve it?
• What are the shortfalls of your current solution?

Step 4: Documentation & Solution Development

The Solution Team will now consider the interviews and documentation the Problem Team has compiled. Use this information to weigh potential solutions based on criteria such as:

• Does it solve a big enough problem for the customer?
• Does this command breakeven pricing (or higher)?
• Is this a turn key solution?
• Is there a short sales cycle?
• Does it limit the number of decision makers required to make a buying decision?
• Is there room for growth?

Step 5: Test Your Solution & Iterate

Finally, present your solution to your group of early evangelists and collect any and all feedback. Services such as usertesting.com can be helpful to gain valuable input on an early MVP of your product (even if it is just one feature). Keep in mind you want to test very specific aspects of your product in order to fully understand what about the product is working — and what is not. As stated in The Entrepreneur’s Guide to Customer Development, “It is better to be wrong than vague. If you are wrong, you iterate; if you are vague, you have wasted your time and cannot draw any conclusions.”

How This Affects Budget & Timeline

The Problem Identification framework does require a time investment up front to validate your problem-solution fit. This investment, however, will serve you in the long run, saving you both money and time. The Problem Identification framework affords you the ability to course correct quickly, limiting the amount of time you could be headed down a dead end path that often is both a time and money suck. In the traditional model you do not validate your customer until post-launch, meaning if you’ve missed the mark, you need to start back over and repeat the (often) most expensive and time consuming part of the process: development. By utilizing the Problem Identification framework at the start of an engagement, you ensure you will only head into development once you have a vetted customer problem and solution, eliminating the risk of repeating costly development cycles.

Moral of the Story

Building the wrong product is the most common business error made by software teams. Reduce risk, wasted time, and wasted money by considering your customer upfront — and building the right product the first time.