A shared software product earns its roadmap by deciding which customer promises it will not make.

In 2023 an enterprise buyer proposed ₹18 crore for an exclusive workflow within Mervanith’s platform. The initial estimate required three shared teams for fourteen months. Sales colleagues saw a substantial immediate opportunity. Nandita Vervale asked which existing product commitments would move if those teams were assigned to a separate branch and what continuing support the exclusivity would require.

I declined the exclusive version and supported a configurable common module instead. The decision gave up a proposal whose value was easy to state, in favour of a product whose usefulness had to be tested across several clients. I wanted the underlying workflow need examined without assuming that the buyer’s preferred implementation should become a permanent obligation for the shared platform.

₹8.4 crore supported product work on the configurable approach. Engineering evaluated the implementation and operating consequences, while sales and legal colleagues retained responsibility for commercial discussions and terms. Six clients participated in the pilot; four adopted the module and two declined because the common scope did not meet their needs. We retained those refusals rather than present configurability as an answer that could satisfy every enterprise request.

The ₹18 crore was a proposed amount, not revenue earned or subsequently lost from an existing contract. The ₹8.4 crore expense was not evidence of a profit or savings result. The outcome was a shared product decision with a bounded adoption account. We accepted a narrower fit and the uncertainty of the alternative rather than let one proposal consume the roadmap by default.

I would make the continuing team and support consequences visible at the beginning of future large-customer discussions. The comparison should include what the product would become, not only the value of the next agreement. A shared roadmap earns its meaning through the commitments it can sustain across customers. In this case, declining the exclusive branch was part of protecting that responsibility, not a claim that customer-specific work is always the wrong commercial choice.

At Dharvilen in 2002, I approved a planning prototype that replaced keyboard entry with a drag-only scheduling interaction. The demonstration looked direct and modern to me. Testing with twenty-six planners showed that eleven could not complete three defined planning tasks without a pointer. Suresh Dharveth challenged my assumption that the new gesture was a sufficient replacement for the existing route.

The design team preferred to teach the gesture and keep one interaction model. I accepted that the task needed a keyboard-operable path alongside pointer use. The issue was not a claim about the identity or disability of any participant. It was that the product had removed a way to perform the defined work and then treated adapting to the demonstration as the user’s responsibility.

₹52 lakh supported restoring the keyboard route and reviewing how its actions and focus moved through those planning tasks. Engineering and design colleagues evaluated the implementation. I did not describe that bounded correction as certification against every accessibility requirement or assume that three tasks represented the entire product. The case concerns a specific omission I had approved, not a retrospective claim that a later standard had been met in 2002.

The outcome preserved another usable route through the planning work. It did not establish a measured productivity gain for all users or prove that no further interaction problems remained. We gave up the visual uniformity of a gesture-only demonstration and accepted the work of explaining and maintaining more than one appropriate means of operation.

I would now ask what existing task capability a proposed interaction removes before celebrating its appearance. A new gesture may add value without becoming the only way to complete the work. Suresh’s challenge changed how I treated product simplicity: reducing the visible interface is not a sufficient result if the reduction makes a necessary action unavailable. I needed to correct my own preference before asking users to change theirs.

A 2016 field-service proposition was initially described as an offline version of the platform. Research with forty-seven firms found nineteen with a need to work through intermittent connectivity. Their requests covered different activities, and the broad phrase invited a much larger expectation than the first capability could support. The commercial sponsor wanted to retain that phrase because it was immediately understandable in a sales conversation.

I narrowed the promise to viewing assigned jobs and capturing information in six specified forms. Updates would remain queued for reconnection, with conflicting changes made visible for resolution. The offer did not include every operation or imply that disconnected work had already been reconciled with the shared service. Engineering and service colleagues retained responsibility for implementation, evaluation and the supported conditions.

₹6.8 crore funded product work. Ten firms joined the pilot. Seven accepted the stated scope, while three needed broader offline functionality and declined. I kept that distinction in the account rather than treat their requirements as misunderstandings we could solve by explaining the same limited offer more forcefully. The product was appropriate for a narrower set of needs than the opening pitch had suggested.

The result was a bounded capability and a pilot response, not a universal availability promise or proof that every queued update would complete without conflict. We gave up the simpler claim that the whole platform worked offline. The clearer description required sales and customer teams to discuss what happened during disconnection and what remained to be resolved afterwards.

I would define the offline task and the reconnection consequence before choosing the headline in a future proposition. A user needs to know which work can be performed, what state it will be in and what will happen when shared information becomes available again. The product decision should make those boundaries intelligible without turning the website into an engineering specification. Precision about the six forms made the promise smaller, but made the choice more useful for firms deciding whether that capability fitted their work.

In 2021 the team evaluated machine-assisted status suggestions for service workflows. A review of 1500 suggested items found 180 with the wrong context for the intended status. The proposed product direction would have published suggestions automatically, using the apparent convenience of the successful examples to describe the feature as a reduction in routine work.

I declined automatic publication for the evaluated capability. The product would present a draft with source context and a named human review step before publication. The delivery sponsor preferred to retain automatic action because it made the benefit easier to demonstrate. I wanted the response to the observed contextual errors included in the product’s operation rather than delegated to a warning that users might not see until after a status had changed.

₹9.2 crore supported product work on the bounded approach. Engineering evaluated the suggestion mechanism, and service and security owners assessed the relevant workflow conditions. The reviewed items were part of prototype evaluation, not an account of autonomous changes already sent to customers. We did not claim that adding a person eliminated error or made every suggested status suitable for every context.

The outcome was a narrower assistance model that retained responsibility for the publication decision. It did not establish a measured time saving, a complete release or a universally safe product. The trade-off was additional review work and a less dramatic demonstration of automation. That cost belonged in the proposition because the evaluated evidence had not supported removing the review.

I would define the consequence of a wrong contextual suggestion before deciding which action the product may perform on its own. A correct-looking sentence can be inappropriate to the case it describes, so a feature’s fluency or convenience is insufficient evidence for automatic publication. The draft approach kept the assistance useful for examination while declining the broader promise. Its adequacy would still need further evaluation of the real workflow and the people expected to review it.

The 2025 onboarding programme had been organised around account provisioning and a tour of platform features. Those steps made rollout activity visible, but they did not establish that a customer team had completed the service work for which it had adopted the product. I asked for a first end-to-end workflow to become the organising task of the pilot, with blockers retained in the account rather than hidden after a successful tour.

The launch sponsor preferred the existing completion story because provisioning and tour attendance were easier to schedule. I chose a guided first job, with the product and customer teams agreeing what completion meant for the pilot’s scope. Engineering and service owners assessed the supported setup and operating conditions. The product team could help structure the journey without claiming authority over every customer process or every dependency outside the platform.

₹7.6 crore supported the product work. Among 120 pilot customer teams, eighty-six completed a first end-to-end service workflow within thirty days and thirty-four did not. We recorded the incomplete group and its blockers for further enquiry. The case contains no invented earlier completion rate, so I did not present the result as a measured improvement over a baseline we had not established.

The output gave the team a more substantive account of the pilot’s progress. It did not prove sales growth, retention or a causal effect of the guided approach. A completed first workflow was also not a claim that every later task would be straightforward. We accepted a less uniformly positive completion report in exchange for seeing where customer work still required attention.

I would agree the first useful task before selecting the onboarding milestones next time. A tour can help users learn, and provisioning is necessary, but neither should be mistaken for the work the customer came to accomplish. The product account becomes more useful when it shows that difference. Here it kept the thirty-four incomplete teams in view and made the next decision about their actual obstacles, rather than about how to make the rollout dashboard look finished.