Requirement Analyses Suck

We feel nauseous at Upsales when someone says “requirement analysis" or “preliminary study". I mean those ballooning excel spreadsheets some person who never worked in sales or in a market function has tinkered with for several weeks. 

 

You recognize these reports as they are stacked with columns of anxiety-enhancing words like: document layout requirements, regrade requirements, system modifications, physical environment, pseudo requirements, and so on ad infinitum. 

 

We have come to the conclusion that spending too much time on writing these specs doesn’t really lead to better decisions or implementations. (Even though we also see good requirement analyses where the specs are to the point and leave out redundancies.)

 

What's the problem?

 

It’s very much like you cannot learn to play soccer through analyzing requirements. You have to start playing to actually learn the game.

 

It’s when you start using a complex software product (at least if it has proven itself in the market place with hundreds of customers over the years) that you start see what exactly you will need from the product and how to go about it. 

 

You need to be practical and get ready for takeoff. This is especially true for complex sales and complex buying of established products. 

 

Think pilot instead.

 

In our industry, there is a solution that reduces the customer's job with requirement specifications at zero and it's a pilot. 

 

We drew this conclusion by looking at which of our new sales processes worked the best. We noticed that the pilots were almost always succeeding from day one. The sales process that proceeded into a pilot (free for the customer) has always felt the best for both parties. Suddenly there is respect from both sides and a smooth opening for everyone.

 

Also, without a pilot project, it may be difficult for sellers and buyers to predict exactly what will happen during the implementation of a complex, but proven, product. 

 

After long negotiations both seller and buyer naturally wants to get started and it easily feels academic to deep dive into every possible detail. “Let’s just do it instead.” With the outcome that the customer finds out a small new function or issue that the seller could not possibly foresee or missed explaining. And it’s not clear if it is in the contract because it would have taken a month to write the contract to take every possible scenario in to account. 

 

All that vanishes like magic with a pilot. It's when testing the product you come to see exactly what you want from it.

 

Later, the customer is up and running when signing. We get rid of surprises popping up during the implementation phase.

 

Most clients who start a pilot will carry on to become customers. It’s a clear win-win. The pilot is favoured by everyone. 

 

So we adjusted our whole sales process around it. Now the only thing that is recognized as a business opportunity in our pipeline, is the pilot.

 

We started by modelling a team member to a sales engineer. His task is to support the sales by making the pilot happen. 

 

Our sales engineer does not give up until everything is in place and works well. He can also be demanding on customers. It comes with the business card. 

 

This seems like a self-evident process, but it has taken us several years of trial and error to find a sales process in three steps. 

 

  1. It begins with a discovery call. Often a 30 minute meeting (on the web or in a meeting) where we demonstrate the product. During that meeting we also address the deal breakers: for example, we have the same price for all customers as we think it’s fair for everyone. There must also be a product fit and time and intent for a pilot. 
  2. In the next meeting, someone from the management of the client has to join in. We refuse to demonstrate to a person whose sole job is to evaluate multiple suppliers. 
  3. After that workshop, we set up a pilot, an implementation of the system free of charge.

 

This leads to efficiency for our sellers to focus on finding new discovery calls and workshops. The sales engineer that runs the entire pilot. While, the sellers focus on new sales solely. 

 

The customer also prefer the pilot project because there are no sellers in the picture suggesting to go ahead with the buy. The focus is on helping customers evaluate and implement the parts needed. Get the client started and comfortable behind the wheel. 

We invest a lot of work and time in a pilot. So we only do them with committed clients. 

 

Rule number one: If it’s a customer we should not work with, then we don’t do it. 

 

Rule number two: When feeling that transparency between the customer and us is missing, we are out of the game early. It may be that the customer basically has another first choice but wants a last comparison with other suppliers. 

 

In the final analysis the uselessness of the requirement specifications was one of the triggers that helped us come up with the idea to align our entire sales process around the pilot. So we made use of the useless specs anyways.

 

We now think that the market has become smarter, more pragmatic, and that requirement specifications are more rarely used for established products for us and the customers we work with - it just makes sense.