Make the store promise match the game

1695. Lesson identity

Module

4.8 — Store strategy

Lesson

Make the store promise match the game

Academic type

Concept

Schema type

text

Order

Lesson 1 in the module

Estimated time

About 30–40 minutes, including practice

This lesson develops the judgment required to represent a playable product accurately in its store-facing language.

1696. Learning objective

After this lesson, you can identify store claims that lack playable evidence, exceed the product's current boundaries, or promise an experience the game does not reliably deliver.

1697. Why this matters

A store page establishes an expectation before the player touches the game. If its promise is broader, more certain, or more dramatic than the playable product, the mismatch becomes a product problem rather than a copywriting problem. Accurate positioning also improves decision-making: the team can see which audience it is serving and which evidence the game must provide. AI can generate persuasive wording, but it cannot decide whether the wording is supported by the actual build unless you supply and inspect that evidence.

1698. Prior knowledge

You should already be able to review a monetization proposal using explicit acquisition paths, player value, and disclosure requirements from 4.7 — Review a monetization proposal. You should also have a playable product slice or a current product description from which to gather evidence.

1699. Core concept

A credible store promise has four connected parts:

1. Audience: Who is this experience for?
2. Promise: What experience or value is being offered?
3. Evidence: What can a player actually observe or do in the current game?
4. Claim boundary: What must not be stated because it is unverified, conditional, future-facing, or absent?

A claim is ready for store use only when the audience can recognize its relevance, the promise is specific enough to guide expectations, and the evidence supports its wording. A claim boundary is not a weakness in the positioning. It is a control that prevents the store from becoming a second, fictional version of the game.

1700. Mental model

Use Audience → Promise → Evidence → Boundary as a claim review table:

The model works in both directions. Start with a proposed claim and test it against the build, or start with a strong product behavior and formulate a narrower claim around it.

1701. Concrete example

Suppose a small game currently lets players choose routes through a dangerous district, trade limited supplies, and escape when they reach an extraction point. It does not yet contain cooperative play, procedural missions, or a persistent faction system.

The audience may still be described as players who enjoy tense route planning and resource decisions. The promise becomes stronger by becoming more precise, not by adding unsupported scale.

1702. Common mistake

The common mistake is treating a plausible feature, a design intention, or an aspirational roadmap item as evidence of what the current game delivers. Another mistake is using adjectives such as “deep,” “dynamic,” or “unlimited” as if they were proof. Replace broad praise with observable player actions and outcomes. If the claim cannot be demonstrated in the current product, mark it as future-facing or remove it.

1703. Guided practice

Review the following proposed store claims for a fictional product called Night Transit. The playable slice allows the player to reroute a vehicle, spend fuel, avoid hazards, and reach one of two destinations. It has no multiplayer, upgrade tree, or branching narrative yet.

1. “Make fast route decisions while fuel and hazards change the cost of every trip.”
2. “Coordinate with a crew of friends across a living network.”
3. “Every journey creates a lasting story shaped by your relationships.”
4. “Choose between two destinations and accept the risk of a longer route.”

For each claim, record these five outputs:

• the likely audience;
• the exact promise;
• the playable evidence, if any;
• the boundary or missing evidence;
• a final decision: keep, narrow, or remove.

At least one claim must be narrowed rather than simply accepted or rejected. Write the revised wording so that a player could verify it during play.

1704. Validation / evidence

Submit a completed review for all four claims. Your evidence must contain the following five outputs for each claim:

1. Audience — the likely player group or play preference;
2. Promise — the experience the wording offers;
3. Evidence — the specific current action, system, or outcome that supports it, or an explicit statement that no such evidence exists;
4. Boundary — the missing, conditional, planned, or untested behavior that limits the claim;
5. Decision — explicitly choose keep, narrow, or remove.

Also include one revised statement for a claim marked narrow. A satisfactory review distinguishes current behavior from planned or absent features, names an audience without claiming to serve everyone, connects each retained claim to a specific playable action or outcome, and identifies language that creates an expectation beyond the evidence. If another developer can inspect your product slice and locate the behavior described by the revised claim, the positioning has a defensible evidence link.

1705. Key takeaways

• Store positioning is a promise about the player's expected experience, not a summary of intentions.
• Every important claim needs observable evidence in the current product.
• Audience, promise, evidence, and claim boundaries should be reviewed together.
• Narrow, specific claims are more useful than unsupported claims with larger adjectives.
• AI may improve wording, but the developer must verify the product evidence and approve the boundary.

1706. Knowledge check

1707. Next lesson

Continue to 4.8 L2 — Write an honest store-page strategy.

1708. Knowledge check