# A language app chooses a smaller, clearer promise

Companion to /learn/keywords/prioritization/

## Outcome
Choose keyword work using relevance, evidence, feasibility and business fit instead of a single score.

Fictional example, not a client result.

## Scenario
TalkTrip is a fictional language app built around short travel conversations. Its backlog contains “learn languages,” “travel Spanish” and “translate documents.” The first is broad, the second describes its core workflow, and the third implies a capability it does not offer. A stakeholder wants whichever term has the highest tool score.

## Reasoning
Apply product relevance as an entry condition. Then compare the remaining candidates on audience value, demand evidence, competitive context and the work required to support the promise. Use ordinal judgments such as strong, uncertain and weak when the evidence does not justify precise numbers. A weighted formula is useful only if the underlying inputs and weights have a defensible meaning.

## Action
Investigate travel-conversation terms first and draft a listing that demonstrates a realistic exchange. Keep broader language-learning terms as a separate research track rather than pretending one metadata change can own the entire category. Reject document translation. Note which assumptions could change the priority, such as a new supported workflow or stronger evidence of audience demand.

## Trap to avoid
Avoid fake mathematical precision. Multiplying three subjective scores does not produce an objective opportunity forecast. Show the reasoning behind the priority and keep estimates visibly separate from observed results.

## Advanced considerations
Prioritisation should produce a portfolio, not only a winner. Identify a near-term cluster, a small number of research questions and explicit exclusions. Review it when evidence changes rather than on a fixed urge to refresh keywords. Link each selected cluster to a metadata owner and a change-log entry so the research survives the handoff into publishing.

## Exercise
One candidate has excellent relevance but little demand evidence. Another has strong estimated demand but uncertain relevance. Which should go first?

## Suggested answer
Resolve the relevance uncertainty before prioritising the second candidate. For the first, investigate whether the audience uses different language for the same job. Neither weak demand evidence nor a high estimate should be converted into certainty by a scoring formula.

## Your worksheet

### Candidate or cluster
Answer:
Evidence:
Uncertainty:
Owner:
Next action:

### Product-fit gate and evidence
Answer:
Evidence:
Uncertainty:
Owner:
Next action:

### Audience/business value
Answer:
Evidence:
Uncertainty:
Owner:
Next action:

### Demand evidence with confidence
Answer:
Evidence:
Uncertainty:
Owner:
Next action:

### Competitive and implementation constraints
Answer:
Evidence:
Uncertainty:
Owner:
Next action:

### Decision, rationale and revisit trigger
Answer:
Evidence:
Uncertainty:
Owner:
Next action:

## A decision register for TalkTrip
This completed example separates eligibility from scheduling. Unknown demand remains unknown. The team can investigate a relevant phrase without committing to publish it, and can reject an irrelevant phrase without spending time scoring it.

Fictional priority register. No demand, competition or expected-uplift measurements are implied.
Candidate | Decision and reason | Next action / revisit trigger
Travel Spanish | Investigate first: supported travel-conversation workflow | Research local terminology before drafting
Restaurant Spanish | Potential focused message: relevant scenario exists | Check whether the audience expects translation or lessons
Learn languages | Hold: broader promise than the primary product experience | Revisit if supported learning scope expands
Translate documents | Exclude: unsupported workflow | Revisit only after a verified product capability change

### Use gates before trade-offs
Ask whether a phrase describes something the current app does, whether the target audience is appropriate and whether the listing can substantiate the implied promise. A failed product-fit gate is a reason to exclude or investigate, not a weakness that high estimated demand can cancel out. Only compare effort and opportunity after those checks.

### Break a tie with a smaller learning commitment
If two supported clusters remain plausible, identify the cheapest useful evidence that distinguishes them. For TalkTrip, asking relevant travellers what they expect from “restaurant Spanish” may expose a translation-versus-learning mismatch before copy production. Record what answer would lead you to keep, narrow or reject the cluster. This is research prioritisation, not a claim that a small interview estimates market demand.

### Handle dependencies visibly
A priority can be strategically attractive and operationally blocked. Put native review, product verification and required creative beside the recommendation. Assign an owner and a review trigger. When a dependency clears, reconsider the evidence rather than automatically publishing a stale draft. The final shortlist should identify ready work, investigation work and exclusions separately.

## Continue reading
- /learn/keywords/research-process/
- /learn/keywords/difficulty/
- /learn/measurement/keyword-rank-tracking/