Better Product Managers, and Product Management

You know the phrase – to eat your own dogfood – meaning, to use your product thoroughly so you recognize when the workflows are awkward or the help text is unhelpful.

But what happens is that we’re eating dogfood with a side order of the Curse of Knowledge.  We know how our products ought to behave and we know what they’re capable of, and that affects our impression of how easy they are to use.

So what we really need to do is eat someone else’s dogfood – that is, experience our products as though we were someone else, a someone who lacks all the inside knowledge that we have.

Here’s what I did last week:

• I offered to set up customers’ KISSmetrics funnels for them (this offer still stands, if you’re interested)
• Customers who agreed, I walked through their sites and identified the key workflows that I believed they ought to be tracking
• I created their funnel events and reports, and checked back to troubleshoot them
• I followed up (via email or phone) to explain what I’d done with their accounts and why I recommended using the product in this way

And you know what?

1. It was a LOT of work.
2. It was totally and completely worthwhile.

Being completely unfamiliar with their sites and goals put me in a similarly handicapped position as the customer who is unfamiliar with my product.  It became painfully obvious that certain copy was being ignored and that some features were grouped poorly.  There were several configurations where I thought, this would be much easier if we’d provided a visual example instead of trying to write inline help.

Equally valuable was the followup.    I would say “I’d recommend you use the product in this way–”, and someone would respond with “–but we can’t, because of this detail of how our application works”.   A step-by-step walkthrough primes the customer for a lot of little “but…”s and “why?”s that might never make it into a bug report or feedback email.

–

As I’ve written this, I think “but doesn’t this sound like the ‘traditional’ product approach?  Telling the customer, “here’s our product and here’s how you should use it” instead of understanding their needs?

And I think the difference is that these conversations were preceded by months of customer development, and conducted (as best I could) as a conversation.   This is where tone makes a big difference.  “Here’s how you should use our product” is very different from “Based on [assumptions], I recommend you use our product in this way – let me know what you think as I explain the details.”

There has been a lot written about early stage customer development – finding your market, identifying pain points and constraints, creating a vision that reflects customer needs without being ‘what customers ask for’.  But I’m finding that later stage customer development is a bit of a different beast.

It’s the time to move beyond abstractions and into specifics.  You’ve proven your case in theory; that’s why customers are using your product.  But there are definitely gaps in practice between how you envision customers using the product and how they actually are.  I’ll continue to write more as I learn more.

Popularity: 1% [?]

Popularity: 1% [?] blog comments powered by Disqus