To me, product management is a constant negotiation.
In a world with finite resources, it is simply not possible to add every feature a stakeholder wants, whether that’s a client, a salesperson, or a CEO.
Even if you could give someone every feature they asked for, this would make for a terrible product, because every product is as much a function of what it does not offer, as what it does.
And so, every feature request and every idea is basically a tradeoff. This is where communication, negotiation, strategy, and creative thinking can intersect.
Identifying the Root Need
Here is how I approach every new feature request:
- How essential is it to the daily needs of a business? Is it a glaringly missing feature, or an edge-case? Have many people been asking for this, or is it the first time I’m hearing about it? (See also, has this person asked for it multiple times? That’s also a start)
- Will it lead to obvious increased revenue or save lots of time?
- How complex is it to implement? Is it a tweak to an existing system? Does it massively affect everything we already have? Or is it a completely standalone new thing (it’s often easier to create than to integrate)?
When exploring the need with a stakeholder, I like to dive deeper than the presented solution – much like a psychological need, there is often a deeper motivation for the request, and often a solution proposed by a non-technical person might not be the simplest or most streamlined solution.
Creative Problem Solving
Once I understand the need, I’ll think creatively about the best solution to the problem. If I’m familiar enough with the stack I can do this myself, other times I may need to consult with engineering.
My guiding principle is this: what solution can we implement that will lead to 80% of the requested solution with 20% of the effort?
Here’s my thinking behind this:
- There are very often “quick wins” that take the least amount of additional effort and get us most of the way towards the required solution.
- The closer you get to “100% solved”, the more work it takes to get there.
The ratio might not always be 80/20, but broadly that is my belief – that you can solve the majority of problems with a disproportionately small amount of changes or features.
I enjoy this creative problem solving stage immensely. It allows me to creatively combine product, UX, and engineering, either myself or by working closely with specialist colleagues to understand the issue and propose solutions.
Negotiating Compromise
Then comes the negotiation. Since I inherently will not able able to completely solve the problem, I need to get the stakeholders on board with said partial solution.
Here’s what I like to do to help with this negotiation stage:
- First, I validate the request. It often uncovers a deeply frustrating current reality that they have to deal with regularly, and I empathize with them.
- I then explain the technical constraints. Even if they are not technical, I still try to explain what is going on under the hood and why it might be difficult to fully solve the problem. I might throw the product under the bus a bit, if it helps, without calling out any individual people. “This system is eight years old and we know it needs an update. When we started using it we weren’t dealing with nearly the amount of scope that we currently are handling.” There is nothing like a shared hatred for an outdated dashboard to unify the masses.
- I present the solution, explaining how I think it could solve most of the issue, and ask for their feedback. I will overtly acknowledge areas where I feel this doesn’t fully address the issue (the remaining 20%).
I believe most people are reasonable, and appreciate even just the validation and the effort you are showing to address their request and needs.
I try to create similar buy in from the engineers:
- First I empathize with the reality of what they are being asked to deal with – so often they are overworked, needing to pivot from something else, modify something back from what they just changed, and I have enough experience in the trenches myself that I can commiserate with them.
- Then I explain the need – I believe that everyone is more motivated when they understand why they are doing what they are doing (it so obvious to me that I don’t think we need an entire book on the subject, Simon Sinek). It can be easy to just give engineers orders about what to build next, but I believe including an explanation into why a feature is needed can be helpful for them as well, both for motivation and for their own creative problem solving skills.
I would argue that buy-in is not something you need to achieve from actual decision makers. Those on the receiving end of the instructions greatly benefit from buy-in as well.
The Spectrum of Solutions
Once the solution has been successfully implemented, you can actually think of the remaining 20% of the issue as a new 100% problem. Here too, there is probably another 80/20 solution that can further address it. Dividing a problem into granular steps like this helps you address the most pressing issues first.
I think a key component in this philosophy is seeing all problems as a spectrum. A problem is rarely “solved” or “not-solved”, it can often be “mostly-solved” or “a little solved”. With that in mind, the question becomes how far on this continuum can I push the solution with the least amount of engineering effort.
I recognize that this philosophy does not always work for all use-cases. In high-stakes situations perfection might need to be the name of the game. But especially in early-stage products or experimental features, getting something out quickly and iterating without bogging down the core system, is often the priority.
