Choose what the product should keep owning

In February 2024, our workflow product existed as sixteen runnable code branches: one common line and fifteen client-specific forks. Some differences represented contractual workflows that the common product could not yet support. Others survived because copying a branch had once been easier than agreeing a configurable behaviour. Every shared correction required engineers to establish which versions needed the work and how each would be examined. Sales colleagues valued the apparent freedom to promise a separate version; product engineering carried the continuing cost.

I proposed a six-month programme to consolidate ten forks into the common line while retaining five with substantiated differences. A complete consolidation would have created a simpler diagram, but it would also have forced unsuitable workflows on those five clients. Keeping all sixteen avoided a difficult commercial discussion and continued the repeated engineering work. I chose a smaller common product with explicit variation points, supported by account-by-account agreement on what would change.

The programme cost CNY 8.4 million. Product, delivery and account owners reviewed each candidate with its client before migration. By August, the product had six runnable branches: the common line and five retained specialist forks. A configuration choice in the common product did not remove the need to examine the resulting behaviour; it changed where that examination was maintained. We kept the five specialist owners and their support obligations visible in the product plan.

For the same monthly correction-and-regression activity, recorded engineering effort moved from 460 person-hours in the pre-programme reference month to 310 in the first stable month after consolidation. Those two observations helped us inspect the direction of the change; they were not a controlled study or an annual labour saving. No employees were removed on that basis, and the consolidation cost remained in the investment account.

The useful result was a product whose common and exceptional work could be discussed honestly. I would begin the client variation review earlier next time, before architectural sketches have made a preferred common behaviour feel inevitable. Engineers need a commercial explanation for a difference before deciding whether it belongs in configuration, a separate extension or a continuing fork.

In November 2024, a document-assistance prototype looked cheaper when reported as expenditure per model response. That denominator counted useful drafts, unusable drafts and answers that a reviewer would have to rebuild. The product team wanted to select the cheaper route quickly. I asked for a comparison at the level of work a user could actually accept, while keeping the experiment narrow enough to explain.

We assembled a fixed set of 1,000 permitted test requests with representative source documents. Each route produced one answer per request. Before comparing them, subject reviewers agreed criteria for factual support, required fields and an explicit refusal when the supplied material was insufficient. The reviewers did not see which route had produced an answer. The set and criteria remained unchanged across the two runs; no client document was made available for a different purpose merely because the experiment was useful.

The existing route incurred CNY 2,240 of measured inference charges and produced 800 accepted answers. The proposed routing approach incurred CNY 2,100 and produced 875 accepted answers. Dividing the full charge by accepted outputs gave CNY 2.80 and CNY 2.40 respectively. We reported all four underlying numbers. The lower figure did not include reviewer time, development expenditure or the cost of later operating support, and the 125 unaccepted outputs in the second run did not disappear from the report.

I supported a limited product trial rather than broad adoption. The commercial sponsor wanted to extrapolate the observed cost to every document workflow. I declined that forecast because the tested set represented one task, and the routing choices had been developed with knowledge of its requirements. The six-week evaluation and implementation work cost CNY 1.9 million, a separate investment from the measured inference charges.

The trial made a useful unit of comparison available without claiming general model superiority. A different mix of requests, longer sources or changed reviewer criteria could reverse the result. Next time I would reserve a separate, unseen evaluation set before engineering begins. Keeping the development and final evaluation populations distinct would provide stronger evidence than repeating a familiar set, even when every calculation within that set is correct.

In April 2025, an industrial inspection application sent every image to a central service before presenting an advisory classification to the operator. The application served forty-eight stations across two client sites. Its output helped people examine a part; it did not operate a machine interlock or decide whether a production line was safe. The central design made model maintenance straightforward but made the operator's response depend on the network round trip.

I recommended a split design: local inference and a recent approved reference package at each station, with central distribution, monitoring and later synchronisation. The infrastructure team preferred one central operating surface. Delivery leaders worried about maintaining many local installations. I accepted those additional obligations because the interaction needed a prompt local response, then limited the local component to the decision support that actually required it. Reporting and model distribution remained central.

