How to navigate feature obligations in contracts
How to navigate feature obligations in contracts
Feature obligations in contracts refer to specific functionalities or enhancements that software vendors commit to deliver within a certain timeframe, as part of a contractual agreement with their customer. These stipulations are particularly common in agreements with enterprise customers, who often have unique and complex requirements for the software solutions they procure, especially from younger startups whose products might not be mature enough to meet their demands
Enterprise customers may request these obligations to ensure that the software will meet their evolving business needs, comply with industry regulations, or integrate seamlessly with their existing IT infrastructure. For software vendors, these feature obligations represent a promise to tailor their offerings, or adjust their roadmap, to the needs of these customers, often necessitating a close partnership and clear communication channels to manage expectations and deliver on these commitments effectively.
These contracts can sometimes impose a strict timeline on the vendor, oftentimes with ramifications if the vendor fails to deliver. Hence, they can cause a lot of stress and angst within a software development organization. In today’s post I will cover how to navigate the vendor-customer relationship in which contractual obligations are set by the customer on the vendor.
Understand the cost/benefit tradeoff
The first step a vendor must do is estimate the time and resources needed to deliver on these requests. The contract will most likely require a timeline delivery of features, hence, as a vendor, you will have to estimate time, and therefore development effort and cost.
Once you have the cost, you can then assess if it’s worth doing, or the opportunity cost of you doing this work versus other work that you had prioritized. This presumes that these features will require you to divert resources and therefore shift roadmap priorities in favor of working on the features the customer requires. This has a cost - an opportunity cost - and therefore needs to be evaluated against the benefit of winning this customer’s business.
A very simple approach is to do the work if the benefit > cost. In this case both the benefit and cost can be modeled in dollar terms. If you win the customer you are awarded $100 in revenue and the cost of winning this customer is $50, hence do it. However, this approach is too simplistic. Consider the case of you wanting to win a large and highly strategic customer. This customer can act as a reference for your product and company within their peers, thereby helping you win more opportunities. Additionally, this customer might initially commit to a small purchase, tie that to a commitment of features from you and increase their spend in outer years, meaning their LTV is far greater than the cost to deliver what they need now.
Because this cost-benefit analysis can be tricky to do, it is not uncommon for sales opportunities that have large feature obligations tied to them to require explicit approval from the heads of Product, Engineering, Sales and even the CFO or CEO.
Have a partner to work with
I can’t stress how important this point is. When you are negotiating on the opportunity terms, including which features to build and when, you are likely negotiating with the procurement department and perhaps the customer’s leadership team. These individuals will not be the ones that ultimately use your product. They cannot help you scope and refine the features that were stipulated in the contract. Therefore, you must identify a partner on the customer side whom you will work with post-sales to scope, refine and deliver on these features. You want someone(s) who will be hands-on with your product.
I’ve had a few instances where I alerted a customer that a feature they requested is available to them only to be told that they never needed this feature to being with. The people who added these features in the contract, aren’t the ones who use the product and they might add superfluous ones.
Don’t be surprised if requirements change
This point is related to the one above and reinforces it. The features that are stipulated in the contract will change. Don’t be surprised when this happens, and in fact you should expect it. A customer evaluating your product has a relatively limited understanding of how it operates and fits within her environment. That understanding will evolve and change as they start using your products. Features that are absolute must-haves could diminish in priority or scope and vice versa.
Not only are these changes expected but they are welcome - up to a point. A change, be it in scope and priorities, reduces the risk of the customer using any adverse clauses like penalties of the option to terminate the contract. Change, means that whatever was written in the contract is no longer “dogma”.
Note, that significant changes, perhaps by expanding the scope or introducing new large feature requests, should be evaluated and the cost-benefit tradeoff assessed. You want to be flexible and open to change, but up to a point.
Understand that risk is on both sides
This is also a point that I have found to be underestimated. It’s easy to see how the vendor assumes a lot of risk with these contractual obligations. The risk, though, is on both sides.
For the vendor, committing to specific features within a rigid timeframe can introduce significant risks, especially if the scope of work is not clearly defined or if unexpected technical challenges arise. The pressure to deliver may lead to compromises in quality and can strain the vendor's resources, leading to burnout among team members and possibly affecting other contractual obligations.
On the other side, customers face the risk of basing their operational or strategic plans on the timely delivery of these features, only to encounter delays or receive a product that doesn't fully meet their needs. This dependency can result in operational disruptions, lost opportunities, and financial losses, especially if the software is critical to the customer's business processes. The biggest risk thought tends to be on the decision maker. Someone on the customer side took a risk on the vendor - i.e. you - being able to deliver on these features. That person is at risk of damaging their reputation or even losing their job if the vendor doesn’t deliver.
Having gone through many of these interactions, I know how stressful they can be. In my experience the best manner to navigate them through a partnership and collaborative approach. Treating each other as partners rather than mere transactional participants fosters an environment of collaboration, open communication, and mutual respect. This partnership allows both parties to more fluidly address and adapt to changing requirements, reducing the inherent risks associated with rigid contractual obligations and the stress of meeting hard deadlines. By working together in a partnership, both sides can develop a more flexible framework for the project, one that accommodates adjustments and refinements as needed, based on real-world feedback and evolving business needs.
This not only minimizes the pressure on both sides but also enhances the likelihood of successful, timely delivery of features that truly meet the customer’s needs, ensuring that the relationship is off to a good and productive start.