product management | An Open Discussion on Product Management

Posts tagged ‘product management’

Eight of Ten Customers Agreed with Your Concept. But Is It Enough? You will Be Surprised.

You are a product manager of an enterprise software product. You had planned a new feature and went out to validate your concept with 10 customers. You had carefully selected these customers and made sure that they represent all verticals targeted. You had a pretty good result. 8 of 10 customers expressed positive feedback to your idea. Now you are preparing a meeting with your VP to report the result and is going to claim that majority of your customers will welcome and pay for this new feature. Sounds familiar? But wait, you will be astonished when you finish the reading.

One thing that a product manager needs to do is to interview customers, whether they are existing customers, evaluators, or prospects. Those interviews provide key insights on urgent, pervasive, and high value customer problems that your company can solve. Based on information gathered, product managers decide the product concept and write their use cases and user stories . So to make sure what you gathered truly represents the market that you are targeting is very critical.

In enterprise software sector, I have seen popular practice focusing on a few large or strategic customers. In one team, I have seen that the top favorite 10 customers were visited by product managers constantly. Many use case references point to those small set of customers. Yes, those customers are early adopters, provide majority of revenues, are most vocal, or are most friendly to the company. But are the data gathered from them sufficient enough to warrant a new concept, new use case, or new feature that represents all of the other customers in the same market?

Putting aside the bias from the existing customers, the number (10 in this example) of the sample size itself causes the question of its representativeness. Let’s use some math here. Statistically, you want to get a sample size that gives you enough confidence level with acceptable confidence interval. If you like statistics and are comfortable with formula, Wikipedia has a great page explaining this in more detail. But don’t worry, you can find a calculator and a simple explanation here.

Let’s take an example. Assuming you are targeting global 2000 companies and consider each company as a single customer, how many customers do you need to talk before you have a relatively confident answer of your product features? Let’s plug in some number.

population: 2000
confidence level: 95%
confidence interval: 10%

This set of number means that if you get your 60% of customers saying your concept solved their problem, you have 95% of the chance that you are right. So how many customers that you need to interview to get this? It turns out you need to interview more than 10 customers; you need to get at least 92 customers.

Let’s do the other way, in my example above, how much confidence interval is it for that team to validate the concept? Through the calculator, the number turns out to be 31%. What does this mean? This means that even 8 customers (among of 10) tell you that your concept is the right one for them, you may still end up wrong with your targeted global 2000 customers. In other words, even if you just ask those 10 customers to toss the coin to decide whether they like your idea, purely by chance, you could easily find that you will have 6, 7, or 8 customers all toss the head and claim agree your idea. This is pretty dramatic then most of us expect. And if your favorite 10 doesn’t represent the proportion of your targeted vertical, you will be in even bigger trouble.

So next time when you decide to validate your concept, look beyond your favorite customers.

January 24, 2009 at 10:41 AM Leave a comment

Five Steps to Validate Your Product Idea by Using Value Proposition

Often times, people write value propositions for their products as part of the marketing exercise in the later part of release cycle. On the surface, it sounds right, because you need to have a statement to sell your product. But think twice. Ask yourself: “why should I build a product without knowing how to sell it”?

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?

3. 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.

4. 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.

5. 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.

January 12, 2009 at 8:53 PM 1 comment

Where to Gather Requirements From Enterprise Customers?

Reading Tuned In, written by Pragmatic Marketing folks, one thing strikes me. When it talks about how to find unresolved problems, it asks to “look for problems in your entire market, not just your customer base”. Wow! It is a simple idea but many of us in the enterprise software business probably forget to do it. I have seen many enterprise product teams to get their new requirements, user stories, and features mainly from the existing customers. Sometimes, they may just overwhelmed by a few major customers.

The problem to just tailor your products for a few major customers is that they probably represent just a small but important portion of your targeted customers. In addition, they have already had your product and probably have more requirements on incremental enhancements and tactical problems.

To tweak features to please your existing product is enssential to your business, but it is your incentive to move the discussion beyond small incremental improvents and instead focus on the problems that will make your solution complete, and on new problem areas that you can address. Don’t forget to get your user stories from those potential and unaddressed customers.

December 22, 2008 at 9:18 PM 3 comments

A Product Manager for Just 3-Month?

I came across a job post that is looking for a product manager for a 3-month contract. I immediately had a question: what is the kind of product that only needs a product manager for just 3 months? There are several possibilities:

It is a product with a short life cycle, very short, like 1 month release cycle and 2 month shelf life. But does this product have road map beyond this single release? If there is no future, why does a customer want to buy it?
The team only looks for a product manager to a very limit number of activities during the product management cycle (Pragmatic Marketing has a good framework). But it will be difficult for a product manager to do the job without having time truly understanding customer problems and laying out the direction.
The recruiter probably doesn’t appreciate what a product manager could play in the success of the product. He/She may just want a product manager to come in, write requirements (magically), have a nice 200-page MRD/PRD, and leave it for engineering to carry through.

There could be other possiblities that I can’t think of. Will you hire a 3-month contractor for your product management team?

December 12, 2008 at 9:36 PM 2 comments

What is the Product Management?

What is the product management? Particularly what is the product management of a software product? There is no clear definition. Wikipedia has a definition. But I don’t that it is as complete as it could. Since the context is too broad, let’s focus it on software business in which I have spent almost all of my career.

When I asked other product managers what they do daily, I got variety of answers. Some of them worked like a UI designers and testers. Some of them did so-called outbound product marketing because the product is defined mainly by engineering teams. You can expect more answers than that. And if you talk to 10 product managers from different companies, you will probably get 10 different answers.

So what is a software product manager to me? I thought that I had an answer when I started this blog. But when I about to write it, it appears to me that I don’t. But I do have several thoughts about it.

A product manager is a broker, who can sense the demand – customer needs- and generate the supply – a idea converted to a product.
A product manager is a puzzle solver, who needs to connect dots together, from an opportunity, an idea, all the way to the post-launch follow through. Not only that, a product manager should realize that those dots are not connected as a line. In fact, they are connected as a spiral circle. And you need to have a clear vision on where you want it to go.
A product manager is a care taker, who will take every step to nurture the product, from a concept to a successful release. This means that a product manager will think it as a whole yet pay attention to the detail.
A product manager is a master negotiator, who must have a way to bring all the cross-functional teams together, communicate and convince them, and make tough decisions for necessary trade-offs.

Let me try to summarize it in one sentence. A product manager is a master who can carry a team of different players to convert an idea into a product into a growing marketplace to meet specific needs.

Let’s see whether I will be still satisfied with this definition in a year.

November 21, 2008 at 6:10 PM 2 comments

An Open Discussion on Product Management