Don't be a product expert
How to use product knowledge strategically and why it's more important to be an expert in the problems your customers have than your specific product and features.
/
0 min read
Memo: Don't be a Product Expert
(via email to the company)
Recently Iโve noticed many Robinauts spend a tremendous amount of energy learning product details, both for Robin and for [competitors] in our space. As we grow, this approach will get exhausting โ especially for folks navigating customers and prospects all day. In short, yikes!
To avoid getting weighed down by changing details (and stay approachable for customers), we must be problem experts, not product experts.
Problem experts get better results, regardless of role. Across the organization their flexibility makes them more successful at closing deals, designing useful features, and inspiring confidence in customers adopting new functionality. Problem experts may also have a deep understanding of the product, but use this expertise strategically (and sparingly).
A few ways to spot the differences in this approach:
A product expert spends time learning how a feature works. A problem expert understands why customers find the feature valuable.
At Robin, a product expert can tell you the exact permissions supported on a desk reservation, and whatโs next in the roadmap.
At Robin, a problem expert knows booking permissions are one way to control who shows up to the office, and how [desk] check-ins or [COVID] health checkpoints are important parts to the same story.
A product expert focuses on accuracy. A problem expert focuses on impact and outcomes.
A product expert looks for ways we can match competitor functionality, and gets defensive when a prospect brings differences up. A problem expert understands most problems have many solutions, and helps prospects understand trade-offs to alternate approaches.
A product expert believes new features need differentiation to succeed. A problem expert knows not all features need โspecial sauceโ to succeed โ we win by focusing on innovation for our most valuable and hard-to-copy features instead.
Example: We don't need to differentiate on health checkpoints, but we do need to lead with an approachable desk booking experience.
A product expert memorizes new talking points for every new feature release, and relies on one-pagers to share specifics. A problem expert seeks to understand how each update improves our ability to solve a problem, and updates their talk track only when it helps paint a clearer vision.
A product expert highlights each change, as we make it. A problem expert prefers that 80% of changes are gradual and seamless improvements without fanfare, so they can highlight the 20% that matter most to their audience.
A product expert wants all plans documented ahead of time, and gets frustrated when they change after release. A problem expert understands regular releases are a powerful way to learn, and doesn't get stuck on details we expect to rapidly improve.
A product expert avoids setting future expectations, since plans might change. A problem expert actively manages expectations so customers understand the vision and are ready for whatโs next.
So please, don't be a product expert โ you're all much too talented to stop there.
โ Zach
โ
Wrap Up
If you work in a go-to-market or customer-facing role, you spend a lot of time presenting your product. And it changes constantly. If youโre not careful, it may even seem like your primary job is to showcase features and deliver news when the product changes. But that isnโt quite right. Your actual job is to connect the capabilities of your product to your audience, so they can find value in it too.
Itโs a small but important difference โ and why you should be an expert in your customerโs problems, not just the features your product has that week.
Tell a better story with product + feature demo videos
Learn how Rally makes great storytelling easy for your whole team, sales to customer.