Four places where the software promise needs an owner

When I became CEO, Nerivane Systems maintained 41 customer-specific product branches. Some supported requirements that our main product did not yet handle. Others preserved decisions whose original commercial rationale was difficult to reconstruct. Engineering wanted consolidation, while account teams feared that a migration programme would turn technical debt into customer dissatisfaction. Both groups were describing a real cost, but they were not yet working from the same record of obligations.

I commissioned a branch-by-branch review covering contract terms, active usage, support effort and the feasible route into supported configurations. We did not announce a single retirement date. Instead, each account received an explicit decision: migrate after a defined capability was available, retain the branch with a named owner, or discuss an orderly end to the relationship. The board accepted that the programme could reduce revenue before it improved our operating position.

The first commercial estimate identified US$9 million of annual recurring revenue attached to the most difficult transitions. We funded migration work and gave account leaders authority to negotiate timing within agreed boundaries. Engineering published the product capabilities needed for each move, while customer teams documented acceptance criteria. We also kept a record of promises that could not be absorbed into the main product without distorting it for other customers.

Over thirty months, twenty-eight deployments moved to supported configurations and four relationships ended at agreed renewal points. Nine branches remained, with owners and future decisions recorded. Annual recurring revenue lost through the four departures was US$2.1 million. The company reduced duplicated release work and could explain the exceptions it still supported. I would change the initial sequencing: we began with technically straightforward branches, but a few commercially sensitive accounts needed earlier discussion even though their engineering work would occur later.

A review of enterprise implementations found that 27% of a defined cohort required a disputed extension before acceptance. Delivery teams described late customer decisions; account teams described product gaps; customers described commitments they believed were already included. The disagreement often began before the project had started, when an attractive proposal left the evidence of completion too open to interpretation.

As chief operating officer, I asked sales, legal, product and delivery leaders to review twelve completed engagements together. We followed each disputed item back to its earliest written description. The exercise showed that a longer statement of work was not necessarily a clearer one. Some documents listed activities in detail without describing the customer task that would demonstrate a satisfactory result. Others assigned a date without recording dependencies on customer data or decisions.

We introduced an acceptance workshop before final commercial approval for larger engagements. Customers and our teams agreed representative scenarios, evidence and the treatment of changes. The workshop added effort before signature and delayed several proposals that sales colleagues expected to close sooner. I accepted that cost and changed the internal reporting so unresolved acceptance questions were visible rather than quietly transferred to delivery after booking.

In the subsequent reviewed cohort, disputed acceptance extensions fell from 27% to 11%. We also recorded a median eleven additional days between proposal and signature for engagements using the workshop. That was a real commercial consequence, not an inconvenience to omit from the result. Delivery teams gained a clearer basis for escalation, and customers could see which of their own decisions were prerequisites. My correction would be to include procurement colleagues earlier. An agreement reached with operational users could still become ambiguous when translated into a different contractual format during the final purchasing process.

In 2023, Nerivane Systems acquired Ostren Workflow, a smaller supplier-workflow software business with US$16 million of annual recurring revenue and 38 engineers. The integration proposal identified opportunities to consolidate tools and release processes quickly. I was concerned that several apparently redundant systems contained operational knowledge about customer configurations, support history and release sequencing that our teams did not yet understand.

The finance team wanted a clear timetable for the planned savings. Product leaders wanted time to observe the acquired system through a complete release cycle. I approved a staged integration that deferred US$1.4 million of anticipated first-year savings and protected the core engineering team from immediate reorganisation. That did not exempt the acquired business from scrutiny. It created a defined period in which we would establish which practices were essential, which could change and which had no continuing justification.

We paired engineers and support colleagues across the two businesses around real customer incidents. The teams documented configuration assumptions, identified fragile release steps and tested migration proposals on a limited set of environments. We retained a small historical support tool until the relevant knowledge had been transferred and verified. Management reviewed evidence of completed transfer rather than the number of documents produced. A written explanation that nobody else could use did not count as integration progress.

Thirty-five of the original thirty-eight engineers remained after eighteen months. We completed the main release-process consolidation without increasing the acquired product's severity-one incident count during that period. I do not attribute retention solely to the integration approach; role opportunities and market conditions also mattered. The company gained a more realistic sequence for change and avoided booking a saving before its operating consequence was understood. I would make the observation period clearer in the acquisition communication. Some colleagues initially interpreted a pause in structural changes as uncertainty about the transaction's purpose.

Our product team developed an automated assistant for extracting and organising supplier-document information. Early demonstrations were persuasive, and the commercial plan assumed a broad release across five document classes. A more representative evaluation showed that two classes performed consistently enough for a controlled workflow, while three produced errors that were harder for users to detect. Output speed was attractive; the cost of verification was less clear.

I asked for a release recommendation based on completed customer work rather than the number of documents processed. The product lead proposed a narrower first release. Sales leadership challenged the effect on planned bookings and argued that prominent review instructions would allow customers to decide how much checking they needed. I considered that insufficient where the nature of an error made it easy to miss. We needed a workflow that kept uncertain outputs visible and required a customer-controlled review step.

We limited the initial release to the two document classes, changed demonstrations to show correction as well as successful extraction and removed language implying broader reliability. The decision deferred US$3.2 million of planned first-year bookings. We funded additional evaluation work and agreed the conditions for considering another class. Those conditions included error characteristics, customer review effort and the consequences of a mistaken output, not only an aggregate accuracy score.

During the controlled rollout, median handling time for the two approved classes fell by 34% after including review and correction. We reported the result for that workflow only. Three other classes remained outside the released scope. The decision helped align the commercial proposition with what the product team could substantiate. If repeating the work, I would involve customer operations staff earlier in designing the evaluation set. Their difficult documents and informal checking practices were more revealing than the clean examples we had initially assembled internally.

As regional vice president, I was asked to approve a multi-country implementation whose first-year contract value would have been US$4.8 million. The customer wanted one commercial agreement covering four operating businesses with different data structures and approval processes. Our proposal assumed that a shared product would make the rollout largely repeatable. The regional delivery team believed the local differences would require substantial work outside the stated scope.

I brought the customer dependencies and delivery estimate into the commercial review before final signature. The account sponsor argued that we could resolve the differences through a strong programme office. That might have been possible, but the proposed price and timetable did not fund the necessary work. I offered a phased agreement beginning with one business and an evidence-based decision about the remaining rollout. The customer preferred a supplier willing to commit to the original scope and timing.

We declined the full contract. I then had to address the consequence inside our own company: the regional plan had assumed the booking, and several colleagues had invested months in the opportunity. We revised the forecast, retained a small paid discovery engagement that the customer still wanted and documented which assumptions had made the original offer attractive. I changed approval requirements for later multi-entity proposals so shared branding could not be treated as evidence of shared operating readiness.

The discovery engagement generated US$260,000 and identified six material process differences across the four businesses. It did not recover the lost booking. Its value was a more accurate account of the work and a commercial relationship that did not begin with a commitment we doubted we could fulfil. I would now surface the local delivery view earlier in qualification. Waiting until a proposal is nearly complete makes a necessary decision more expensive and encourages the team to defend effort already spent rather than examine the remaining obligation.