I've recently spent much time thinking about communication between product managers, customers, stakeholders and leaders. I've spent time dwelling on this topic because there is a vast gulf in expectations between all parties.
In my 12 years in Product Management, it's always been challenging to learn from peers and thought leaders the behaviours and techniques that should be present in your product management toolkit. Unfortunately, despite the wealth of helpful content covering anecdotes, case studies and theory, it's tantamount to navel-gazing.
So to help me ponder a few topics, such as communication and empathy, I'm writing here to share my thoughts and offer insights into the product management craft, with the hope it will provide valuable insights to a broader audience. Unfortunately, product management regularly gets distilled into this combative quip.
Customers want outputs. Product Managers want outcomes.
The statement above, or variations on the theme, get bounded about on Twitter and Podcasts. To many, it may seem counter-intuitive as product managers work with colleagues trained to design and build software to produce new or improved artefacts for our customers.
In contrast, the role of a product manager is to provide information that ensures their team discovers valuable and usable solutions to customer problems - a process called Product Discovery and a critical topic not discussed outside of product circles. Finally, it's the responsibility of the team's engineering talent will ensure that their solution is feasible and reliable.
Steve Jobs: The Lost Interview has a fantastic description of taking ideas, comments and feedback through a process where a team has the space to explore and polish those initial thoughts to become Usable, Valuable and Feasible products that customers love.
That said, the team's output wouldn’t always be new features. Instead, it could be better documentation, scaling to improve stability or bug fixing. Unfortunately, where an output-focused culture prevails, the product development teams are stuck "Building for the Sake of Building". Melissa Perri calls this situation The Build Trap.
Melissa's book is worth reading to learn about the various hallmarks of organisations and teams stuck in this rut. In short, software teams in this situation are subordinate to Sales, Marketing and Operational departments working as an internal development agency. Where software teams aren't empowered to collaborate with customers, they become a feature factory producing pet projects for senior leaders, building features written into contracts by the Sales Team or writing software without speaking to customers.
Whatever the cause, they'll find themselves writing software with diminished usefulness and overall quality that lacks a certain 'je ne sais quoi', as they aren't solving 'real' problems that create positive change for their customers. What a nightmare! So what's the solution?
There isn't a silver bullet or framework you can adopt to solve this problem miraculously. But, product managers can minimise tensions for their customers, stakeholders and leaders by approaching these conversations with empathy and transparency to explain how ideas move first to product discovery. Furthermore, only some ideas, once polished, will move on to product delivery and the reasons why. Finally, we all need to remember everyone wants a positive result for the company, but it takes empathy and concerted efforts from everyone involved to get on the same page.