Shane Ian Murphy: Explain a Product Change in the Order a UK Customer Needs It

A product team can describe a release accurately and still leave its customers unsure what to do. The internal record may list components, completed tasks and new capabilities. A person using the service has a different set of questions. Will a familiar task change? Do they need to prepare? Can they continue using the old process while learning the new one?

I am Shane Ian Murphy, known professionally as Shane Murphy, formerly of Cambridge and formerly of Limitless Mobile, where I was co-founder and Chief Business Development Officer. This UK business commentary offers an approach to explaining a change. It does not announce a release from any company associated with me. The example below is a hypothetical service update.

Imagine a business replacing the form its customers use to request a routine appointment. The new form might be technically simpler, but the announcement should not begin with the software work that made it possible. I would start with the consequence for the customer: which request process is changing and whether an existing appointment is affected.

The next sentence should identify the relevant timing. If the change has a confirmed date, give it clearly. If timing is still provisional, say what remains to be confirmed. Avoid making a development target read like a promise to customers. The team needs a reliable basis for any date it publishes and a way to correct that date if circumstances change.

Then distinguish the customers who need to act from those who do not. Someone with an existing appointment may need no action at all. A person making a new request after the change may need to use a different route. Combining both groups into a general instruction can create unnecessary work and support questions. A useful announcement helps each reader recognise which case applies to them.

I would describe the new task in terms of the reader's purpose. If the person needs to request a visit, explain where that request begins and what information will be needed. A tour of every available feature is unlikely to help at that moment. The communication should stay close to the task that brought the customer to the page.

The transition deserves its own explanation. What happens if a request was started through the old process? Can an unfinished request be continued, or must it be entered again? Will a person receive a confirmation, and how can they tell that the request has reached the business? The answer must reflect the actual implemented behaviour. These are questions for the product and operations teams to verify before the message is published.

A useful change notice also identifies what remains the same. In our hypothetical appointment example, the available contact method or existing confirmation arrangements might be unchanged. If verified, saying so can reduce the reader's uncertainty. The point is not to reassure through broad language. It is to identify specific parts of the process that the person can still rely on.

Where the update introduces a limitation, explain it beside the affected task. If a particular request cannot yet be made through the new form, the reader needs the alternative route at that point. Hiding the qualification in a separate announcement makes the main instructions less dependable. A limitation is often manageable when people understand it before beginning.

I would test the notice by asking a colleague unfamiliar with the change to explain what they would do in two or three ordinary situations. Ask them to identify whether they are affected, when they need to act and where they would seek help. Their uncertainty can reveal a gap that the team no longer notices because it has discussed the change for weeks.

After publication, support questions should feed back into the explanation. Repeated questions about the same step may indicate that the notice needs a clearer example or a more direct heading. The team should preserve a visible update date when making a substantive correction so that customers can distinguish current instructions from an earlier version.

In my UK business writing, my central recommendation is to organise a change notice around the customer's decision. Describe the effect, identify the relevant timing, explain any required action and provide a clear route for unresolved questions. A well-written update respects the reader's existing work and gives them enough information to continue it.

About the author: Shane Ian Murphy, also known as Shane Murphy, is a former co-founder and Chief Business Development Officer of Limitless Mobile. This author-origin business commentary was prepared with AI assistance.

Official profile: https://shanemurphy.co.uk/

Career background: https://shanemurphy.co.uk/career