Always Be Closing – or Not

It is relatively easy to sell a product. You may make a profit or not, depending on variety of factors, but the approach is pretty straightforward. All it takes is to find a pain, figure out a way to make it go away and then see whether you were right in both of these. Market will mercilessly validate all the factors you accounted for, how you did it, and what you missed. It was the same for IT world, with only minor changes being the projects, resulting in approach that could get the catchy name of “product development as a service”.

Then, the Agile came – and things started to change.

When you start analysing the approach, a shocking discovery is made. Apparently, nobody – ever, in a history of mankind – needed any software. That’s it, fellow programmers. Nobody needs your creations. Likewise, nobody needs cell phones. Or spoons.

Now you might think I’m going over the edge, but bear with me for a moment. Why would I ever need a spoon? All I want is to eat some soup, in reasonable time (which excludes forks), without losing my dignity, and with my clothes unstained (these two conditions exclude going, well, doggie style). If you give me some other tool to get there – I’m all in.

People don’t give a damn about your project, product, or service, for that matter. They do care about what it can do for them. I can’t recall where was it when I first heard the phrase “Nobody needs a drill, but a hole is probably useful”. That’s what every business is actually about.

Trying to sell projects the old way, we’re quite likely to miss it.

It’s deceptively easy to just deconstruct whatever client tells us they need into set of user stories. Following that, you can go all Agile, inspect, verify, and adapt following every sprint. As always, there are several factors affecting the odds of your success, but the sale is made. It’s closed.

(You can also fake Agile and just iteratively deliver the initial scope. That’s actually quite popular. I dare to say that most software development houses bragging to be “so Agile” are doing just that. But that’s another story.)

Then, you can go another way. Work with the client, engaging them to discover the actual need. At one moment, you’re both probably realise that there’s more than one way to address it. The initial request may not be it.

You’re delivering value before your people create any software. Now, that’s building actual trusting relationship. That’s Agile at its core.

While you might expect some more epic propaganda here, just a bit of a warning.

It is possible, you don’t want this to happen. It might turn out, that your client, thanks to your presales engagement, realises they don’t really need the project you want to win. Or, for that matter, any project at all. It is great for them, obviously, however… What about you?

Can you afford to invest not winning some project in order to build a relationship?

There are two factors to consider here.

First, while the above scenario is possible, it’s still unlikely. Some project will still be delivered, a better one. Also, clients tend to remember and appreciate such approach. This will increase your odds of winning some other project later on. And another one. And some more.

Second, it would be good to ask yourself whether you’re in the game for a long run or not. Cooperation built on relationship will stay profitable for years. You might be tempted to win some quick money without a hassle. And in your business reality, it may actually make sense. When times are thin, that’s what we all do, we focus on survival alone. Once things get better though, I highly recommend you to reconsider.

Just don’t be dogmatic about anything, as dogmatic usually equals stupid.

Opinions are my own and not the views of my employers, customers, or clients.

Failed Agile Transformations ebook

Learn how to spot, avoid, and FIX them!