Better Product Managers, and Product Management

Question: Who should give you feedback on your early-stage product mockups/demo?

a) Your investors

b) Your most loyal, early-adopter existing customers

c) A demographically-balanced segment of people who have no familiarity with your product

d) Anybody, as long as it’s not you

OK, sure, there’s probably an “ideal” audience to show your product to.  But it probably doesn’t matter.

Earlier this week, I emailed a friend with a URL to ask for his feedback.   To be honest, he was far from my “ideal” user testing subject: an expert user, tech- and product-management-savvy, an existing user of previous versions of the product, super-familiar with our company and what we’re trying to do.  The kind of person who’d probably agree with me on what websites rock and what apps are lousy.

How useful could his feedback possibly be?

(I think you know where this is going.)

He was kind enough to send me a Screentoaster video of him navigating through the flows and “thinking out loud” — and from the first glance he started pointing out problems we hadn’t noticed.  Wording that was confusing.  A call-to-action button below the fold.  An interactive panel that we’d thought was awesome – that wasn’t nearly clear enough.  And on and on and on…

Even an “expert” noticed these problems – because he wasn’t me.

Even as someone who’s done tons of critiqueing UIs and workflows, I just hadn’t succeeding in stepping back and seeing our product concept through the eyes of a customer.

So — don’t wait until you have a full product, don’t wait until you’ve done another round of design, don’t wait until you’ve revised your copy.  Get someone to take a look at whatever you have NOW.  Doesn’t matter who – as long as it’s not you.

PS – hey readers, if you’ve got a few moments and can record a Screentoaster video of yourself walking through these flows, email me.  I’ll be happy to return the favor for you and your product!

This is the way the product ends

This is the way the product ends

This is the way the product ends

Not with a bang but a whimper

(apologies to T.S. Eliot)

What happens when it’s time to End of Life a product? Too often, companies just stop fixing bugs, stop answering support emails, and seem to hope that customers will just drift away. This is especially tempting when a product is very early stage and the company is facing a pivot towards a new solution or business model.

However, honest End of Life communication is both the right thing to do and a great opportunity for learning. Even if you think these current customers aren’t going to be your future customers, they can still affect your reputation going forward.

Elements of a Good End Of Life Email

  • Thanks for believing in us
  • Dates when support, access, data retrieval end
  • What we learned
  • What we’re up to next
  • Available substitutes
  • Request for feedback

I recently got an EOL email from the site which has since evolved into 2gov.org, which did a really nice job with the thanks, learning, and what’s next parts:

As an early member of our service for registered voters you provided some incredibly valuable feedback that allowed Votizen to grow in ways we hardly could have imagined. I appreciate all you did to help us at the very start, and wanted to let you know about some changes we’ve made as a result of this input.

Specifically, the Votizen site has evolved beyond its original vision and you will no longer be able to log in to Votizen.com; instead, please find our new service at http://2gov.org. 2gov allows you to easily contact your elected officials through one, simple-to-remember address. Votizen.com will continue to evolve, but for now our main service can be found at the new 2gov.org site. In accordance with our privacy policy we’ll be deleting all information related to the prior site.

Most companies don’t thank their users enough! This email makes me feel like the time I invested in this product — and this entrepreneur — were worthwhile and appreciated.

The only things I’d potentially improve upon: ideally, you’d send the email before access to the original site shut down, and it’s particularly thoughtful to provide alternates – whether that’s another product in your product line or a competitor’s product.

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