Sales and Engineering departments – the broken promises

Sales teams require flexibility to close deals in certain setups, especially when an organization is using Business to Business model. In software industry, this flexibility sometimes means promising a new feature at the time of closing a deal. When these promises are not managed properly, they often turn into a never-ending list of unrealistic deadlines and the engineering teams often struggle to keep up with them. In this article, we look at how engineering and sales departments can work together to manage customer expectations and avoid hurting the company’s reputation in the market. 

Why the broken promises?

Time is money 

The best products cannot survive in any market without a good sales team. And a good sales team need its tools to close better deals. One important factor in closing any deal is to act fast. For instance, when a customer insists on having a certain new feature in the product before closing a deal, the sales team needs to validate the request by reaching out to the product team. This is a time-consuming process. 

An attempt to shorten the process 

To speed up the process, granting access to product backlog might appear as a good attempt at providing transparency into what is in the pipeline. This information can be helpful for the sales teams since they can instantly validate the customers new requested features against the upcoming items in the backlog without reaching out to the product team every time.  

Challenges in sharing product backlogs 

Providing visibility into future product features has few challenges. For instance, the development backlog items are often too noisy for the sales teams to use. There can be many distractions in the list, from one-liner user stories to very detailed technical specifications. Looking for that one feature request can be a hectic task. Even when the backlog is nicely tagged and filtered, finding a feature in the list that matches the exact customer’s needs is very unlikely. Additionally, the product backlog keeps changing to adjust itself with product needs like regulatory requirements and technical debts. The situation can get worse when an exact delivery date is requested by a customer, which they often do. 

The prerequisites 

To solve the challenges mentioned earlier, we need to focus on few key items first 

  1. Build a communication channel between sales and engineering departments. The product team, whether as a part of the engineering department or not, needs to get input from the sales teams. Conducting a regular meeting to get the list of customers feature requests that raised in the sales sessions is a great starting point. To better understand the customers’ needs, the “why” questions must be answered.  
  1. Familiarize the sales teams with the products potential. It sounds very obvious, but the sales teams need to be familiar with the products in the organization. This can be beneficial when the product allows certain customizations without really changing any code. 
  1. Explain the software delivery processes being used in engineering department. It is extremely important to go beyond the engineering department when working in an agile setup and explain the software development life cycle to all who interact with the engineering teams, including the product teams. In this case, the sales department is no exception. The sales teams need to understand software is a living creature that constantly changes to survive and some of these changes are unpredictable. Complying with the new regulatory requirements, software maintenance and technical debts are just few examples to name. 

Rely on the past investments 

Instead of building expectations around the upcoming features by looking at the product backlog, which can change at any time, we can focus on what has already been done so far. Showing the development teams effort in an abstract manner shows the dedication of the company in any of the upcoming features. This solution limits the flexibility required by the sales teams to close a deal when a customer requests for a certain feature to be in the product prior to signing the deal. This limitation, however, helps us to always stay true to our promises and build a better reputation in the market.  

A simple example of showing the company’s effort in different features

A good example 

An example of this strategy is used by a big company called Blizzard. They often use abstract words like Soon™️ to communicate the effort put into their products without making any promises or providing any exact date. The expectation of how long it takes for a product to be delivered is built by the customers themselves and not our organization. In this case, the customers rely on the company’s past deliveries to make sense of what Soon™️ means for any of their products. 

Relying on the past delivery data and using abstraction in our estimation can help us avoid making unachievable promises in the first place. While this method is often well understood by the engineering teams, using story points and team velocities in Scrum for example, the rest of the organization who interact with engineering department might not be fully aware of its benefits. It is engineering department responsibility to help others teams speak the same language. 

%d bloggers like this: