The Product Works. The Company Is Not Ready.

A product reaches the point everyone has been working toward. For months, the hardest problems in the company were product problems: whether the thing could be built, whether it would hold up, whether it would do what it promised. Those are solved now. The product performs as intended. It passes its tests. The demonstration runs clean. The people who built it can carry it from start to finish without holding their breath. The launch date is on the calendar, and after months of building, the mood shifts from making the product to shipping it. What remains looks like rollout.

Then a serious customer begins asking ordinary questions.

What exactly is included? What will it require from them? When can they begin? Who helps if something goes wrong? What happens after the first purchase?

The product team can answer some of those questions. Sales can answer others. Operations, finance, support, and outside specialists may each hold a different piece.

The answers exist. The path connecting them does not.

A functioning product and a market-ready company are different conditions.

I keep seeing teams finish the product while the company required to carry it to the customer is still unfinished. The product can perform its intended job while the company is still unable to explain it clearly, sell it responsibly, deliver it consistently, help a customer succeed with it, support it when conditions change, or maintain it after launch.

This is often described as needing marketing and operations around the product. That is true, but incomplete. It makes the remaining work sound like a collection of launch tasks.

The actual problem is that every function can finish its own piece while the customer’s path across those pieces remains unfinished.

First, the product has to have earned the word works. It has to create the intended value for the intended customer under realistic conditions. A clean demonstration proves that the expected sequence can run. It does not establish usefulness, reliability, or customer value on its own.

Brand can make a useful product understandable. Sales can make it purchasable. Operations can make it deliverable. None of them can create value the product does not provide.

Once that boundary is clear, the company has a different question to answer:

Can it carry a customer all the way through?

Follow one customer, not one department

Asking every team whether it is ready is an incomplete way to review a launch.

Marketing may have the campaign. Sales may have the presentation. Product may have approved the release. Operations may have a delivery plan. Support may have an inbox.

Every team can answer yes while the customer still gets stuck between them.

The more useful test is to take one intended customer and follow what they have to do from first interest through continued use.

They begin by discovering and evaluating the product. They need to recognize that it is for them, understand the result it promises, know what it requires, and judge whether it fits their situation.

The company has to make that possible without rebuilding the explanation for every serious prospect. The website, presentation, demonstration, packaging, or sales conversation has to carry an accurate promise, including the limitations, prerequisites, and evidence the customer needs to make a responsible decision.

This is where an early gap often becomes visible. The product creates interest, but the customer-facing system cannot yet answer basic questions about fit, setup, delivery, cost, or expected results without an internal clarification each time.

Then the customer decides to buy.

Now the company needs more than a price. It needs a defined offer, a way to complete the transaction, terms it will honor, a reliable delivery or start date, and clear boundaries around what may be negotiated.

Finance has to be able to invoice or collect payment. Sales has to know what is included and what is not. Delivery has to receive the commitments made before the sale. A nonstandard request needs somewhere to go before anyone promises an exception.

Some products also carry contractual, regulatory, safety, security, privacy, or technical considerations. The company has to know which claims and commitments require specialist review, who owns that review, and when it must be complete.

That is not a final check added after the commercial work. It is part of whether the company is prepared to make the promise at all.

After purchase, the sale becomes work.

The customer may need setup, implementation, or another transition into use. Someone has to own that stage. The required information and prerequisites have to be known. The handoff has to preserve what was sold, what was promised, and anything unusual about the customer.

The company also needs a definition of completion. “Onboarding started” does not mean “the customer is ready to use the product.”

The first exception will test that definition quickly. A prerequisite will be missing. A dependency will not behave as expected. The customer’s situation will not match the standard sequence.

A ready company does not need to predict every exception. It needs an owner and a route for the exception when it appears.

Then the customer attempts to get the result they bought.

This is where a launch becomes customer value rather than launch activity. The company needs evidence that the customer reached the intended outcome, not only that an order was placed, an account was created, or delivery was completed.

It also needs a way to understand what happened when the outcome does not arrive.

Was the product defective? Was setup incomplete? Was a prerequisite missed? Did the customer misunderstand the promise? Did the company sell the product into a situation it was not designed to handle?

Without that distinction, every problem becomes either a product complaint or customer error. Neither explanation gives the company enough information to improve the product or the system around it.

Then support meets the customer.

Support cannot first learn the product when customers begin asking for help. Before launch, the company should know where requests enter, what information is needed to diagnose them, who owns the response, what support may resolve, and what has to reach product, operations, a supplier, or a specialist.

The customer should not have to watch their question move from inbox to inbox while each team explains why another team owns it.

A product tour is not support readiness. A tour explains what should happen. Support readiness explains what to do when it does not.

The path continues after the first problem is resolved. Depending on the product, the company may need to support continued use, whether that means renewals, replacements, or ongoing maintenance.

Someone has to own that ongoing condition. The company also needs a way for what customers experience after launch to return to the people making product, sales, delivery, and support decisions.

Otherwise, the launch creates activity but very little learning.

Turn the customer path into a readiness map

The walk-through becomes useful when it is made visible.

For each stage the customer crosses, record what they are trying to accomplish, the company capability their next step requires, who owns that capability, the evidence that it is ready, where an exception goes, and what will show that the customer completed the stage successfully.

The evidence has to describe something that can be observed.

“Sales is ready” is not evidence. A qualified customer receiving an accurate offer without the company redefining it during the conversation is.

“Onboarding is ready” is not evidence. A customer completing the process with the agreed information, ownership, and handoffs intact is.

“Legal will review it” or “security is looking at it” is not evidence either. The review needs an owner, a defined scope, and a point in the sequence where it must be complete.

As the map takes shape, mark every assumption the company is treating as fact, every capability with no named owner, every handoff that has not been tested, and every exception that has nowhere to go.

A checklist shows what the company produced.

The readiness map shows whether the customer can move.

Decide what the company is ready to launch

A launch date is not a launch decision.

Neither is a meeting where every department reports that its assigned work is complete.

Someone with authority should be able to make a specific statement: We are ready to launch this version, to this customer group, at this volume, under these conditions.

The scope matters.

A company may be ready to support five pilot customers closely without being ready for five hundred. It may be ready for one customer segment, one product configuration, one geography, or one delivery channel while broader readiness remains unproven.

That does not make the product unready. It defines what the company can responsibly carry next.

The decision should name the evidence supporting that scope, the risks that remain, who owns them, and what would cause the company to pause, narrow, or revise the release. It should also state when the first customer evidence will be reviewed and what decision that evidence is expected to inform.

I would rather see a company launch narrowly with a complete customer path than launch broadly with a collection of finished assets.

A controlled release is not a lack of ambition. It is a way to learn without asking the first customers to absorb every unfinished handoff at once.

Readiness still does not guarantee success. It cannot create demand, repair weak economics, correct poor timing, or force the market to care.

What it can do is reduce avoidable operating risk and make the remaining uncertainty visible. The launch can then test the product and the market, instead of testing whether the company can improvise fast enough to keep the customer moving.

The drift usually makes sense from inside.

Product was concentrating on finishing the build. Sales was waiting for something stable enough to sell. Support had no real customer behavior to study. Operations was waiting for volume it could plan against. Leadership was trying to protect the date.

Each decision was reasonable. The gap formed because no one had walked the complete customer path early enough to see what was missing between them.

Before the launch review, choose one intended customer and follow their path from first interest through continued use. Mark every assumption, unnamed owner, untested handoff, unfinished capability, and missing exception route.

Then ask the question the launch date cannot answer:

If the right customer said yes tomorrow, where would their progress stop because the company has not yet decided, assigned, built, or tested what happens next?