Need vs. Solution

In a world where the customer is always right, the competitiveness is high and the need for client retention is imperative, it’s easy to get lost in the middle of concessions and the fear of saying ‘no’. The problem is that it becomes a trap for the companies that gives custom solutions, mainly when there isn’t enough knowledge about the business rules of the area, depending only and exclusively on the necessities and solutions informed by the client.

The client responsibility is to announce the problem or necessity, but it is not, and it has never been, to define the solution, despite being instinctive. The solution can even be suggested, but never blindly taken by the provider. The responsibility of establishing an appropriate, viable and fair solution lies on the provider. After all, the software belongs to whom?

This sounds almost academic, but it’s not an innovation. So why, when it comes to practice, do we often experience the opposite? The Frankstein-type solutions that degrade projects and don’t meet end-user expectations? Thousands invested, hundreds of people hours and a feature that is never used?

If you have already wondered why something was done in a certain way and the answer was “I do it because the customer asked” or “Because it is so”? Well, these are the main warning signs to identify these types of problems.

The solution responsibility is yours, don’t run away from it. Don’t be afraid of questioning or building a solution along with the client, after all, the expert is you. Unleash doubts, create scenarios and never, never ever, count on with the obvious and trust that something is implied. Make it clear and write it.

Keep in mind that the goal is reaching a clear solution, with all the doubts cleared, examples and scenarios exposed, what will be delivered and as important, also what will not be delivered. Present the same solution, in different ways or points of view so that the understanding is assured. Provide examples.

A good simple structure that I use is to consider the following flow:

Need (what, why) > Solution (how) > Risk (what if)

Thus, we cover the main aspects, making clear to all involved parties the reason of the solution which was provided due to the need. So we can describe all aspects of the solution which will be done clearly for all involved, technical or not. Last but not least, what will be the risks after the solution is delivered, maybe performance problems or changes to the workflow for users, exposing the need for new training, for example.

Think about it, the next time you deliver a solution and the customer simply does not use the functionality because he did not meet expectations or because it does not work as expected “just because that’s what he asked for,” well, maybe he may not give you a second chance.