I initially supported a ticket-engine proposal because it appeared to sit beside work our software already helped customers organise. We knew venues, we held production-planning records and we heard interest in a better connection to ticketing. The adjacency made the proposal easy to describe. It also made it easy to move too quickly from a customer's wish for a connected workflow to an assumption that the customer wanted us to become the provider of the adjoining service.
Discovery across 27 venues changed that account. Twenty-one wanted integration with their incumbent ticketing system. Six wanted a replacement. Both groups had expressed a relevant need, but they were asking for different commitments. A proposal built around replacing the ticketing capability could not treat the interest of all 27 as support. The distinction was commercially inconvenient because the broader count had helped make the expansion feel more established than it was.
Interest in participation is not permission to own the adjoining service
The product sponsor argued that owning a ticket engine would give the company greater control over the workflow. That was a coherent strategic possibility, not an unreasonable ambition to dismiss. The six venues seeking replacement also deserved attention. My concern was that the paper had combined those facts with the 21 integration requests and used the resulting population to support one proposition. The customer evidence was being asked to settle a choice it had actually divided.
A connected workflow can contain several suppliers because the customer wants those suppliers to retain different responsibilities. Integration may be valuable precisely because it allows an existing arrangement to continue. If a strategy assumes that every useful connection should eventually become ownership, it may misread the reason the customer wants the connection in the first place. The company needs to understand that reason before treating another provider's place in the workflow as space waiting to be occupied.
I recommended withdrawing the ₹2.4 crore ticket-engine proposal before commitment, and the CEO accepted the recommendation. We retained ₹38 lakh of discovery expense. That cost mattered because it represented work undertaken while I supported the original direction. I did not describe the change as though the company had learned everything for free or as though a proposal that was never committed had become a realised saving. The decision prevented a particular next commitment; it did not reverse the expense already incurred.
The narrower programme still needed its own case
I recommended a separate ₹0.9 crore integration programme in response to the connection request. It remains unfinished in this account. That status prevents the alternative from becoming a convenient success story merely because the original proposal was withdrawn. Integration has its own dependencies, technical work, permissions and support arrangements. A narrower proposition is not automatically a completed or profitable one, and it should not inherit approval simply because it appears more aligned with the reviewed need.
The programme also did not answer the six venues that wanted replacement. We could continue to understand their circumstances without pretending that the integration direction satisfied them. The reviewed group was not the whole market, and its split did not establish a universal rule that a planning-software provider should never enter ticketing. It established that our current evidence did not support the particular proposal we had made. Another proposal would require its own account of demand, capability and obligation.
This is an important distinction when a strategy changes direction. Leaders sometimes feel that they must replace one confident story with another immediately. The result is an alternative that sounds complete before the work behind it has been done. I prefer a decision record that can say the original proposition was not supported, the alternative is worth developing and important questions remain. That account is less satisfying as a celebration, but it is more useful for deciding what to fund and what to learn next.
The operating boundary matters as much as the feature boundary. A ticket engine would not merely add another screen to a planning product. It would change the responsibilities customers expected us to accept. Our current product does not process ticket payments, control stage equipment or certify production safety. A strategy should identify any proposed change to those boundaries explicitly and involve the relevant owners. Technical feasibility alone cannot decide whether the enterprise should accept the wider commitment.
A strategy paper should preserve the judgement that changed
My own role in the first proposal belongs in the account. I had heard a plausible connection and supported an expansion before the different requests were sufficiently separated. It would be easier to describe the case as an example of asking good questions from the beginning. That would remove the decision that made the learning consequential. The more useful account explains which assumption I reconsidered, who challenged it and how the recommendation changed.
The disagreement with the product sponsor also deserves to remain visible. Greater control could have strategic value, and some customers did want replacement. The issue was not that those arguments were foolish. It was that they needed a different investment case from one supported by the full 27-venue interest count. Recognising the strongest part of a competing view makes the decision more precise. It allows a company to decline a proposal without pretending that every reason behind it has disappeared.
For a board, I would frame the question around the commitment the business would accept. Which customer problem is being addressed? Does the evidence concern connection, replacement or both? What capabilities and obligations would each option require? Which part of the recommendation belongs to management judgement despite incomplete evidence? Directors do not need to choose an integration design to examine whether the commercial argument and the proposed enterprise boundary correspond.
The same questions help after approval. If the integration programme remains unfinished, the board should see its actual progress and unresolved conditions rather than receive the original rationale as though it were evidence of delivery. A good initial decision does not make subsequent execution automatic. Strategy remains responsible for keeping the choice connected to what is learned, while product, finance and operating owners retain their respective work.
I still see value in adjacent opportunities. Customers often reveal useful connections between activities, and a company should be capable of examining them seriously. The lesson of this case is to be specific about what the customer wants connected and what the company proposes to own. Those can be different propositions even when they appear on the same workflow diagram. Once we separated them, the next commitment became smaller and less complete, but it became a commitment we could explain more honestly.