As a software architect I've worked with multiple product managers over the years. Most of them position themselves as the "voice of the customer" or the "bridge between business and technology." Recently, while listening to the Software Captains podcast interview with Peter Janssens(in Dutch) about Product Management, Peter shared a quote that perfectly crystallized what effective product management really should look like in practice:
A product manager has two ears and should use them equally—one ear to listen to the business and customers, one ear to listen to the product and development team.
This simple metaphor aligns with my experience when my collaboration with a product manager resulted in the best possible products. I unfortunately worked with some product managers that only used one ear, resulting in a mediocre product, budget overruns and lack of innovation.
The two ear product manager really makes all the difference.
So if you are a product manager (or have the aspiration to become one), this post is for you…
 |
| Generated with Bing Image Creator |
The familiar ear: Customer and business listening
Most product managers are already skilled at using their "business ear." You conduct user interviews, analyze market research, dive into analytics, and translate business requirements into product features. This external listening is crucial—it ensures that we're solving real problems and building something people actually want.
You know how to ask the right questions:
- What pain points are customers experiencing?
- Which features drive the most business value?
- How do market trends affect our product strategy?
- What do sales teams hear from prospects?
This outward-facing listening keeps the product manager grounded in reality and market needs.
The overlooked ear: Development team insights
But here's where many product managers miss a golden opportunity: the development team is a treasure trove of innovation waiting to be tapped.
Your engineers, designers, and technical team members aren't just code-writing machines. They're creative problem solvers who:
- See technical possibilities a might miss. That "impossible" feature request from sales? Your backend engineer might know of an elegant solution using a new technology.
- Understand the true constraints and opportunities. While you're focused on what users want, they understand what's actually possible—and what's possible might be far more interesting than what's obvious.
- Think systematically about problems. Developers often see patterns and connections across the codebase that can inspire entirely new product directions.
- Have direct experience with user pain points. They're the ones building the solutions and often spot usability issues or technical debt that directly impacts user experience.
When internal innovation drives breakthrough products
Some of the most successful products emerged when product managers listened carefully to their technical teams:
- Slack evolved from an internal communication tool that developers built for themselves. The product team listened when engineers said, "This thing we built is actually better than anything else out there."
- Gmail's innovative features often came from engineers who had ideas about email that went far beyond user requests—like conversation threading and powerful search.
- GitHub succeeded because its founders deeply understood developer workflows and built something that solved problems developers didn't even know they had.
How to develop your "internal ear"
1. Ask dfferent questions Instead of just "Can we build this?" try:
- "What would be technically elegant to build?"
- "What patterns are you seeing in the codebase that suggest new possibilities?"
- "If you could rebuild this from scratch, what would you do differently?"
2. Create innovation time Google's 20% time wasn't just about employee satisfaction—it was about systematically listening to what engineers found interesting and valuable.
3. Include technical voices in product discovery Don't just present finished requirements to your development team. Include them in customer interviews, market research sessions, and strategic planning. Their questions often reveal insights you'd never think to explore.
4. Pay attention to technical debt complaints When developers complain about "technical debt," they're often identifying opportunities for product improvements. That clunky integration they keep griping about? It might be limiting product capabilities you don't even realize.
5. Foster psychological safety Create an environment where technical team members feel comfortable sharing "wild" ideas. The best innovations often start as seemingly impractical suggestions.
The balance is everything
The key insight isn't to choose between customer-driven and development-driven innovation—it's to balance both. Your external ear keeps you building things people want. Your internal ear helps you build things people didn't know they needed.
Great product managers become skilled translators between these two worlds. They can take a customer pain point and work with the development team to find unexpectedly elegant solutions. They can also take a technical insight and connect it to real business value.
Your two-ear challenge
This week, try an experiment: For every hour you spend listening to customers and stakeholders, spend equal time having deep conversations with your development team about possibilities, patterns, and innovations they're seeing.
Ask your engineers: "What's technically possible that we haven't explored yet?" Ask your designers: "What patterns are you noticing that we should pay attention to?" Ask your QA team: "What are you seeing that suggests we could be thinking about this problem differently?"
You might be surprised by what you hear when you start listening with both ears.
The most innovative products emerge at the intersection of customer needs and technical possibilities. As product managers, your job isn't just to hear what customers want—it's to listen carefully to all the voices that can help us build something truly remarkable.
What conversations is your development team trying to have with you? Are you listening?