# A nutrition app cannot translate its way into product readiness

Companion to /learn/localization/strategy/

## Outcome
Build a market rollout plan that connects demand, product readiness, language and operational support.

Fictional example, not a client result.

## Scenario
MealMap is a fictional nutrition app considering two markets. One has early user demand but incomplete local food coverage. The other has good product coverage and a native reviewer available, but uncertain acquisition demand. Translating the listing into both languages would not resolve either uncertainty.

## Reasoning
Separate market attractiveness from readiness. Investigate demand and competitive context, then verify the actual localized product, support capacity and relevant workflows. Identify which assumptions can be tested cheaply before commissioning all assets. Do not treat language as a perfect proxy for country or assume that a translated store page means the product is ready for everyone who can read it.

## Action
Create a readiness record for each market. For the first, resolve food coverage and product expectations before promoting a broad nutrition promise. For the second, investigate audience language and demand while preparing a tightly scoped pilot. Give each market a responsible owner and explicit release conditions so localization becomes a managed decision rather than a batch of text files.

## Trap to avoid
Do not report localization progress only as the number of translated strings. Track whether the promise, product evidence, screenshots and operational responsibilities are ready for the intended audience.

## Advanced considerations
Plan maintenance when planning launch. A product update can invalidate translated captions, screenshots or feature descriptions. Record how a source change triggers local review and who can block a release when accuracy is uncertain. This avoids creating a growing collection of localized pages that describe different historical versions of the same product.

## Exercise
A market looks attractive in a tool, but the app’s payment flow is not usable there. Should listing localization proceed as a growth launch?

## Suggested answer
Resolve the product constraint or narrow the supported proposition first. A polished listing that sends people into a broken core workflow does not establish readiness. Research can continue, but release should reflect the actual user experience.

## Your worksheet

### Market, language and target audience
Answer:
Evidence:
Uncertainty:
Owner:
Next action:

### Demand evidence and uncertainty
Answer:
Evidence:
Uncertainty:
Owner:
Next action:

### Product and content readiness
Answer:
Evidence:
Uncertainty:
Owner:
Next action:

### Native research and review owner
Answer:
Evidence:
Uncertainty:
Owner:
Next action:

### Creative adaptation and support capacity
Answer:
Evidence:
Uncertainty:
Owner:
Next action:

### Pilot scope and release conditions
Answer:
Evidence:
Uncertainty:
Owner:
Next action:

## A market-readiness decision for MealMap
Markets A and B below are fictional planning scenarios, not rankings of real countries. The point is to separate commercial interest from the ability to deliver the promised experience, then choose the next evidence-gathering step.

Fictional readiness comparison. Product blockers cannot be averaged away by an opportunity score.
Readiness question | Market A | Market B
Audience evidence | Early interest exists; source and segment need review | Demand uncertain; investigate local language and alternatives
Product readiness | Local food coverage incomplete | Core food workflow supported under the scenario assumptions
Review capacity | Native reviewer not assigned | Native reviewer available; responsibilities still need agreement
Release decision | Hold growth launch until coverage and review blockers are resolved | Prepare a bounded pilot brief while validating the audience
Next owner action | Product owner scopes coverage; localization lead assigns reviewer | Research owner defines audience; release owner documents pilot gates

### Write a pilot charter before commissioning assets
Name the store, language, country context, intended audience and supported workflow. Record which product version will be available, who reviews terminology and who approves publication. Define the evidence you can actually collect and the next decision it should inform. A pilot charter should also state exclusions so a small experiment does not quietly become a promise to support an entire region.

### Use gates rather than an averaged readiness score
A missing core workflow can prevent a responsible launch even when research suggests demand. Treat unsupported claims, unusable core journeys and missing review ownership as issues to resolve, not small deductions from a composite score. Other uncertainties may be acceptable in a bounded pilot if they are explicit and the team can learn from them.

### Define expansion and maintenance together
Agree what would support continuing, revising or stopping the pilot. Inspect product experience and support feedback alongside listing evidence. Before adding another market, assign ownership for updating translated copy and screenshots when the source product changes. Keep a shared change record so the new market inherits useful learning without inheriting stale claims.

## Continue reading
- /learn/localization/market-prioritization/
- /learn/localization/local-keyword-research/
- /learn/localization/quality-assurance/