A Successful Launch Can Still Be a Product Failure

In February 2021, Google pointed to the successful release of Cyberpunk 2077 on Stadia as evidence that its game-streaming technology worked at scale. The same update announced that Google would stop investing in internally developed exclusive games beyond those already planned for the near term, and put more emphasis on serving industry partners. There was a real technical achievement inside a business already changing direction. Google's February 2021 update

In September 2022, Google announced that it would wind down the consumer service because adoption had fallen short of its expectations. It continued to describe the underlying technology as strong. Google's wind-down announcement

Those statements leave room for more than one honest judgment about the work. Customers may enjoy a technically demanding release even when the product cannot attract enough use to sustain the business built around it. Their enjoyment is real, and so is the company's problem.

I would be careful about making Stadia a tidy story of a team that built the wrong thing. These public accounts leave the causes of weak adoption and the thresholds behind the decision to stop unresolved. The successful release here is a game on the platform; it is not a claim that Stadia delivered every ambition of its original launch. The case leaves a product leader with a harder judgment than simply declaring all the work good or bad.

The harder question for a product leader comes before that ending, when the release is complete, the initial numbers look encouraging, and there is still time to change the outcome.

At that point, I want the original customer problem to remain attached to the work. A delivery report can say exactly what shipped and what it took to get there. The next investment needs an account of what customers can now accomplish, what still gets in their way, and whether the product has a credible path to the result that justified building it.

The customer may still be doing the old work

Imagine a service that lets customers reschedule an installation appointment online. The company funds it because changing an appointment requires a phone call, sometimes followed by another call to confirm that the change reached the installer. The intended improvement is straightforward: a customer should be able to choose a new slot and rely on it.

Suppose the team delivers the promised flow. Customers can choose a date, submit the change, and receive a confirmation. The release is stable, and people start using it. Completed rescheduling transactions would be a reasonable early signal to report.

Now suppose customers still call afterward because the confirmation does not tell them whether the installer received the update. The online transaction has succeeded. The customer's uncertainty survives it. If the company counts each completed transaction as a call avoided, it will overstate the benefit and may fund expansion of a flow that has simply moved the point at which people need help.

To investigate this hypothetical case, follow an online reschedule through to the appointment. Look at whether the customer contacted support again and what they needed to know. Check whether the installer actually received the change. The answer could expose a communication problem, or it could reveal that the customer has correctly noticed an unreliable handoff to the installer. A more confident confirmation message would make that second problem worse.

The customer outcome has to survive the entire task. For this service, the task ends when the customer can trust the new appointment, not when the submit button produces a success screen.

If the scheduling system is reliable and the uncertainty comes from missing information, the team can test a confirmation that explains what has happened. If the update sometimes fails to reach the installer, the next investment belongs in that connection. Increasing traffic to the feature would amplify the unresolved problem.

I would also want to know who benefited. A service may work well for customers making a simple change several days ahead, while failing those who need to change an appointment tomorrow. Averaging those experiences together can hide both a useful product and an important limitation. There may be a sound case for a narrower service with clear boundaries. That is a decision about which customer promise the company can keep.

Giving the product time has to mean something

A disappointing first result can tempt people into a second mistake: declaring failure before customers have had a reasonable opportunity to use the product.

Appointment rescheduling is occasional. Someone who used the service successfully last week may have no reason to return for months. A retention curve designed for a daily product would tell a misleading story here. The evaluation window has to follow the occasion that creates demand, and the comparison needs to include people who actually had that occasion.

The same patience becomes harder to judge when the product asks people to change an established habit. A new service might need time to earn confidence. Its first users may encounter rough edges that the next release can remove. Cutting it immediately can waste the investment just as surely as extending it without a reason.

I would support more time when the team can explain what it expects to change during that time. In the rescheduling example, a revised confirmation could plausibly reduce follow-up calls. The next evaluation should cover customers who encounter that revision and then complete their appointments. It should also establish whether the change merely suppressed calls while leaving appointment errors unresolved.

The uncomfortable result would be a clearer confirmation with the same need for support. That would weaken the explanation behind the additional work. The team would have to examine another cause or reconsider how much of the problem this product can solve.

“Adoption takes time” leaves that uncomfortable result unexplained. A forecast tied to a change in the experience gives the team something it can learn from, including a result it would rather not see. Continued investment should come with an explanation that the next evidence can challenge.

The funding decision should account for how long a result reasonably takes to emerge. For infrastructure work, an intermediate result might establish that another service can now support its expected load; a revenue effect could be much further away. The people funding it need to understand that connection and how much uncertainty they are carrying. They also need to leave someone able to act when the evidence arrives.

For the rescheduling service, I would reserve capacity to investigate the first real appointments and act on what they reveal. That capacity belongs in the release plan. Otherwise, finding that customers still need to call becomes a report for a future prioritization meeting, even though reducing those calls helped justify the original investment.

The accountable group also needs access to the decisions that determine the outcome. A PM cannot fix an unreliable installer integration through interface changes alone. If another business unit controls that system, its owner needs to participate in deciding what happens next. Asking the product team to own an outcome while leaving the decisive constraint outside its reach creates accountability on paper that cannot work in practice.

Sometimes the answer will be to stop. That creates work of its own for the customers who did find the product useful. Google's Stadia announcement included plans to refund specified hardware and content purchases and keep game access available through January 18, 2023. Those were customer transition commitments alongside the business decision. The announced transition plan

For a smaller service, the same responsibility might mean returning customers to a supported booking route and making sure appointments already changed online remain valid. The value of a product to a particular customer does not disappear because its aggregate results disappoint the company.

I would be comfortable celebrating the rescheduling launch and then keeping its customer outcome open. The people who delivered it deserve credit for the work. When the first customer calls to ask whether the installer knows about the new date, someone should still have the time and authority to find out why that call was necessary, and to decide what the company will do about it.

This writing reflects my personal perspectives on product management, AI, and content discovery. It does not represent the official position of my employer or any affiliated organization.