Offline capability is easy to promise too broadly. A buyer hears that work can continue without a connection, while the product team may mean only that a few fields can be stored temporarily. Both statements can appear in the same discussion without anyone noticing that they describe different products. I prefer to begin with the specific work that can continue, the records available to support it and the conditions that require a connection again. The boundary is part of the offer, rather than a qualification to reveal after the feature has been sold.
In the fictional 2016 Mervanith case, research involved forty-seven firms, nineteen of which needed support for intermittent work. We selected an assigned-job view and six forms for offline capture, with queued updates and visible conflict resolution after reconnection. The six-point-eight-crore programme did not make the entire platform operate offline. Seven of ten pilot clients accepted the bounded offer, while three needed a broader capability. Their response was important evidence about fit, not proof that the smaller promise had satisfied every enterprise requirement.
Choose the work that can travel
I would begin by following the person’s task into the period without a connection. What do they need to see before starting, what can they record locally and what decision depends on information that may have changed elsewhere? Those questions help distinguish an appropriate offline task from an attractive but incomplete replica of the connected application. The answers need collaboration among product, engineering, security, service operations and the relevant customer owners. Product should define the intended work without assuming it can independently settle every technical or information-handling requirement.
The assigned-job view was a deliberate limit. It gave the user a defined set of work rather than suggesting that all current organisational information would remain available. The six forms were selected tasks, not a general promise that any connected workflow could be reproduced. I would explain those choices in language a buyer can test against their own work. If their task requires a seventh form or a decision dependent on a live update, that difference deserves discussion before acceptance. Calling both situations offline would conceal the gap the buyer needs to understand.
Selecting a narrow capability also creates a responsibility to say why it is useful. A restriction alone is not a product proposition. The team should be able to describe a complete piece of work the user can perform within the boundary and how it connects to the wider process. In our case, capture and later submission served a defined need for some pilot clients. We did not claim that every field team, service arrangement or operating condition would benefit equally. The three clients needing more reminded us that a coherent small offer can still be insufficient for a legitimate task.
Treat reconnection as a product event
Reconnection is not merely the moment the technical team sends a queue. It is the point at which locally recorded work meets a system that may have changed while the user was disconnected. The product needs an understandable account of what has been submitted, what remains pending and what requires attention. A reassuring completion message is inadequate if a conflict has prevented the intended update. The person doing the work should not have to infer that state from whether an icon has stopped moving.
I would distinguish capture from acceptance throughout the experience. A form stored on a device has not necessarily become an accepted update in the shared service record. That distinction can be communicated without exposing implementation details irrelevant to the user. What matters is whether the person knows the status of their work and what action, if any, remains. The precise rules for resolving conflicts must be agreed with the relevant owners. A product narrative should not invent a universal rule that the newest local entry always wins or that every conflict can safely be resolved automatically.
The visible conflict-resolution step in the case was therefore part of the product decision, not a footnote to the six forms. It acknowledged that work performed at different times could require a further judgement before the shared record changed. I would want the pilot to observe that transition as carefully as the disconnected capture itself. A demonstration that ends before reconnection can make an incomplete sequence look successful. The person may have entered the data perfectly and still face an unresolved task once other information becomes available.
There are also operational questions about support and explanation. A user who sees pending work needs to understand whether waiting is expected or whether help is required. The service team needs enough context to respond without asking the customer to repeat the entire process blindly. These are reasons to involve operations early, while keeping its actual responsibilities distinct from the product team’s role. A capability that works in a controlled demonstration may require a clearer service account before it becomes an offer that customers can depend on for their intended tasks.
Keep the boundary visible when selling the capability
The commercial description should preserve the same scope the product team tested. An assigned-job view and six forms should not become an all-platform offline claim in a proposal. I would ask sales and implementation colleagues to challenge the description using the customer’s real sequence of work. If the customer needs broader functions, the response may be a different product decision, a clearly stated limitation or a decision not to proceed. It should not be an ambiguous reassurance that the missing work will somehow be accommodated during implementation.
The seven pilot acceptances did not establish an uptime result, universal reliability or a market conversion rate. They indicated that those clients accepted the defined capability in the pilot’s circumstances. The three other clients supplied a different kind of evidence: their requirements exceeded the boundary. I would retain both responses when considering whether to expand the product. Expansion should follow an examined need and a feasible operating promise, rather than an assumption that every refusal can be converted by adding more disconnected screens.
Expense needs the same discipline. The programme’s six-point-eight-crore amount describes the fictional commitment to the selected work. It does not by itself establish savings, incremental revenue or the continuing cost of supporting a broader offline platform. A later proposal would require its own economics and assessment. I would avoid using the pilot as an unrestricted justification for future scope, just as I would avoid treating its limits as evidence that no expansion could ever be worthwhile. The evidence should inform the next question at the scale where it was actually gathered.
My wider lesson is that a useful product promise can be narrow if it is complete enough for a defined task and honest about its dependencies. For intermittent enterprise work, that means understanding the departure from connected operation, the work performed away from it and the return. A real account would need authorised customer evidence and careful treatment of operating details. This fictional story demonstrates the product judgement I would want examined: I chose a bounded serviceable task, accepted that some buyers needed more and kept reconnection within the experience for which the product team remained accountable.