Better Product Managers, and Product Management

I was talking the other day with a friend of mine who works for a Very Large Enterprise Software Company – one that is probably about as opposite from my job as possible.  Nonetheless, we both struggle with how to craft simple, compelling narratives.  With his permission, I’m sharing parts of our exchange.

Enterprise Guy: “Some of the solutions we’re trying to sell are inherently complex and ugly, which is something we’re actually pretty good at handling. But we’re not good at marketing them, because our strength (handling complexity) runs counter to simple compelling narrative.”

Cindy: “Well, you’re correct that the simple narrative that works for simple products isn’t going to work for you.  But that doesn’t mean there is none – it just means that you need to craft one that better plays to your strengths.  You say your strengths are in handling the ugly and complex – now you have to think from the customers’ perspective: what value does that actually create for them?

You have to be honest about what you don’t do well.  You aren’t ‘the easiest solution’.  But that’s okay (the French Laundry isn’t ‘the fastest food’, after all.)  One approach might be to market a sort of reverse Pareto Principle: “If you’re only worried about the 20% of problems that cause 80% of your hassles, we’re not for you.”

Your simple narrative could be something along the lines of “never worry again”, “when every edge case matters”, etc.

EG: “…some of our competitors, who have half-baked software that can’t really solve the complex problem, keep beating us because they tell a simpler, cleaner story. Unfortunately for the client, those solutions often fail because of the inherent complexity of the problem — the client gets bitten by the narrative fallacy by buying into a story that’s too simple.”

CA: First, let’s look at the fact that your clients find the simple narrative appealing.  Why do you think that is?  If I had to form a hypothesis, I’d say it’s kind of like the state of mind you’re in when you need to lose weight. In the back of your mind, you’re pretty sure that getting rid of those holiday pounds is going to require exercise and eating your vegetables and cutting back on the drinks and desserts… and that’s hard work and you kind of dread it.  So when you hear “lose 20 pounds in 2 weeks by eating only cookies!” you’re susceptible.  You really, really want to believe there’s an easy way out.

(That sounds a little condescending, now that I reread it, but it’s not meant that way.  This doesn’t reflect dumb customers, it’s just human nature to seek out easier solutions.)

So you need to:

• acknowledge the appeal of the other, simpler solutions
• educate clients about the ways that simpler solutions have screwed over other customers
• provide relevant examples of how your complexity prevented some big mistake/saved a huge amount of time or $
• without sounding condescending

Here’s how I’d think about it:

“As you know, we talk to a lot of companies in your industry, and here are the types of companies who have done very well with Solution X.” (identify yourself as thought leader, acknowledge the appeal of other solutions, set the stage to contrast this customer with those other companies)

“We know you have X special requirements.  Company Y, who also has similar needs, ran into these problems when Solution X wasn’t able to handle this circumstance.  Of course, it was a rare circumstance, which is why Solution X didn’t handle it, but at a company the size of Company Y, it had a huge impact.” (acknowledge this customer’s unique needs, share relevant FUD story)

You will basically need a different “and here’s what went wrong” case study for every type of customer you pitch to.  If you go to a bank with a retail e-commerce example, the impact won’t be there.

“What circumstances like this are you worried about? Are there areas where you have limited visibility where there’s the potential for similar snafus?” (display your concern for their specific needs, plant the seed that there are potentials for disaster which of course you can solve)

“Company Q, who used our software, ran into this circumstance, which we were able to solve in this way.” (finish with a positive story)

EG: That’s similar to the approach I’ve been using. It’s a variant of the traditional “reference selling” that happens in enterprise software, but instead of using references to help late adopters get on board (the traditional approach), we’re using them to counter the “lose weight with cookies” thought process. This starts to explain why that works and gives a framework for generalizing it.”

CA: Yeah, this would be my basic recipe for your “simple narrative”.  Of course, it will only be “simple” to your clients – it will be a LOT of work for you, since you’ll need to craft different case studies for each type of customer – different industries, B2B vs. B2C, low-tech vs. high-tech, etc.

But of course, “making it look easy” is the hardest thing of all.

EG: “Especially when clients who have failed don’t let you use their names!”

CA: “I feel that pain.  I’ve spent a lot of meetings talking about “a major bank” or “one of the top national newspapers” when a name would’ve opened so many more doors!”

