4 Areas of Validation

When you start out building a new product, you might think that having an idea and building it immediately is the direct way to success. In my entrepreneurial journey and as an ex-product manager I can tell you from experience that most of the time it’s not.

Instead, there are 4 areas that you should think about and validate those where you need some more information about.

Here are some details.

Let’s assume you don’t work for a company where the decision which new product to build is made by your managers just because they themselves or their cousin had a “great” idea. Let’s assume, just the contrary, that your company values decision making based on research, discovery, and real customer and market feedback. Or you are a founder yourself and want to build a product because you want to build your own business.

You’ve done your research & discovery to find opportunities you want to explore. You’ve found something, and after some more research & discovery you’ve came up with product ideas. Great! But don’t start building the whole product yet! When you’re supposed to work on a new product or feature, there are 4 important components that need validation or at least to be checked first:

  1. Desirability
  2. Viability
  3. Feasibility
  4. Usability

With validating these 4 areas you’re basically trying to reduce product risk, customer risk and market risk. I’ll write about these 3 risk areas at a later point in time in another post. But right now, let’s have a look at the 4 areas in more detail.

1. Desirability ❤️
Question: Does anyone want to have/use my product?

First you need to know or have an assumption on who you want to target with your offer. If your target audience doesn’t have interest in getting or using your product, there’s no reason for existence for it. Before targeting your whole potentially targetable audience, define your innovators and early adopters. These are groups of people who get such a value out of your product that they will forgive you if it’s not full fledged as long as it gets the main job done. Start with them. Understand them. Ideate for them to serve their needs.

On a feature level, you’d test if the feature will be used at all by your users.

2. Viability 💰
Question: Will they pay for it?

Do you want to make business with your product? If not, skip this question. If yes, only knowing that they like your product idea isn’t enough. You need to find out if the value your product creates is big enough so that your target audience will pay for it to be able to use it. If not, you’ll need to strengthen your value proposition, change the channel, or the target group & market. You might work at a company that already has cash (VC money or profitable) and follows other business goals than making revenue. That’s fine. Then the check against viability is the check against these business goals. For example, if growth is your focus, then validate how this new product in the portfolio can help grow the business overall.

On a feature level, you’d test if the feature helps to achieve the business goal, i.e. revenue, growth, etc.

3. Feasibility ⚙️
Question: Can I/we build it?

You might have the concept for your finished product in mind. But do you really need to build the whole thing? No! In the first place, you need to make the core value proposition work. Somehow. It doesn’t have to be even software. It can be a completely manual process like in the concierge or mechanical turk methods. If you want it to be software, here is where no-code tools can help you to get started with your…cough…”MVP” (Minimum Viable Product). If you have developers who can build it or are one yourself, and it doesn’t take a lot of effort, fine. Otherwise save money with the manual processes or no-code tools. Because only once you start offering your service you’ll see if it’s really desirable & viable as you’ve validated and see how to grow the product.

On a feature level, if it’s a low risk and quick to build feature you could just go ahead and build it and analyze in production if it was a good feature. If it’s a big or risky feature, you’d still want to check if you can serve the same value with a smaller version of the feature.

4. Usability 🎛
Question: Is it easily usable?

So, you’ve validated the value proposition, you’ve validated there’s a market, and you know you can deliver the service somehow. Chances are, however, that your product is not super user friendly because it’s an MVP. Now is the time to make it user friendly. Find out how you can build it for real and in a user friendly way. Get feedback from your audience in this process. In the end, you’re building it for them, not for yourself. If your product isn’t easily usable, competitors can shoot you down from this angle. Plus, to reach the next adopter group, the Early Majority, the service needs to be stable, usable and provide more than only the core value proposition.

On the feature level, it’s the same. It should be usable. Really.


As a general rule of thumb, this is the order you should validate your product idea. The order can change depending on the industry and type of product.

If you know think that it’s very tedious to validate every single step, here are some good news for you: Except the usability piece, it has become easier to validate these areas since the no-code movement has started. You can use no-code tools to set up small experiments to validate desirability and viability the same way you can use them to build your MVP.

Besides that, you might also skip the one or the other piece of the validation. For example if you know exactly how to build it, go ahead. But see this as a checklist to make sure you’ve thought of the important pieces that affect the success of your business.

Share the Post:

Related Posts

Agile Roadmaps in Practice

An Agile Coach approached me and asked me for reference documents or people to share with him. He wanted to gather some examples on agile roadmaps but it was difficult for him to find good examples of agile roadmaps. Most of the examples that he found were far from agile.

Here’s my answer.

Read More

“Why would you need Product Ops?!”

I was very skeptical about Product Ops.

I couldn’t grasp it. What’s Product Ops anyway? What do Prod Ops Managers do the whole day? Why do we need yet another new role and even a whole new team that does things that we’ve been doing without them the whole time? Aren’t we sick of creating new titles for old concepts?

UNTIL….

I talked to Chris.

Chris Compston. Check him out!

Hi Chris.

Thank you Chris.

Chris is my best friend now. Sorry old best friends, you’ve been pushed aside (you are not but you know I need the dramaturgy).

Read More

Agile Roadmaps in Practice

An Agile Coach approached me and asked me for reference documents or people to share with him. He wanted to gather some examples on agile roadmaps but it was difficult for him to find good examples of agile roadmaps. Most of the examples that he found were far from agile.

Here’s my answer.

Read More