Comment by dchuk | Hacker News Reader

Comment by dchuk | Hacker News Reader

I have a large team of product people, and work with a growing team of sales people.

Something I’ve been doing recently that’s really important for this is highlighting to everyone customer facing the difference between client and customer.

Clients hire you to work for them on something.

Customers buy your product.

Said simply, it’s an inverted demand situation. Clients flow requirements to you, customers get features deemed most valuable by product folks.

Shit starts to break down horrifically when you treat your customers like clients, the reason being is that you’re not internally dedicating engineering resources to that customer, so you’re mismanaging their expectations for delivery of asks.

There’s a whole detailed flow on this I need to complete as a blog post, but understanding and educating on this basic distinction helps a lot.

“customers get features deemed most valuable by product folk” - perhaps I am misreading the intent here, but this seems like a license for product people to ignore really getting to know the customer problem. Contrary to popular SV wisdom, I believe that most customers really do know what they want, at least most of the time and in broad brushstrokes. Many of the best products I’ve worked on have come from asking customers what they want! See http://brettcvz.com/posts/49-finding-product-ideas-in-new-cu... for a more detailed write up.

It's not about what they want typically, it's what they need. Most customers/users aren't incentivized to solve upstream problems for themselves, instead they just need to use the tools they're given to do their job (at least in B2B area).

Product people should rarely if ever react directly to WHAT customers ask for, but instead dig in and understand WHY this ask is coming up. Then you'll get to the good stuff.

EDIT: For clarity, I fully agree that product people must learn the customer's problems. Just be careful responding to what they ask for when doing so.

Okay I think we’re saying pretty similar things then!

The “top two” technique works particularly well for addressing “performance” type features for products already in market. Most customer requests, and most of the things that my stakeholders come to me with, are around ways the current product could better address the existing problem it’s trying to solve, rather than finding whole new customer pain points.

Reply on news.ycombinator.com