The eight-week implementation cost CNY 4.8 million. In a replay of the same 30,000 permitted test images on the defined station hardware, the 95 th-percentile response interval fell from 180 milliseconds through the central path to 42 milliseconds locally. Both measurements used the same start and end points: submitting the image and receiving the advisory classification. They did not measure an operator's inspection time, manufacturing throughput or the correctness of the classification.

During a separate ninety-second network interruption rehearsal, local assistance continued with the last approved package while its activity records waited for synchronisation. We showed the package version and disconnected state to the operator. Continuing to produce a result was not permission to use an indefinitely old package; the operating owner set the allowed disconnected period and the response when that period ended. The client retained authority over the underlying manufacturing process.

I considered the result evidence for that particular division of work, not an argument to move every application to the edge. Next time I would bring local package maintenance and replacement hardware into the first design workshop. A latency comparison can draw attention away from the support work created by multiplying installations, and that work belongs in the original choice.

In October 2025, delivery teams proposed fourteen components from earlier client engagements for a common product library. The technical case appeared attractive: the components solved problems likely to recur. The difficult question was whether the company was entitled to reuse each implementation and whether client-specific information had become embedded in it. The engineering team could describe the code but could not settle the contractual position by itself.

I asked account owners and authorised legal colleagues to review the relevant agreements and provenance before product adoption. A delivery sponsor argued that an internal library was less consequential than selling a component separately. I did not accept that as sufficient authority. The alternative of rebuilding all fourteen would have avoided some dependency on earlier implementations but consumed scarce engineering effort and still required a clear specification of what could be carried forward.

Seven weeks of review and preparation cost CNY 2.6 million. Nine components were approved for the stated shared-product use after the responsible reviewers completed their work; five remained outside the library because the necessary permission or separation had not been established. Approval concerned the defined use and implementation, not a universal right to reuse anything learned on the engagement. We retained the agreement references and the restrictions with each accepted component.

Product teams subsequently selected seven of the nine approved components for three named internal delivery programmes. Two were available but did not fit those programmes. That distinction mattered: legal clearance and technical availability did not themselves establish adoption or commercial value. We did not count the five restricted components as product assets, and we did not infer revenue from the seven selections.

The decision gave engineers a usable route to reuse without turning their technical assessment into a legal conclusion. It also exposed why provenance should be captured while an engagement is active, when its decisions are easier to reconstruct. If I repeated the programme, I would put the prospective reuse discussion into the original engagement design and agreement review. A later library exercise is an expensive place to discover that a useful component cannot responsibly travel beyond its first client.

In February 2026, we considered building an internal scheduling capability for a new enterprise product. The initial plan assigned eight engineers for nine months, or seventy-two planned engineer-months, before allowing for continuing maintenance. The team was capable of building it. My concern was whether owning that particular implementation would distinguish our product enough to justify the attention it would consume.

I compared the proposed build with a purchased component that met the agreed functional and operating requirements in a controlled assessment. Engineering leaders preferred full control of the code. Product colleagues needed the surrounding domain workflows sooner. I recommended purchase with an explicit integration boundary and an exit exercise, while retaining our own definition of the product behaviour. The supplier would provide a component; it would not become the owner of the product's priorities.

The selected arrangement carried CNY 3 million in annual licence cost and CNY 2.4 million for the four-month integration programme. Four engineers performed that integration, representing sixteen planned engineer-months. The other four from the original proposed team worked on the product's domain workflows. I did not present the difference between seventy-two and sixteen as a cash saving: the people remained employed, the purchased route added recurring charges, and the alternatives had different schedules and continuing obligations.

By June, the defined integration was complete and the team had demonstrated export and re-import of the scheduling state in its exit rehearsal. That exercise reduced one uncertainty about changing the component later; it did not prove that switching supplier would be immediate or inexpensive. The product retained monitoring, support and renewal responsibilities. Commercial owners approved the licence arrangement, and the investment account showed both initial and recurring expenditure.

The choice preserved engineering attention for work we believed customers would value more directly. It remained a decision to revisit as product needs and supplier terms changed. Next time I would compare the two options using a three-year ownership account from the outset, rather than allowing the first build estimate and first licence quotation to frame the discussion. A sensible first-year choice needs a visible account of what it asks the company to keep paying and maintaining.