The use cases I chose to serve, and the obligations I retained

The storage proposal at Norvelen Power began with an appealing specification: 10 MW power and 20 MWh nominal energy capacity. Commercial colleagues wanted a common product family for eight customer operating profiles. The difficulty appeared when we described the required service instead of the equipment. Five profiles involved a two-hour peak window; three required six hours. The same rating could not simply be placed beneath all eight customer accounts and allowed to imply the same service.

Owen Carvelen argued for keeping the full opportunity together while engineering developed the options. I understood the commercial reasoning. A broader family could attract more attention and keep all eight discussions open. My concern was that one development proposition would begin to carry two different duration expectations. The nominal ratio of 20 MWh to 10 MW is two hours; it is not six. Even the shorter ratio is not a complete delivered-service commitment, because actual usable energy, reserves and operating conditions require engineering assessment.

I supported C$14 million feasibility work around the five shorter-window profiles and removed the three six-hour profiles from this particular proposition. Those customers were not told that their requirements had disappeared. They needed a different development account. The decision gave up the appearance of one family addressing the entire opportunity and made the narrower commercial scope visible to the executive team.

We asked engineering colleagues to examine the intended service under the relevant site conditions, while product colleagues retained responsibility for describing the use case and its exclusions. The result recorded here is a bounded feasibility programme, not eight deployments, a certified operating duration or revenue from accepted orders. Neither the nominal rating nor my decision supplied the remaining technical approvals.

The experience changed the product conversation because the excluded customer became part of the evidence. I could explain why the proposal fitted five operating profiles well enough to investigate and why the other three required another approach. A specification becomes more useful when its relationship to a customer task is explicit. Allowing the larger opportunity to determine that relationship in advance would have made the development brief less honest and the eventual service discussion harder.

At Calverune Grid I approved a maintenance-support proposition organised around a planned weekday production stop. Our own service schedule was easier to manage that way, and the proposal had acquired the status of a standard before we had properly examined the factories expected to use it. I was then product manager, with twenty-three colleagues through three direct reports and C$2.6 million annual product expense. The decision was within my remit; it was not a standard imposed on me by somebody whose role the case can conveniently leave unnamed.

A review of forty factories found that twenty-eight could arrange the assumed window and twelve could not. Mara Vellensby challenged the proposition from the perspective of those twelve. I initially thought the account teams could handle exceptions around the standard. Her objection was that we were calling our preferred internal calendar a customer product, then making the unsuitable customer carry the burden of explaining why it did not fit.

I withdrew the single-window starting point and supported C$480000 to develop three planned service-window options with an explicit site-agreement process. The change cost us scheduling simplicity. It also required product and service colleagues to make the terms of each proposed arrangement understandable before it reached a customer discussion. We did not promise that every requested time could be accommodated or describe the options as unrestricted availability.

The recorded outcome is the redesigned proposition and agreement process. It is not a claim that downtime fell, that all forty sites bought a service or that maintenance became safe merely because the calendar changed. Engineering and operating responsibilities remained with the people qualified and authorised to exercise them. The service window had to fit alongside those requirements.

I retain this example because it shows how an internally convenient assumption can become invisible to its author. The factories were not being difficult by having another operating calendar. My product brief had treated a condition we preferred as though it were one they shared. Correcting that error required changing the standard itself, not adding a more patient explanation for why the customer should adapt to it.

The industrial load-control programme at Norvelen Power involved ninety facilities with markedly different activities. Thirty-six operated continuous processes, twenty-four used batch operations and thirty were cold-storage sites. The proposed product could support bounded automatic actions, but that capability did not settle whether a particular customer wanted to authorise them. Product development needed a clear account of participation before commercial materials could describe the service.

Forty-eight facilities authorised bounded automatic control in the programme. Forty-two asked to confirm an action manually. Owen Carvelen wanted the release to concentrate on automation, arguing that a second mode would complicate the experience and make the product harder to explain. His concern was reasonable from a development and sales perspective. I disagreed with treating the manual preference as evidence that those customers had not yet understood the modern product. Their operating responsibilities could make that confirmation part of the service they needed.

