Use Value Propositions to Validate Your Product

By Harry Yang September 17, 2009

I have heard many answers for this question in the past. Here are some of those examples: “I think it is a cool product”, “My VP told me so”, or “Our top three customers told us that they wanted it”. These could be the reasons why you are managing your product. But those statements are not saying anything about whether you have a right product. Does the “cool” attribute solve your customer’s problem? Does it matter whether you, not your customer, think it is cool? Are your VP or your top three customers the only customers that your product targets? As a product manager, I would rather make sure that, in the very beginning, my product concept is the right one that can solve urgent, pervasive, and high value problems for our customers. One effective way for doing that is to define and use the value proposition to validate the product concept before you go too far.

Here is the value proposition framework I use.

For <user persona>, <product brand name>, a product of <frame of reference>, provides <solution> for <user problem> by <distinct advantage>.

Let’s see how a product manager can use it and follow five steps below to validate a product idea.

  1. Identify your user persona. A product can have multiple value propositions. Each is for a different user persona. For enterprise software, most likely you will have at least four user personas. You need to know who is the buyer (the decision maker), who is the end user, who is the developer, and who is the IT administrator. Rarely are they the same person. Take a business process management (BPM) solution as an example. The CIO (the buyer) wants to increase the efficiency of its business processes. The business user (the end user) demands to conduct its business operation in a familiar user interface (such as email). The developer asks for a easy way to construct a workflow. The IT administrator requires uniform environment. If these four attributes ¬— efficiency, familiarity, simplicity, and uniformity — are what those four different personas are looking for, the product manager for this BPM product had better make sure the product concept resonates with the appropriate personas.

    Don’t put assumption based on your previous experience working on a different product. For example, many enterprise software developers are J2EE expert. But you can’t assume that is true for your new enterprise software product. If your developer persona is more comfortable writing Javascript than J2EE Java code, your IDE tools, APIs, and SDK (documentation and samples, etc.) should reflect it. Ask yourself how your personas will use your product.

  2. Know your enemy. Frame of reference is important when you validate your product concept. Often, it is the part most ignored. Do you know your product’s frame of reference? Without a clear frame of reference, you don’t know your competitors and your market segment; therefore, you have no way to position yourself or focus on your differentiation. Don’t take it for granted when identifying the frame of reference. Sometimes, it may appear that your product could fit into a particular product category defined by your competitors or analysts. But before you settle down, think hard how you are going to compete. For example, if you are doing an enterprise wiki product, you may consider following frames of reference with potential competitors.

        • wiki - MediaWiki, TikiWiki, Wikispaces, …

        • web publishing tool - Dreamweaver, Drupal, Vignette, …

        • online collaboration platform - Webex Connect, IBM Lotus, Microsoft SharePoint, shared file system, …

        • social networking - Socialtext, Confluence, Clearspace, …

        • information sharing - email, fax, interoffice exchange, …

        • people empowerment - inspiration speech, off-site team building, monthly employee meeting, …

If you are the product manager, are you going to frame your product as just another wiki or a new way to empower the employees and improve the productivity for your enterprise customers?

  1. Understand the problem your customer has. Do you think your product is cool? Now ask yourself again. Does it matter? You are going to sell your product, not because of how you feel about it, but how your customers will consider it to solve their high value problems. Ask your users in your targeted persona whether the problem your product tries to solve is a high value one that customers are willing to pay for the solution. Take the wiki product mentioned above as an example. If it tries to make it easy for users to post content, it may address inconvenience (such as hard to upload content to a content management system or difficult to copy it to the shared file system). However will an enterprise customer pay a fortune for this? What if the wiki product, instead, targets to improve business productivity by eliminating the barriers for people to share their content? Will this be better positioned and have higher value?

    One thing is worth mentioning, when you research your customer, don’t just target your existing customer, or worse, just top five strategic customers. Although those customers are very important, unless your product has reached all of your total addressable market (TAM) or your TAM just have these five customers, they don’t represent all of the opportunity that you have. You need to find a way to research your potential customers as well.

  2. Explain your solution. This seems easy. But is it really? Do you use so much technical jargon that you need to send a dictionary as a free gift to your customer? Do you use a language that your targeted user persona understands? Your solution is not an architecture diagram. Your solution is an answer to your customer’s problem. For instance, to a business user, instead of saying that your wiki product is an open standard based AJAX web tool, you might try this: the product provides a dashboard in your browser to let you aggregate content, share your thoughts, and collaborate with your colleagues in a single place. Think through your solution, not from a technical perspective, but from your customer’s.

  3. Articulate your product value. When customers want to buy your product, it is because your product solves their high value problems much better than the alternatives. Differentiation is not enough. Your solution must be superior. The superior differentiation, this is the value of your product. If you follow the steps above, you already know your customers, your competitors, the problems that you are solving, and how to solve them. Now the question is whether your product solves the problem better than any other competitor. Remember, you need to be honest with yourself. Don’t fall in love with your product. Check with your customer using wireframes or even a quick walk through. Ask your customer to compare your product concept with alternatives and tell you why yours is different. Your customer is your ultimate judge for your success.

These five steps seem obvious. But you would be surprised to find many product teams that don’t know these answers before they begin developing the product. I have seen many cases and most of the time the mistake was costly. I encourage my fellow product managers to test your concepts using these steps. If you know all the answers, you have a very high chance to build a star product.

Harry Yang

Harry Yang

Harry Yang has spent more than 10 years converting innovative ideas into compelling enterprise software products and business solutions to solve high value problems in a wide range of industries and market segments. He has brought several enterprise products to the marketplace as a product manager and led development of market leading solutions for global 2000 companies. Harry holds MBA from University of California, Berkeley, MS in computer science, and BS in electrical engineering. You can catch his latest thoughts at his blog: An Open Discussion on Product Management and contact him at

Looking for the latest in product and data science? Get our articles, webinars and podcasts.