Is Your Business Ready for a Product Launch?

An application can accept a payment while the business is unable to resolve a payment dispute. It can create an account while support cannot help a customer recover access. It can display a successful order while the team has no reliable way to find an order that failed.

These are different readiness questions from whether the software performs its intended function. A launch puts the product into an operating environment with real users, imperfect inputs, external suppliers and staff who need to respond when something goes wrong.

The release decision should reflect that environment. Which customer journeys will be available? What volume can the business reasonably support? Which failures would have serious consequences? Who has authority to limit, pause or reverse the release?

For a small team, answering those questions need not produce a large governance exercise. It should produce a clear account of what has been demonstrated, what remains uncertain and what the business is prepared to accept.

Google's production launch planning resources place launch preparation within reliability practice. Their value for an SME is the attention to operational readiness, adapted to the size and consequences of the release.

The launch date may be commercially important. It should still be considered alongside evidence about the service the business is asking customers to use.

Choose the tasks that define the initial release. For a subscription product, that may include finding the offer, registering, paying, beginning useful work and getting help. For a customer portal, it may include receiving an invitation, accessing the correct record, completing an action and understanding the result.

Run those tasks through the production-like environment using safe test data. Include the messages, receipts, access controls and support routes around the main interaction. A user should not need a developer to explain a gap in the journey.

Test the awkward variants that are plausible for this product. An email address may already exist. A payment provider may return a pending result. Someone may enter incorrect information or lose connectivity before the confirmation appears. The interface should make the resulting state understandable.

Onboarding deserves particular attention. A functioning product can still leave a new customer unsure where to begin. Establish what first useful action the release is intended to support and whether the customer has the information needed to complete it.

The commercial description should match the released scope. If a capability will be available later, the launch materials should not imply that it is already usable. Support and sales need the same account of what the product can do.

Keep the evidence attached to specific journeys. “Testing complete” is too broad to explain which customer outcomes were checked, in which environment and with which limitations.

For each important failure, identify how the business would discover it. A customer complaint may sometimes be the first signal, but the team should understand that limitation.

Technical monitoring should be connected to customer consequences. A healthy server does not necessarily mean that people can complete checkout or receive a confirmation. Select signals that help the team recognise the service failures it has prioritised.

AWS's Operational Readiness Review guidance recommends tailoring readiness questions using lessons from operational incidents. A small business can apply that principle by testing the failures it already knows are possible and updating its review as new evidence arrives.

An alert also needs a recipient and an action. Decide who is available, what information they receive and when they must escalate. If the team cannot cover a certain period, the launch plan should account for it through the release window, audience or support commitment.

Rehearse the recovery steps that matter. Can the team disable a failing feature? Can it communicate a disruption? Can it restore required data in a safe test environment? Can it identify affected customers without searching through raw records it should not expose?

Document what was actually demonstrated. A backup configured in a dashboard is different evidence from a successful restoration test. A rollback instruction is different from a team showing that it can perform the rollback safely.

Support staff need a usable view of the product's initial scope, common problems and known limitations. They also need to know which actions they can take and which require approval.

This can be a concise operational guide rather than a large manual. It should explain how to identify a customer's issue, locate the relevant record, use the approved recovery route and escalate an unresolved problem. Avoid putting credentials or sensitive customer information into general-purpose documentation.

Check the surrounding services too. Billing contacts, vendor accounts, domain renewals and access permissions should have owners. The person who implemented a component should not be the only route to understanding or operating it.

The UK Government's service-team role guidance links service ownership with authority to make decisions. An SME may combine responsibilities, but it still needs a named person who can decide whether the release should proceed and what to do if the conditions change.

Security readiness belongs in this decision. Check the access, secrets, data handling and recovery controls appropriate to the product and its risk. A launch review cannot certify compliance with every law, and a successful functional test cannot establish that those controls are adequate.

Where specialist review is needed, make that requirement visible early enough to influence the release rather than discovering it at the final meeting.

Readiness is rarely a simple choice between launching everything and doing nothing. The business may be able to release to a limited audience, disable an uncertain feature, cap onboarding or begin with an assisted service.

Those choices can reduce exposure, but they also create responsibilities. A limited pilot still needs clear terms, support and a way to handle failures. Calling a release a beta does not make customer consequences disappear.

Use a decision record that separates unresolved questions by consequence:

These are examples, not automatic rules. The business must judge its obligations, alternatives and tolerance for risk.

Record the owner of each accepted limitation, the response if it becomes a problem and the point at which the decision will be reviewed. That gives the release team a shared basis for action after launch.

Agree what the team will review once customers begin using the service. Include failed tasks, support demand, onboarding difficulties and unexpected operating costs. Successful registrations alone may conceal people who never reach a useful outcome.

Keep a record of the assumptions behind the release limit. If support demand or failure rates differ materially from those assumptions, the team needs permission to change the pace of onboarding or the available scope. A commitment to learn is more useful when somebody can act on what is learned.

Marketing activity should reflect the same capacity decision. A campaign that creates demand beyond the team's ability to respond can undermine an otherwise careful release. Coordinate acquisition with the service's demonstrated ability to onboard and support customers.

A useful brief for software development and cloud engineering asks for operating evidence alongside the features. Launch readiness should make the service easier to run on its first difficult day, when the team needs more than a successful demonstration.