I allocated C$3.8 million development to release both modes. Product colleagues had to specify the difference clearly, and commercial colleagues had to stop grouping all ninety facilities beneath an automatic-participation claim. The product retained a way for a site to confirm an action, while operational specialists remained responsible for the suitability of the intervention in its actual circumstances. An industry category alone did not supply permission.

We gave up some interface simplicity and accepted a more differentiated account of participation. The result was a release containing both agreed modes, with forty-eight and forty-two describing the respective permissions in this programme. These numbers are not delivered megawatts, an estimate of energy saved or evidence of a completed grid-service transaction. They answer a narrower but essential question about what the customer has authorised the proposition to support.

The case matters to my product approach because a capability and a permission can look similar on a roadmap. Both may appear as a box marked ready. They are different relationships. A product can support an action that a customer has not delegated to it. Designing the manual route openly kept that distinction in the release instead of leaving account teams to reconstruct it after the larger claim had travelled.

A proposed twelve-year fixed-asset service arrangement looked coherent when we considered the equipment life. It became less coherent when we considered the premises occupied by the prospective customers. Of eighteen customer situations in the 2018 review, nine had building leases shorter than seven years, six had longer terms and three involved owned premises. The supplier’s intended service period and the customer’s control over the location were not the same calendar.

Mara Vellensby argued that commercial teams could negotiate the individual differences without changing the core product. That would preserve a simpler family and avoid committing development expense before demand had been demonstrated. I thought it left a recurring problem outside the design discussion. A customer with less than seven years of site tenure should not have to begin by explaining how a twelve-year fixed arrangement might somehow work. The product needed a serious alternative to examine.

We funded C$8.6 million development and four portable-service pilots. I did not present portability as a universal answer. Moving equipment can involve practical, technical and contractual questions of its own, and the pilot did not make those disappear. The decision was to investigate whether a different configuration and service account could fit the shorter-horizon situation, with the relevant specialists assessing the actual conditions.

The trade-off was additional development complexity and a less uniform commercial proposition. We also gave up the convenience of treating all eighteen customers as candidates for the same long commitment. The four pilots are the recorded development outcome. They are not proof that every shorter lease qualifies for the arrangement, that portability reduces every customer’s total cost or that a particular financing treatment follows.

I learned to ask about the customer’s ability to make the proposed commitment before discussing how attractively we could package it. Asset life can inform a service model, but it cannot grant the customer control of a building for longer than the customer actually has. The product account improved when both calendars could be examined together and the unresolved conditions remained visible to the people deciding whether to proceed.

The proposed remote-controller upgrade supported the protocols at 132 of 198 installed sites. Sixty-six sites used protocols outside that supported set. The product announcement could have concentrated on the larger compatible group and described the rest as migration work. That would have made the next generation appear cleaner while leaving an important question unanswered: what service account would exist for customers who could not take the proposed route on the same terms?

Owen Carvelen argued for directing available development expense towards the new controller and handling the older family through exceptions. I shared his concern that continuing several generations indefinitely would dilute the product organisation. But the sixty-six sites represented an installed relationship, not merely demand that had failed to qualify for a new product. A roadmap decision needed to identify the obligation being retained and the resources required to meet it.

I supported C$6.4 million for the older-control support programme covering 2026 through 2033, while migration planning remained specific to each site. That eight-year period was a stated programme horizon, not a claim that every installation would remain technically unchanged until its final day. Service and engineering colleagues had to examine the circumstances of an actual site and own the work needed there. Product colleagues had to keep the support account and the proposed successor distinct.

The decision reserved expense that could otherwise have appeared in the next-generation development plan. It also prevented the 132 compatible sites from being described as 132 automatic upgrades. Supported protocols establish one condition; customer authorisation, engineering acceptance and the actual implementation remain separate. The record contains no blanket operating-safety or performance certification.

This case makes retirement part of the product job. A team that only explains what it will introduce has not described the full portfolio it is asking the business to fund. The older family needs a visible owner, a dated account and a path for decisions when conditions change. I would rather show that continuing responsibility in the product plan than let a successful launch narrative make installed customers appear to be somebody else’s problem.