10 Hacks of Customer-Centric Enterprise Product Managers "Product people - Product managers, product designers, UX designers, UX researchers, Business analysts, developers, makers & entrepreneurs 6 September 2018 True Customer Feedback, customer interactions, customer obsession, Enterprise Product Management, Product Management, Mind the Product Mind the Product Ltd 1605 Product Management 6.42
· 8 minute read

10 Hacks of Customer-Centric Enterprise Product Managers

Over the years I’ve worked alongside a number of enterprise product managers in many companies. Those who have stood out to me as particularly customer-centric have had two qualities in common. The first quality is about laying foundations and the second is about finishing touches.

I’m a product manager at Adobe, a company with a long product management tradition and which has produced some of the best products in the history of software. I see the immediate impact on our customers when my team and I exhibit these traits.

The Foundation: Immediate Access to a Diverse set of Customers

Few product managers care to admit it, but many don’t spend enough time understanding their customers, despite the amount of time they spend with them. And since product managers are supposed to be knowledgeable about their customers, there is a certain level of embarrassment, which makes it harder to address this issue openly.

The lack of time spent understanding customers happens for a few different reasons:

  • Some product managers wait to be pulled into customer conversations by field sales representatives. However, field sales reps are understandably cautious about adding someone to a customer conversation. They need to trust the product manager before they introduce them into a relationship with the customer.
  • Often when product managers are pulled into customer conversations, they are asked to either present the product roadmap or help out with an escalation, neither of which are ideal for learning about the customer.
  • During product roadmap presentations, product managers are expected to appear knowledgeable. This doesn’t allow product managers to feel confident to ask all the questions they would otherwise ask.
  •  There’s usually an urgency to customer escalations, which means it rarely feels like the right time to take a step back and learn about the customer.

The above points mean that many product managers don’t have enough opportunities to learn about crucial product requirements such as:

  • How the customer is organized
  • How the customer would like to buy the software (the biggest pitfall in my experience for enterprise products)
  • How the customer would like to use the software
  • How the customer would like to get value out of the product
  • How one customer differs from another

Instead, some product management organizations start defining imaginary personas and use cases – all in the name of customer obsession. These imaginary personas and use cases may make a lot of sense on slides, but have little to do with reality, which typically doesn’t follow conventional wisdom.

This lack of meaningful customer interactions then leads to confirmation bias. The little time that is available is used to confirm ideas with a few randomly selected customer accounts (typically the ones the product manager has access to) and a specific group of customer representatives within these accounts (see Figure 1), who may belong to the same use case.

Figure 1

Similarly, when confronted with customer requirements that belong to separate use cases (see Figure 2), these are looked at as confusing and are dismissed as being meaningless. Some product managers then introduce their own devised use cases, which make sense to them, but do not consider how the customer would use the product, or, more importantly, buy the product. I call this “building enterprise software while bypassing customer requirements at scale”.

The solution is to take customer input – even contradictory – very seriously and to dig deeper into requirements with other customers to gain insights. For further reading on this I suggest you look at Jason Lemkin’s 20 Interview Rule. This is why it is critical for product managers to have easy and immediate access to a big pool of diverse customers to tap into for input. The lack thereof inevitably leads to poorly specified products, so it is the product manager’s responsibility to provide themselves with this foundation.

Figure 2


Product Management Hacks – Ways to lay the Foundation

  1. Make friends with the field: It works like a bank account, which means you will have to invest in these relationships before you get to use them. Make yourself available for presenting roadmaps and product demos, help out with escalations or whatever else is needed. Make them consider you a valuable resource.
  2. Leverage partners: figure out ways to leverage partners to understand adjacent categories and use cases. I had partners who allowed me to join their customer advisory board meetings, which was way more insightful than anything I was able to find on their websites.
  3. Be known in your industry: speak at industry conferences and engage on social channels such as LinkedIn, Quora, Twitter and others to build your credibility with customers
  4. Use the roadmap wisely: before presenting a product roadmap say that before you go over the product roadmap, you would love to spend a little bit of time on finding out more about their business.
  5. Hold a high standard by making it measurable: every time your team has a customer interaction (whether on-site or over the phone), collect the information on a wiki and do a little debrief. Doing these retrospectives in a group makes it a routine and allows the product management team to share best practices with each other for gaining customer insights.

The Finishing Touch: Precision in Defining Personas and Use Cases

To keep up with the day-to-day rush, many product managers take shortcuts and resort to defining (shell) use cases with vague personas such as “the user”, “the marketer”, or “IT”, which don’t adequately capture the complexity of customer requirements. The lack of time spent with customers is the underlying issue here, because many product managers don’t have easy and immediate access to sufficient and diverse customer input.

Not only is it hard to build a product this way, but in the end, customers won’t be able to recognize themselves and their needs in the product, which only leads to poor – or worse no – product adoption.

One of my favorite quotes about enterprise software is that “Enterprise software is about solving (seemingly) underwhelming problems … but at scale.” The “scale” part is the key to what makes the whole proposition so hard to solve.

Scale can come in many different shapes and forms, and typically falls into the following categories: technology, people, process. It is often assumed that technology is the hardest to solve for, but it becomes unnecessarily harder or even impossible to solve with inaccurately captured personas and use cases. You can’t engineer your way out of a wrongly defined problem.

Once you have easy and immediate access to a sufficiently large and diverse customer base, you have all the ingredients for being precise about your personas and use cases, but you still need to be intentional about it.

Product Management Hacks – Ways to add the Finishing Touch

  1. Be intentional with your words: when thinking or talking about the customer, avoid using the word “customer”. Instead say “users on the customer side”. The word “customer” perpetuates the mental model of a single user on the customer side as opposed to an oftentimes multi-dimensional matrix of personas that can have very complex relationships between each other.
  2. Collect organization charts: Some industry conferences collect organization charts and make them available to attendees. It is a great way to educate yourself on the many ways customers organize themselves. Also, simply make it a habit to ask your customers to share with you their organization charts.
  3. Leverage partners: Ask partners such as ISVs, implementation partners, or agencies for their input. Always keep in mind that they might be approaching the same use case from a different angle, so make sure to reconcile their input with your own info before acting on it.
  4. Know your verticals: Learn about the different verticals your customers are in, understand their jargon, and how their teams are structured. A good way to get started with understanding verticals is to regularly read quarterly business results of publicly traded companies. These contain valuable information about companies such as the KPIs they focus on, and the challenges they face.
  5. Hold a high standard: Promote the above strategies within your team by asking specific questions about the personas during spec reviews. Even team members outside the product management organization should engage. Product marketing management and engineering can play a special role here in keeping the product management team honest by asking for detailed descriptions of the use cases, which should include sample organization charts at a minimum. As product management leader create an environment that encourages each product manager to build a solid customer base. Report on the number of customer interactions each week and measure all the use case and persona related information that is being collected. Each product management organization should have their own “handbook” about personas and use cases, which contains all the details gathered by the team and serves as system of record allowing new product managers to get up to speed quickly.

In Conclusion

Product management is arguably one of the most intriguing and rewarding job functions because of its potential impact on the customer. However, it requires both creativity and perseverance in abundance, which can be exhausting. Hence, being systematic about it is critical for delivering products that customers not only find useful but truly love.

Building products is like running a marathon, or perhaps more accurately a long series of sprints. In any case, you don’t want to lose too much of your time, energy and mental bandwidth on the fundamentals. Otherwise, you won’t be able to go the distance. The two traits in this article will help you and your team get there while maintaining – and possibly increasing – your pace.

Comments 0

Join the community

Sign up for free to share your thoughts

About the author