The illusion of the right solution
Product discussions often look like debates about the best solution. But in reality, they are usually debates about trade-offs.
Teams weigh different approaches, assess their implications, and select the most acceptable option given the constraints and circumstances. What seems like a debate over the best solution is often about which compromise the team is willing to accept.
The pressure for quick solutions
One of the most common trade-offs appears when dealing with urgent customer requests.
There’s usually a quick solution that meets urgent needs. The demand for speed is intense because customers want results immediately.
At the same time, it is worth questioning how urgent these requests really are. The sense of immediacy around customer needs can easily turn into unnecessary pressure on teams.
In many organisations, the perception of urgency also changes over time. There are periods when customer requests dominate the agenda, and teams feel constant pressure to respond quickly. At other times, attention shifts toward broader strategic initiatives or new technological trends. When this happens, requests that once seemed urgent can quickly move to the background.
Providing a quick solution can remove some of that pressure in the short term. But it comes with a cost.
The cost usually appears later, when the functionality needs to be maintained, extended, or generalised for other customers. Once something is released, customers start treating it as a stable capability of the product. Changing it later becomes much harder, especially if adoption has already started, regardless of any early adopter or beta labels.
Sometimes these shortcuts are acceptable. Sometimes they’re not.
As it always happens, transparency helps in those situations. If everyone understands that the solution is temporary and that additional work will be required later, the trade-off can be managed consciously.
In practice, however, these trade-offs are not always discussed explicitly.
Customers propose solutions
Customer requests rarely come as pure descriptions of a problem. They often come as and include a proposed solution as well.
This is natural. Customers understand their needs very well, but they usually have limited visibility into how a product is built internally.
Part of the work of product and engineering teams is to detach from the proposed solution and go back to the underlying problem. Only then can the team determine whether the suggested approach actually makes sense.
Accepting the customer’s proposed solution might still be the right choice. However, it should be a deliberate decision, made after considering the alternatives.
Different perspectives, different priorities
Trade-offs also exist because different roles evaluate success in different ways.
Engineers often focus on stability and long-term maintainability. Product teams often focus on time to market and delivering value quickly. Business and leadership perspectives add another dimension, focusing on revenue and the needs of the most important customers.
Each role optimises for a different outcome.
When these perspectives meet, disagreements are almost inevitable.
In many cases, these disagreements are not really about the right solution, but about which trade-off a team is willing to accept. I explored this dynamic more in a separate note on managing disagreements.
Strong teams recognise this and actively explore alternative solutions instead of assuming that a single perfect answer exists.
Choosing the trade-off
In my experience, it is rare to encounter a product problem with a single solution that everyone immediately agrees on.
Healthy teams understand that there are always multiple ways forward, none of them perfect. Instead of searching for the ideal solution, they try to understand the implications of each option and decide which compromise is acceptable.
Because, in product work, the real question is rarely about what the perfect solution is.
The real question is which trade-off are we willing to accept?