It’s hard to argue with the concept of the Minimum Viable Product (MVP) – build the smallest possible representation of your product vision first – then validate it, get feedback, and refine it.

But how can you balance the Minimum Viable Product with maintaining credibility?

Companies who do not employ iterative development processes may not understand that “version 0.1″ is a mere fraction of what “version 1.0″ will be.  If you’re selling into an enterprise company, you may not get multiple meetings where execs can see your vision unfolding.

When the rallying cry of MVP is “if you’re not embarrassed by your first version, you spent too long on it”, how do you balance that with looking serious enough to get meeting #2?

Prepare: Go direct to the end-users for early testing and research

In a B2B2C situation, you can do a lot of quick and dirty research with your customers’ customers.  You don’t have to tell the customers you’re doing this (it’s very easy to solicit for “users of Company X” on Craig’s List or similar venues).  If you want to be stealthier, you could ask for “users for Company X’s competitor”.

When I worked at Yodlee, my team frequently tested the first (“most embarrassing”) rounds of prototypes directly on end consumers and iterated based on that feedback.

This also allowed me to go into meetings and say “I’ve talked to your customers and this is what they want” – very powerful.  Then we had the opening to say, “Now tell us what YOU want” without sounding clueless.

If you’re working with enterprise software that will be used internally, it’s more difficult, but still possible, to contact employees directly.  It’s easy to find names of people using LinkedIn, and if you compensate them for their time they really won’t care that this is in preparation for a presentation to their bosses, as long as you maintain their anonymity.

Prepare: Invest some time in elegant but minimal design

You don’t need to have your product fully thought out – it’s not even possible – but what you give your customers to react to, can still look professional and polished.   Someone with great UX design and CSS skills can make a great-looking — but minimalist — usable prototype – not as quickly as an “ugly” one but still 5-10x faster than it would take to code it.

“Looks good” is a surprisingly strong indicator of credibility.  A pleasant neutral color scheme, good use of whitespace, and of course, lack of typos, gives customers faith that whatever else you build will also be high-quality.  (I have tried the opposite – presenting essentially the same demo but without this minimal good design, and the difference in reception is enormous.)

Alternatively, you can use a tool like Balsamiq, which gives you “hand-drawn” looking stencils so that you can make UI elements look consistent and legible – but still clearly “works in progress”.   (Another option is to create stencils for Visio or Omnigraffle – a good option if you have a lot of visual elements specific to your industry that you’ll need to reuse over and over.  I had one of my designers create a whole set of stencils, which allowed product managers and other “non-visual” types to sketch out prototypes that looked good.)

Present: Set expectations.

Emphasize: this is early and their feedback can help direct the product. Use flattery (“we’d especially benefit from your feedback because of your expertise in X”).  Follow up with a thank you and synthesis of their feedback (“we understand that your main needs are X and that you’d be looking for something more Y”).  Ask for the followup (“can we contact you next month/quarter to show you the next revision?”).

How much of what you say do you think your audience listens to?

• I’m a user experience designer.  I’m going to notice that you never mention user testing or user feedback as you talk about your product redesign.

• I’m a business development stakeholder.  The longer you wait to put ROI numbers behind those impressive-sounding features you’re talking about, the more suspicious I will become.

• I’m an operations engineer.  I’m going to hear that one offhand comment about “having to do some refactoring to improve performance” when you talk about your roadmap.

• I’m a product manager.  I’m going to see that bullet point about expected marketplace adoption and wonder how the heck you’re going to do that since you don’t seem to have a plan.

• I’m an investor.  I see those inflated Forrester “market cap in 2010″ projections all the time, I don’t take them seriously, and I wonder how you can say them to me with a straight face.

When you’re presenting to prospects or customers, it’s not about what you want to say.  It’s about what your audience needs to hear.

Everyone in the room is waiting for a cue – something that will let them know, will this person (and product) make my job easier or harder.  If you can pre-empt peoples’ concerns, they’re a lot more likely to relax and actually listen to the rest of what you have to say.

(Don’t know what worries engineers, or marketers, or QA testers?  Take some out to lunch and find out.  Don’t know who the stakeholders are at your prospect or customer company?  Shame on you – you haven’t been on good enough terms with your salesperson, have you?)