When you’re a product manager building a platform that involves a mix of enterprise B2B and also B2BC products, the number of opinions you receive — whether you want them or not — can be overwhelming.
We don’t always hear directly from end-users, but we do hear from the businesses, or clients, who purchase our products. Often, clients present us with a smattering of feature requests that represent a portion of their end-users’ pain points. These requests also include their own ideas and features they see from competitors. The ideas coming from clients is only a portion of the forces at play. Product teams also face internal pressure from sales, operations and engineering. It’s the job of the product manager to assess all these inputs and find the greatest good.
With a continuous funnel of opinions, how do product teams ensure they prioritize what’s next to work on and not simply react to the latest, or loudest, request?
Product teams who create the most impact do so by understanding the right inputs.
Talk directly to end-users
As a product manager for a fintech company, I talk to a lot of bankers. And bankers, I love you, but I also love your customers (or end-users). It’s one thing to hear a bank tell me “we get lots of requests from our customers about this feature.” It’s another to hear the customer (the person actually using the software) directly explain their pain point and motivations.
A lot of details can be lost when your client (in my scenario, the bank) is translating feature ideas they’ve heard from their customers. It’s important to understand that sometimes what is high priority for your client is not always high priority for the actual end-users of the software.
Do whatever it takes to talk to the actual end-users of your software — remove the middle man and hear the problem described from the user’s own perspective.
This will allow you to build empathy for their situation and have a clear understanding of their pain points without any bias or alternative motivations.
It’s also important to translate your findings from the conversations you’ve had with end-users back to the client. This reinforces the fact that we build products for them (our client), but emphasizes that doing so requires meeting the needs of their end-users.
Get comfortable saying ‘no’
Creating something entirely new means you have to be comfortable saying no. Not only comfortable, but confident. It can take clients quite some time to see your vision and to understand what you’re building. For other clients, they’ll simply think you’re the next version of the product they’ve had for the past five years. As a product team, hold strong and know that it’s okay to say no.
If a feature request doesn’t fit your strategy, don’t give in.
If you build one feature for a VIP client, you’ll build another one for the next VIP who comes along. Before you know it, your entire product will be filled with one-off requests that distract from your vision.
Validating your vision is a topic of its own, but you should have a framework in place that allows you to visually share it with key stakeholders — such as a SWOT, opportunity assessment, or market assessment that confirms market potential.
Saying no to a one-off request should be done in a way that helps the client understand that by saying no, we’re actually helping achieve the long term vision sooner. In other words, don’t just say no — educate your client and position why this move will help towards the long term strategy.
In product management, and in shipping valuable products, the goal isn’t to please everyone… it’s to improve user’s lives through technology.
In order to do that, sometimes you have to say no and in good time deliver on your promise of a better way.
Ignore the feature chase
If you’re creating a new wave of innovation, chances are that your product doesn’t have all the features as the competition. If it did, you’re probably not creating a new wave but riding someone else’s.
If you’re truly innovating, your product should have features that don’t exist anywhere else. Features that solve real problems — technology that improves people’s lives in new ways. Don’t just ship ideas to check a box, ship meaningful features that solve real problems.
The ideas presented above are nothing new. They’re just a few practices our team tries to uphold and things we’ve witnessed successful product teams do.
Product teams: use this guide as a starting point. There’s plenty of great advice on the web about shipping meaningful products. When you’re feeling lost, remind yourself of these simple principles. Get motivated, be inspired and build solutions that attract customers who want to join you on the journey. Build partnerships for the long haul.
Clients: if you understand the vision of your vendor, go all in. Help them help you. Connect the product team to your end-users. Present your ideas but know when to yield (and yes, this takes trust!). Make it clear that you’re looking for a partnership, not just a vendor. Collaborate, share and keep reminding us (product teams) that our goal is the same — to build something great!