Validating a Product Concept: A Lean Approach

It’s easy to pour months — or even years — into building something, only to realize that you can’t make the business work. That’s why we recommend that clients use this tried and true approach to validating a product concept.  

Every Great Solution Starts With a Problem

We’d argue that there are two kinds of problems: those the world can live with, and those begging to be tackled. When it comes to software development, we should always pick the latter.

Which means, before we build any kind of solution, we ask a lot of questions, like: is the problem that we’re solving really worthy of attention? And is the proposed solution desirable, feasible, and usable? Will our product or platform make life easier or the world a better place?

We may think we know the answers, and we can theorize all day long. But we never build on a hunch, and neither should you. Instead, we test every assumption that a proposed solution requires us to make, so we can minimize risks down the road. Running a validation cycle will either help you affirm and refine your concept, or it will save you hundreds of hours (and thousands of dollars) on a project that isn’t worth your time, energy, or capital. We call that a win-win.

Here’s how it works.

But First: Some Context

Our validation process is born out of lean principles. We’re happy to say that we’ve gotten it down to a science: no matter who we’re working with or what we’re testing, we use the same framework and the same methodology. But there are lots of variables at play, which require smart, strategic choices and flexibility in the right moments. So, bear in mind, even with a proven process in place, no two validation cycles are ever alike.

Week-by-Week Validation

Validation isn’t about us or you, the problem or the solution. It’s about the market — because your customers are the ones struggling with the problem (or not), and they’re the ones who will be using the solution (or not).

That’s why customer interviews drive the validation process. Typically, we conduct three rounds of week-long interviews — ideally, with five to seven customers per week. Those rounds directly correspond to our three validation phases, and they help us move from one phase to the next.

Week 1: Problem Discovery/Validation

Our goal in Week 1 is to test our assumptions around the problem that we’ve identified. As far as our proposed solution goes, we’ll have nothing but a verbal narrative right now, which we’ll share with the customer only if they validate the problem first. Our Problem Discovery/Validation questions may be:

• What’s the hardest part of your day?
• What are some unmet needs you have?
• What product do you wish you had that doesn’t exist yet?

Week 2: Solution Discovery/Validation

If the problem has been validated, we’ll spend Week 2 focused on validating the solution — which, at this point, is more than a verbal narrative. We’ll have a visual representation of the product or platform (typically just a set of static screens) that we’ll share with customers in this round. Our Solution Discovery/Validation questions may be:

• What does your ideal solution to this problem look like?
• What are you currently doing to solve this problem?
• What do you think about this product?
• Would this product solve your problem?

Week 3: Product Optimization

If we get to Week 3, both the problem and solution have been validated. Our customers will be able to engage with a live prototype, and the questions we ask will revolve around product implementation, optimization, and pricing. Our Product Optimization questions may be:

• What could be done to improve this product?
• What would make you want to tell your friends about this product?
• What’s most appealing to you about this product?

Customer Interviews: What, How and Why

At the beginning of our validation engagement, we develop the entire interview script. This gives us the option to run through every question in every interview, no matter which phase we’re in.

So, let’s say a customer validates the problem during our first interview in our Problem Discovery/Validation phase. Why stop there? We might as well keep rolling through the script and get answers to questions around Solution Discovery/Validation. Sure, that’s technically next week’s focus — but the more information, the better. (On the flip side, if we find that the problem isn’t really a problem for the customer, then there’s no need to move forward.)

Whether we’re in Week 1, 2, or 3, the goal is to get through as much of the script as possible — and ultimately, land on a discussion around pricing. As we go along, we’ll trim and tighten the previous sections of the script so that we can get to the most important parts as quickly as we can. And, of course, the responses should help us to refine our proposed solution, as we get closer and closer to a live prototype.

Building the Script

The cardinal sin of customer interviews: leading the witness. No matter how great a concept may be, or how solid our assumptions may seem, we’re looking for every reason that they may be invalid. So as we’re curating our questions and gathering answers, we always follow a few basic do’s and don’ts:

• Do focus on the present. That’s where the customer lives, and that’s where the problem is — so avoid hypotheticals and references to the future (however promising it may seem).
• Do get specific. Broad questions lead to broad answers, and those aren’t as helpful when we’re trying to validate or invalidate very specific assumptions.
• Do listen — actively. This isn’t a pitch: we’re here to learn.
• Don’t ignore other problems that the customer mentions. They may be worth exploring down the road, especially if the current problem is invalidated.
• Don’t be frustrated if (and when) assumptions are invalidated. It means we accomplished exactly what we needed to accomplish, and we’re in a position to make incredibly informed decisions. That’s a good thing.

Results and Findings

During Week 4, we compile, analyze, and evaluate all of the responses and feedback that we’ve gathered in the past three weeks. Then, we draw insights and identify trends that either validate or invalidate the assumptions we’ve made.

Our team will pull together a thorough report of our findings, both at a high level and specific to each target market segment. The report typically includes:

• Issues that were typically important to users
• Issues that were seemingly unimportant to users
• Product price point
• User demographics
• Recommendations

What come next depends on whether the product and solution have been validated. If the solution isn’t validated, it may just be a matter of refining the approach. If the problem isn’t validated, we’ll strongly recommend that our client go back to the drawing board — and we’re happy to go with you, because it’s usually not the end of the road. More than likely, other problems were identified during our customer interviews, and they could very well be worth pursuing.

On the other hand, if your concept is validated: It’s time to build. (And we know just the team to help.)