Customer collaboration over contract negotiation

The Problem

You may have already recognized the title of this article. It's one of the four statements in the Agile Manifesto. What it means is that we need to work together with the customer in developing the right product that will fulfill the right need. In theory, this should bring more value than contract negotiation. By including the customer in the development of the product, you ensure you get early feedback on what you are building and also avoid situations like ambiguous requirements, solutions that do not solve the problem, late changes in the product, change request negotiation, or contract renegotiation.

Let's also not forget the footnote of the Agile Manifesto: "while there is value in the items on the right, we value the items on the left more." That is to say that there is some value in having a contract. You need some rules of engagement. You need some guidelines on what, when, and how much. But according to Agile, these should be generic stipulations that would not hinder the collaboration between the customer and the supplier.

In theory, all of the above sounds really good, but let's take these principles to the real world. Let me first take the perspective of the customer. I have a problem that needs a solution. After some research, I find that there is no "off-the-shelf" solution available, and thus I need to create a custom solution for my problem. But I don't have the skills in my company, and thus I need to find a supplier that is able to build it for me. And now here comes the big question: How do I pick the supplier? I have no relationship with any of them. I ask for offers from multiple suppliers, and I need to choose. But the quality and service during the development may differ from one supplier to another. Moreover, I have heard from other friends of mine that they spent small fortunes on custom products, and in the end they received the products with very high delays, or in some cases they have never received the product and stopped the relationship with the supplier. This is why I also have some trust issues, and it's a pain in choosing the "right" supplier.

At the other end of the spectrum, let's imagine that we are the supplier, and we have a bunch of employees that need to be paid every month. I need to make sure I have projects in the pipeline for them. But customers don't like to be kept in a pipeline. They want everything, and they want it yesterday. At the same time, I have met a lot of companies that want big projects but have budgets well below the expectations. They also have the impression I am stealing from them and challenge every estimation. They also have trust issues, and I have also developed trust issues that the customers might not be able to carry out projects until release or post-release maintenance. I am trying to push Agile principles and discuss with the customers about developing together, but more often than not they are not willing to put in the effort of having a dedicated representative for feedback and validation during development. Also, they want fixed-price projects instead of pay-as-you-go because they want to know beforehand the cost of the product. I completely understand their point of view, but, man, I wish they would at least try to understand mine also. I just wish I would find the "right" customer.

The "Bullshit" Solution:

Given the lack of trust between both parties, they act as if they are enemies instead of partners. The customer is trying to hide from the supplier the budgets and the plans that they have. The supplier is trying to find the right price for the fixed budget project by mitigating two opposing forces: the willingness to pay of the customer vs. the need to feed his employees. The result is an offer that is compared with many other offers from other suppliers, offers that might be misleading because they do not completely cover communication, services, collaboration, level of quality, and many others.

In the end, for the customers, it is a trial and error until they find the right supplier, and it very often happens that the customer gives up after several failed relationships with several suppliers. The lack of experience and know-how is a big risk for in-house development, and the project has very little chance of success.

The supplier is also frustrated about the lack of trust from the customers and, pushed by the market, gives unrealistic estimations of cost and time, hopes to "hook" the customer in working with him, and after the project begins gradually reveals the shortcomings of his offer. By this point, the customer's lack of trust deepens, and the relationship is compromised. Instead of working together, they end up arguing about every little thing in an endless downward spiral of frustration.

The "No Bullshit" Solution:

You may have noticed how many times the phrase "lack of trust" was mentioned in the lines above. This is the key. We are not just building products. Before we can even conceive of building a product, we need to start building a relationship.

The first step is in the offer. Stand your ground on your estimations and prices. Be the best at what you do, and the customers will refer you before you even know it. Make sure your offer also includes the services you offer besides the product. The empathy, the active listening, the understanding of the pain points, the going the extra mile—all these activities should be part of your tool belt as a product manager. And when you go with a pitch to that customer, take with you the passion of building the product for their needs. I remember my first pitch. At some point during the slide deck, I stopped and responded to one of their questions with, "I was an engineer before being a sales guy." They felt it, and I am sure that weighed in the decision of choosing a supplier.

Now let's assume you got the project. You are the chosen one. Even if you bang your head in the beginning by the lack of trust from the customer, do remember that relationships take time to be built. There are many traits you need to show in order to build it, like transparency, openness, reliability, availability, understanding, and many more. But the best way to earn trust is to make yourself vulnerable. Remember that when you have your weekly reporting meeting to the client, you are speaking to other human beings. Each one of them is beautiful in his own way, and each one of them has its quirks. It's your job as a product manager to find out the beauty and quirks of each one of those people you interact with and show your own beauty and quirks to them. It's okay to be human. It's okay to make mistakes as long as you own them and do your best to fix them. It's okay to not know everything and ask your own questions about their business in order to fulfill their needs.

And week after week, all that small talk about your kids and their kids getting the flu or going to little league creates a bond. And that bond becomes confidence. And that confidence becomes reliability. And that reliability becomes trust.

There is no fast way of achieving this. There is no magic bullet to get people to do business with you and trust you. So cut the crap, lose the hard shell we usually wear to protect our feelings and the cape of fear of being vulnerable, and start carrying out genuine and meaningful conversations with active listening.

Only after you have started building trust can you actually build a product together the way the Agile principle intended in the first place. Because trust replaces contract negotiation, and you are left with customer collaboration. This is the only way those "gentlemen's agreements" work and have value. When both parties in that collaboration are gentlemen.