Software Deals Are Like Marriages. Can we Prevent so Many Ending in Divorce?

Have you ever wondered why there’s such a big deal made of the start of a marriage (there’s a whole industry built around engagements and weddings), but there’s almost no fanfare at the end?

Samuel Thompson pointed this out on Greg Isenberg’s podcast. Samuel highlighted that there are lots of products designed for the start (and the big party that goes with it), but there aren’t many products designed for the end of a marriage (even though I assume there are lots of people just as excited to get out of their marriage as they were to get into it).

It dawned on me that this isn’t the only example of start / middle / end asymmetry.

It’s true also of digital transformations.

Software buyers and sellers / vendors optimise for getting to the big day when they both say “I do”.
The courtship phase is often lengthy, polished, well-funded, and obsessively engineered – from the arduous procurement processes, RFP responses, reference architectures, negotiations / discounts, executive sponsorship, Proofs of Concept, and all the way through to the promises of long-term partnerships.

The complexity of the courtship phase is what we refer to as The Buyer – Seller Chasm.

But once the deal is signed, the hype immediately starts to fade. The relationship doesn’t just quietly change. Most software deals are flawed from the outset (unlike most marriages, which hopefully start out from a great footing!).

Then comes the challenges of project delivery / transformation and handover, followed by post-go-live operations.

The reality of living with each other (and the software) for the next 5, 7, or 10 years looks nothing like the engagement party or wedding day.

And when the relationship no longer works – when buyer and/or seller fall out of love with each other – each is left on their own to sort it out.

Interesting….

Like many other industries, there’s an asymmetry that designs obsessively for beginnings and barely provides any support at all for the middle or the end.

What are the ramifications of that for us? Let’s explore.

.

Why Is the Wedding Day the Peak of the Relationship?

In OSS and BSS deals, the wedding day is everything. It’s the point where careers are made, targets are hit, and back-slapping success is declared. Procurement teams optimise for signature. Vendors optimise for closure. Integrators optimise for delivery. Consultants optimise for concluding the match-making process.

The problem is that go-live is treated as an ending, not a beginning.

In reality, the wedding day is the least representative moment of the relationship. It tells us very little about how the relationship will function in the years that follow.

.

Who Actually Owns the Relationship Once the Deal Is Signed?

Before contract signature, ownership is clear. Sales teams lead the Seller side. Executives sponsors lead the Buyer side. The onus is on the Buyer to make the decisions. Everyone knows who is accountable (anyone within the Buyer stakeholder group can simply say “no” and the whole relationship stops).

This changes somewhat during the delivery phase, when shared responsibilities appear. But then after go-live, ownership can really fragment further. Sales / account teams exit. Project / Delivery wraps up. A variety of Operations and other Business Units inherit a complex system, a long contract, and a set of assumptions that they might not have ever even been aware of.

No single party within Buyer or Seller truly owns the health of the relationship.

Maybe the Account Manager (Seller side) and Product Lead (Buyer side) own the functional responsibilities (features, roadmaps, and upgrades, etc). But who owns the relationship? Both organisations do, but more specifically, who within those organisations and who/what as a Buyer+Seller collective?

.

How are Buyer / Seller Relationships Supported?

From a functionality perspective, there are plenty of products and services across the life of the contract. Integrators help to build and customise. HR provides resources. Internal teams build product (Seller side) and use / configure the product (Buyer side).

But I’m not talking about the functionality. I’m wondering who owns the relationship?

Hmmm…..

But still, that’s not quite the point of this article. No, this article is about what support exists to help the buyer and seller with their relationship.

In a marriage, there are Marriage Counsellors and Divorce lawyers to help with the middle and end of a relationship.

Are there any equivalent products or services offered by independent parties to help Buyer and Seller avoid the quiet dissatisfaction that accumulates long before contract renewal or exit is discussed?

.

Why Isn’t the Middle Where Most Innovation Happens?

If you look at where time, money, and frustration are actually spent, it is not at selection or go-live. It is in the middle – managing change, absorbing new demands, and keeping systems alive / relevant despite constant pressure to do more with less.

And yet, this is where innovation investment is thinnest. R&D focuses on new features to win new deals. Tooling focuses on acquisition and deployment. Very little is aimed at improving the lived experience of long-term relationships.

The same is true of relationships through this stage of the life-cycle.

Relationships often age poorly. Not because they were bad decisions, but because they were designed for Day 1, not 5+ years after go-live and/or were never designed or supported to age well at all.

.

Why Don’t We Have ‘Marriage Counsellors’ for Software Relationships?

In human relationships, we accept that long-term success often requires significant effort and/or intervention (where neutral parties help surface issues, realign expectations, and prevent avoidable breakdowns with both parties’ best interests in mind).

In software relationships, does an equivalent role, a “Software marriage counsellor,” exist?

There are few neutral, lifecycle-focused actors whose mandate is relationship health rather than sales, delivery, or renewal leverage is there?

A “software marriage counsellor” appears to be a missing concept.

An independent arbitration entity that focusses on optimising outcomes (relationship continuity, adaptation, and long-term viability) for Buyer and Seller across factors such as:

• Technical issues (architecture, roadmap, capabilities, infra, processes, pain-points, issues, integrations, support, implementation planning, benchmarking / audits, etc)
• Commercial model observations (capex, opex, R&D, investment, etc)
• Operational readiness (templates, processes, etc)
• Executive / strategic alignment (re-framing as businesses evolve and adapt, new situations arise, etc)
• Risk management & mitigation
• Legal / contractual review (balance of power, clauses, exit planning, variations, renewals, renegotiation, sizing/scaling, etc)

OSS/BSS relationships are highly complex throughout all phases of their lifecycle. I’ve observed many over the years and strongly believe in the marriage analogy.

Many software divorces are not caused by bad choices at the start, although they often do start from a flawed footing. Others are caused by years of relationship neglect in the middle. Interestingly, I can’t think of many that have been failures from a technical perspective. Some have failed to deliver to technical expectations, but are still more about the breakdown in relationships.

If carriers and vendors want fewer divorces, the answer is not better weddings. It’s effort and attention on building better marriages. And bringing in better marriage support.