Better Product Managers, and Product Management

• “Isn’t customer development just product management?”
• “You don’t really need product management if you do customer development right.”
• “Customer development is fine for startups with no process, but it doesn’t fit into a mature product management organization.”

I’ve heard all 3 of these, and I think they’re all completely wrong.

Customer development and product management are two complementary tools.  Used together, they provide a competitive advantage to any products company.

Customer development is not the secret to creating a great product.  Let me repeat that, because I’ve heard many people claim this: Customer development does not create great products.

Customer development is primarily a risk mitigation tool.

It replaces that uneasy guesswork of assuming there is a market for your idea based on:

• analyst reports
• what your competitor is doing
• the opinions of the highest-paid executive in the room

You start customer development with a hypothesis, which you are trying your damnedest to disprove. If you go in trying to prove that you were right, guess what? That’s exactly what you’ll find.

Instead, if you go in with a high degree of skepticism and a commitment to pushing beyond “yes/no” answers and vague “sounds like a good idea” statements, and still find that people are yelling/anguishing/laughing/cheering over your problem statement, then you’re safe to continue.

At this point, we move into what most of us have traditionally known as product management - envisioning requirements, prioritizing, identifying constraints, pricing, working with engineers to get the thing built.

Of course, the product manager who is also a practitioner of customer development doesn’t stop getting feedback after that initial phase — they continue talking with prospects and customers to refine and to collect more detailed feedback as the product emerges.

Customer development is also an opportunity identification tool.  If you’re a product manager in a more mature organization, you are less likely to be looking for a whole new problem to solve or a whole new product to create — your company already has customers and product lines.

It’s easy to think, “these people are already our customers; we don’t have anything else to sell them: what’s the point?”

The point is, even customers who are happily paying you may not be using the product the way you expected them to.  They may love your product — but also wish they could do X and Y.  They may not even realize that they’re doing something that is time-consuming or expensive or resource-intensive — where you could save them time, money, or people by introducing a new feature or way of using your product.

