Product management is as much about what you don’t build as it is about what you do build.
There are hundreds of good ideas, great ones even. They come from you, from your stakeholders, from your clients. Some of these ideas will be contradictory. Some will have dependencies. Some will seem so obvious they don’t even need to be debated. How do you weed out the ones that aren’t top priority, and that will never be worth doing?
Building a defensible business case, identifying alternatives, and sharing the journey with colleagues are key to identifying and handling situations where product turns out not to be the right solution to a problem.
Start with the Business Case
“We need to integrate with this API.”
I had heard it countless times in my first year at a company, but it just never sat right with me. I delayed the work, prioritizing other features. I asked what stakeholders thought the API was going to get them. I asked for the program strategy that this technology was supposed to allow to scale. It didn’t add up.
Regardless of your thoughts on whether the PM is the CEO of the product, spend the time to build the use case. Address things like expected impact on revenue or margins head-on and always ground the conversation in fact.
This was a situation with a real business need – reduce cost for one part of our service offering in order to stay competitive. The executive sponsor was charismatic and a vocal proponent of the API and a short list of other requests she believed would unlock her team’s ability to scale. Everyone took this as a given because it had been talked about for so long.
I started to unpack this challenge by learning how the team currently did their jobs, and how they worked around not having these features. I asked how long they spent on each part of the process. It was only after tough questions to the executive sponsor about labor cost and addressable market size that we started to see the full picture. There were challenges to scale, all right, but they weren’t exclusively (or even primarily) due to a lack of technology.
There were easy wins if we went back to negotiate with vendors. There was process optimization possible. Most of all, we realized we couldn’t accurately predict the market size.
Through the discovery process, I learned that the team thought API integration meant they wouldn’t ever have to log into that other app. In our current world, it didn’t. Our app currently wasn’t collecting almost any of the information we’d need to send to the third party via their API in order to truly automate our use of that system. The engineering effort to collect all the necessary data was prohibitively high.The unclear market size combined with a high level of effort made this project a no-go. So what do you do when you’re telling stakeholders that they’re not going to get their wishlist, now or ever? That the business case just isn’t there?
Identify Alternatives
When we looked at the challenge without expecting a technical solution, we found that the easiest solution to scale was to throw people at the problem. Pro tip: sometimes that IS an acceptable solution. Sometimes people are cheaper than the cost to build and maintain a product, especially in an early-stage, high-growth startup. It’s not a forever solution, but when you’re testing new ideas and gauging demand, it’s likely cheaper and faster to do with people than product.
Other solutions like renegotiating with vendors and building trust with our internal team about what parts of their process they could use our app for, and exactly how it worked, were tech-free ways we could move the needle on this service.
When you’re killing an idea, especially a cherished one, bring alternatives. You’ve gotten to know their processes, pain points, and opportunities pretty well in an attempt to prove the business case. As a product manager, you see how and where to optimize through technology. Shift your focus and help your stakeholders see how and where they can optimize using what they have.
Research third party tools that already accomplish what they need, if you can’t build it for them. Look for something on the wishlist that impacts a large enough group of users to be worth addressing, and help the team get an incremental lift by solving that problem instead of the original ask.
“Here’s what I think we could do…” is a powerful way to reshape the conversation.
Share the Journey
It’s quite easy to focus only on the outcome as a product manager. We forget about the twists and turns it took to get to a decision or to the end product you see in front of you. We share data, success metrics, and next steps, but we rarely take people through the journey that got us here.
Doing so allows you to acknowledge the ideas and input from team members that didn’t make the roadmap. I like to share these in a public setting like a quarterly all hands meeting…it gives you a chance to highlight the work that your team is doing, but also the things that didn’t make the cut, especially when they were your experiments. This reinforces to the company at large that it’s ok, good even, to throw out some proposals.
To build the story, focus on 3 important things:
-
The problem and proposed solution
-
The discovery work and what it revealed
-
What you did (or didn’t do) as a result
Humanize the journey and you’ll have a lot more people willing to partner with you in the future.
***
It takes courage to throw out an idea. Evaluating the business case for a product and being willing to let go of pet projects is a skill the entire organization must develop if you are to stay lean and show outsized results from your engineering team.
When you find those opportunities to change course into something with more potential, celebrate it. Partner with the business to identify alternative solutions to solve their very real problems. Share the learnings with the company. Reinforce your shared goals and express gratitude for the flexibility of the sponsoring team in keeping the product and engineering teams focused on the most valuable things for the company.
And don’t be afraid to start with the tough questions.
This article originally appeared on Product Coalition.
