If you build it, will they come? Part 2

In the first post of this two-part series, I shared the importance of validating your product idea before you write a single line of code and outlined what you need to validate. Now we’ll dive a little deeper and I’ll explain how you can validate market demand, the problem, and your product or proposed solution.

Remember, the eventual outcome of product validation (assuming your idea is validated) is a market-focused user-centric product team that’s creating real value. The goal is to avoid this famous cartoon from becoming your reality:

Software_Treeswing

 

Validating Demand

I typically don’t spend more than a week of effort conducting this phase. When you cast a big net sometimes you catch garbage. As you’ll read later, the most valuable data will be collected straight from your customers.

The goals of validating demand is to get an answer to the questions:

  • What is your total market potential?
  • How much of that market will you be able to capture?
  • Is that enough justification to move forward on development? Will building your product be worth the risk? Is the market big enough for the financials to make sense?

Your goal is to figure out your realistic market size. If not, you risk there not being enough demand for the product because it (a) doesn’t solve a big enough problem for its market or (b) it doesn’t solve the problem in the right way that works well for the users.

You want to ensure the target market is big enough and there are enough people willing to pay for your product. What’s a target market? Is yours big enough? Some people don’t like the term “target market,” but I do. When a market is targeted, it implies that you are focused and you have a deep understanding of your audience.  It’s pointless to start too broad.

For example, it’s too difficult to build a single product that “people who play music” will all want. However, “people that play guitars” is more narrow and “people who play electric guitars” is even better. I would make the assumption that “people who play electric guitars” is a big enough market to make plenty of money in if you’re intuitively solving a real problem that electric guitar players know exists. When you start too broad, it’s difficult to actually collect any useful metrics to help validate your assumptions.

Here’s some tips, tools and methods for validating market demand:

  • Check out industry reports from IBISWorld, Hoovers, or the Census.
  • Look at demographic data from the Census.
  • Look at Google Trends data to find out the search query volume.
  • Use Google AdWords Keyword Planner to determine how many searches related to your market take place on Google each month.
  • Use Google Insights to look at trends related to specific key phrases.
  • Look at the traffic of competing websites using Alexa, Compete, SEMrush, and Quantcast.
  • Try to determine revenue numbers from competitors based on their pricing and your guess of how many customers they have. Sometimes, you can even find their historical revenue numbers on the Inc. 5000 list.
  • Build a landing page (I use LaunchRock) and try to drive traffic through pay-per-click campaigns on platforms like Google AdWords or Facebook Ads (free or paid). Use relevant and targeted keywords and phrases to drive traffic. Traffic is one indication of interest, but getting users to convert by giving you their email address, is even more compelling.

Validating The Problem & Solution

Congrats! You’re confident you’ve got a big enough target market that you can create a viable product. Now, you have to go talk to people who are in it.  Most likely, your friends and family are not a good place to start. You need to find your actual target customers and engage them. It doesn’t always have to be in-person. Sometimes people are more accessible online. This includes discussion forums, Facebook groups, or LinkedIn groups . You could also try to engage with people by attending a Meetup or industry conferences and tradeshows.

Personally, I like in-person meetings because it tells me that if they were willing to give me some of their time to discuss a particular issue then this must be a pretty important problem to solve. The other thing to keep in mind is that you need to talk to the people in your audience that actually possess buying power. Customers and users are not always the same person, especially in the B2B software world.

Validating The Problem

When validating the problem, you need to answer the following questions:

  1. Is the customer aware that the problem or pain point exists?
  2. Is the problem top of mind? Is it an isolated or recurring problem?
  3. Is the customer actively trying to solve the problem?
  4. Has the customer already tried solving the problem themselves? (ex: spreadsheets, home-grown software, etc.)
  5. Does the customer have a budget to solve the problem?
  6. What is the customer willing to pay to solve the problem?

When interviewing your customers, it’s important to ask people open-ended questions about the problem you’re trying to validate. Trust me, they will talk; complaining is an American pastime. Hone in on any problems they mention. If the problem is big enough, they’ll most likely want to show you what they have to deal with. Let them! The opportunity to observe your customer’s current process – how they do things and why – is an excellent learning opportunity. You may also find out ways they’re currently solving their problem or workarounds they’ve put in place to make things “manageable.” This process of discovery should help influence your future product’s implementation. You want to design a UI that naturally fits into the daily lives of your customers. This will help minimize your time spent on training and support while simultaneously increasing the likelihood of retention. Just think, knowing all of this before you’ve even write a line of code.

As your sample size grows, it’s critical you identify any patterns of pain and focus on the biggest highest-priority problems. These are the problems that are top-of-mind, usually some of the first problems mentioned during your interviews.

When it comes to validating price, just ask! Most entrepreneurs dance around this question, but you’ll be surprised how honest people will be with you. If they say they have the budget and are willing to pay then ask for their email address to contact them when the product launches. Sometimes, I’ll even draft up a contract and get paperwork in place where the only contingency is the product being built by x date. If they’re reluctant to sign paperwork then chances are they were just leading you on during the interview.

Once you’ve gotten the hang of interviewing customers, the key is getting a large enough sample size. Your ideal sample size will vary. I usually try to talk to at least 20 customers for B2B products and at least 100 for consumer products.  As your sample size grows, keep in mind that not all customers are created equal. I always give more voting power to customers willing to pay more per user or willing to on-board numerous users at one time than someone else. The second case is a very likely scenario for B2B software products.

Validating The Product/Solution

Ideally, building and validating the product should go hand-in-hand. It should be an iterative process with some amount of validated learning along the way (or at the very least, with every iteration you make). This is the final step and comes after validating demand and validating the problem. It involves constantly asking yourself the question: “Does this product really solve the problem in the market we have identified?” Product validation is even more complicated than market and problem validation.

The best way to validate your product is visually. Here are some of my favorite methods for doing this:

  • Competitor lightning demos – Have your users interact with your competitors’ products. This will help you find out what is good about their product and what things could be improved.
  • Collaborative sketching – get some of your potential customers together or one-on-one and begin sketching out the UI.
  • Wireframes -great for walking users through the workflow of your product and identifying potential issues with feature that are buried too deep in the UI.
  • Hi-fidelity mockups and prototypes (aka vaporware) – brings your product to life and gives the customer a sense that you’re further along than you actually are.

When you do have a prototype ready, you need to get people to interact with it. Remember, you’re not there to sell your idea or your product. You’ve got to take an objective unbiased assessment of what needs to change to improve the user experience of your product. If, for some reason, your users don’t understand how to use your prototype or they’re unable to find  features buried in the interface then that’s a sign that you need to keep iterating.

You may have to iterate through a number of prototypes before you end up with a validated prototype at the end of the exercise. Of course, validation doesn’t end with prototypes or beta testing. You’ll need to continue following the validated feedback loop of BUILD-LEARN-MEASURE in every step of the product life cycle – bug fixes, new features, UI updates, etc.

Things To Remember For Product Validation

  • Don’t be a fool; validate your most critical assumptions before you build your product.
  • Find out your customer’s BIGGEST problem by identifying the pattern of pain.
  • You must find out your price point so just ask your customer!
  • A larger sample size is critical.

If you have any questions about software product validation, feel free to leave a comment or reach out to me directly at ross.morel@frogslayer.com. Don’t forget to follow me on Twitter, @rossmorel.

 

 

Image Credit