In traditional product organizations these opportunities usually come through VOC (voice of the customer) feedback.  But customers are often unable to articulate what they need, especially if it’s something they don’t even realize is a problem.  The active “pull” of customer development interviews, as opposed to the passive “push” of VOC, gets richer feedback (and guarantees that you aren’t being unduly influenced by your “squeaky wheel” customers.

Popularity: 9% [?]

September 22nd, 2011   View Comments  

Last week, I wrote a blog post in which I said,

The answer to any question that starts with “do you want” or “are you concerned about” will always be “yes”.

I wanted to expand on that a little bit more, because most product managers will need to understand whether their customers really do value a certain feature or value, and they’ll need to understand the obstacles that potentially prevent someone from becoming a customer.

The reason for this phenomenon is that “wanting” is free.  It doesn’t cost your prospective customer anything to “want” feature X, customization Y, added security, privacy, or fiber.

To change this dynamic, you need to make “wanting” no longer free. (A more sophisticated version of this is conjoint analysis; but I’m just going to talk about the simplest level.)

How do you put a cost on customers “wanting”  things?

• Stop asking yes/no questions.   It’s way too easy to say “yes”.
• Insist upon details. This doesn’t mean asking for customers to define the features they want (99% of them won’t be able to anyways), but ask how they would use it, in what situations it would be beneficial, how their life is worse without it.*
• “Think out loud”a cost. “So, if this would regularly save you 2 hours a week, and your time is worth at least $20 an hour, then you’d be gaining $40…?”  (Note: this is not asking people what they’re willing to pay, which they won’t answer anyways, but it gives you some insight into order-of-magnitude — if someone goggles at this question, it probably means they were thinking they’d pay $4, max.)

* This caught me out just the other day: someone had me on the phone for a customer development interview and I said I was interested in some feature.  Well-trained, the interviewer asked me to tell him more about how it would make my life better… and I totally drew a blank.  You caught me, I said, theoretically it sounds interesting but I can’t tell you why, which means I probably wouldn’t pay money or change my behavior to get it.

One of my favorite anecdotes around “wanting” dates back several years, to when I was working with a client on usability tests.  My team had produced the prototypes and handled all of the administration around getting and compensating participants; the client’s user researcher was on hand to ask additional questions (and spy on us because she was clearly suspicious that we’d managed to set up in 1 week the type of testing sessions that typically took her team months.)

The app we were testing was in personal finance, so the user researcher insisted that we ask about privacy.

Despite my objections that constructing a yes/no question would get biased data, the user researcher asked each participant, “Are you concerned about privacy when it comes to your financial information and identity?” Of course, they all said “yes!”

As the final person said yes, I jumped in: “Thanks for participating in our test.  We have your $50 check ready for you – here an evil little glint appears in my eyes — you just need to write down your social security number and mother’s maiden name for our records.”

I waved the check; the guy said “OK,” and reached for the sheet of paper and pen.

(I didn’t actually let him write it down! But here he was, “very concerned about privacy…” — but not concerned enough to give up $50 for it!)

Popularity: 7% [?]

September 15th, 2011   View Comments  

1. Whatever people say they will pay for it is wrong.
2. If someone says, “I wouldn’t personally use it, but I bet other people would”, no one will use it.
3. The answer to any question that starts with “do you want” or “are you concerned about” will always be “yes” .
4. If someone says “maybe it’s just me, but…” — it’s not. Especially if it pertains to your product being hard to use or your marketing being unclear.
5. If you want to charge money for your product, don’t talk to people who try to get everything for free. (They might eventually be customers, but not until your product goes more mainstream or becomes a defacto standard.)
6. What features your customers ask for is never as interesting as why they want them.
7. Almost anyone will do almost anything for you as long as: the request is short, you are enthusiastic, they don’t have to make any decisions that require more than 1 minute of thought.
8. The two driving forces of purchase and usage behavior are apathy and the desire to avoid looking/feeling stupid.
9. You can’t build a good product if you don’t genuinely like the people who’ll be using it.  You don’t have to be like them, but you have to like them.
10. Whenever you start thinking “this is a lot more complicated than I originally thought”, you should immediately stop and find a sounding board. You are probably either wrong or overthinking things, and an external brain will see it much faster than you.

Popularity: 25% [?]

September 8th, 2011   View Comments  

Are you designing/coding something with radio buttons or a drop-down menu?  Stop!

I’m going to show you how taking an extra 30 seconds to identify the type of choice and presenting the appropriate defaults can save you a ton of errors, dropoffs, and customer frustrations.

Which of these describe your choice:

There is only one right answer, and that answer is obvious to the customer

Don’t set a default. For radio buttons or checkboxes, that means nothing should be selected.  For dropdown menus, that means adding an explicit first option called “Choose one:” so that the menu doesn’t default to the first alphabetical choice.

There is only one right answer, and that answer is NOT obvious to the customer

Don’t provide options at all. This seems counterintuitive, right?  If you’re asking a hard question, it seems like you should help the customer by telling them what the possible options are.

But what happens is that customers will simply choose an option at random, and if they guessed wrong, an error will happen.  (Very bad if you are doing an emergency funds transfer to save yourself from overdraft!) It’s better to force them to type in an answer, which they will do slowly and with more care.

There are multiple acceptable answers, but you can guess which one would be preferable to the customer

Set a default and (preferably) explain why. I often hear product managers say something like “well, the customer should pick X, but I want to let it be their decision…”  Guess what?  People hate making decisions!   If you know we should pick X, throw us a bone and pre-select X for us.   Please.  We will appreciate having that 5 seconds of my life and those 5 brain cells spared!

There is one answer that is probably right unless [some situation applies]

Set a default and explain clearly what that exception situation is. Offer an email address or more info icon so the customer can feel really sure that the situation does / does not affect them.

Popularity: 9% [?]

September 1st, 2011   View Comments