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!”

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?)

“OK, hang on a second, having some technical difficulties…”

Projectors are not known for their usability.  That said, there aren’t too many variables: a couple types of cables, a couple settings, a few places to look for projection/monitor settings on your laptop.  I learned them.  If you’d rather waste my time than learn them yourself, I’m a lot less inclined to listen to you.

(Also, you never know when you can jump in and be a hero to someone else.)

“You probably can’t read this chart, but here’s what it says…”

Don’t paste in charts from Excel.  Don’t paste in charts from Project.  They will never be legible to your audience, and odds are that they don’t need that much detail anyways.

If you really, really needed to show lots of little numbers and data cells, print out hard copies and pass them around.

“Let me walk you through this slide…”

Closely related to the previous sentence of doom.  If a slide contains data or bullet points that are not self-evident, they are not well-written enough to be in your presentation.

“And then – hmmm, what does this slide mean again?  Oh yeah…”

Let me guess: you finished your slide deck at 2 in the morning. (I forgive you.  I’ve done it too, coffee-powered, in the hotel room.  Sometimes that’s where the best presentation ideas come from.)  But then you failed to take ten minutes in the morning to read through it again and make sure that it all made sense.  Oof.

You should know, at a glance, what the one key idea of each slide is.  If you wake up in the morning and slide 14 doesn’t make sense, please rewrite it or ditch it.  Don’t subject us to projector improv.

“Looks like we’re running low on time, so I’ll just speed through these last slides…”

By all means, race through forty more bullet points without stopping to breathe.  No one needed to take notes or understand what you were saying anyways.

Yeah, it stinks to run out of time on a presentation.  But people have short attention spans.  They remember if you started off strong, and they remember if you ended strong.   They won’t remember that you skipped the last ten slides but they might remember your concise recap of the top 3 takeaways.

Some more good presentation “don’ts”:

Stop Your Presentation Before It Kills Again

8 Bonehead Ways to Blow a Presentation

When pitching investors you have a captive audience. But they won’t stay captive for long unless you can hook them.

Ben Yoskovitz’ article is centered around pitching to angel investors and venture capitalists – something that a lot of product managers may never do. But his tips apply just as well to a pitching potential customers.

There are two in particular that I think are hard for product managers.

1) Be entertaining – in a relevant way.

I think a lot of bad presentations stem from the freshman English 5-paragraph essay format: first tell ‘em what you’re going to tell ‘em, then spend three paragraphs telling them, then tell ‘em what you told ‘em. Okay for your paper on tragic figures in Romeo and Juliet; in a conference room guaranteed to send your audiences diving for their Blackberries.

One opening that has worked well for me is:

“I’m going to start this demo by putting myself in the shoes of one of your customers, and talk about the things that frustrate me.”

Eliminating pain is the driver of success for a lot of consumer products and services. Maybe all of them. Don’t rely on features and benefits slides to make it clear, spell it out: Here is the pain. Here is how we solve it.

If you can hint at that kind of content in the first thirty seconds of presenting, you stand a chance against the Blackberries.

I don’t memorize entire decks, because I can’t do that and still sound natural. But I will practice saying my opening story, three or five or ten times on the drive to a meeting, until the right word choices and pauses and emphasis work themselves out.

Don’t overemphasize the product. For product managers, heresy! Right? Well… in large part, potential customers are investors. They’re trying to decide whether to invest more attention and due diligence, and that means buying into more than just a product:

…Ultimately investors are buying into the team, the passion, and the belief that you can execute on what you claim you can execute on.

Product is a teaser – the promise of: Here is the pain. Here is how we solve it.

Some of the most painful presentations I’ve endured are due to product managers trying to make sure their audience knows about every single differentiating feature. But first I have to be convinced that the product team understands the big picture. Before you show me features, show me that you’re qualified to choose and define features.

Once that initial investment of attention is secured, then you get to sell the product down to the last feature. But it still helps to have some entertaining stories (or really big beautiful pictures) to mix in!