Direct answer: start with one selected niche, write the observable Audience job it serves, then map distinct Promise role entries for feed, subscription, PPV and custom surfaces. For each entry define the deliverable, evidence, Repeatability, workload, boundary, and handoff. Remove rows that duplicate another promise or cannot be delivered consistently.
- Feed row: public value, proof of relevance and the next logical handoff.
- Subscription row: repeatable access promise, cadence and sustainable workload.
- PPV row: distinct optional deliverable, production demand and clear boundary.
- Custom row: request scope, capacity limit, turnaround assumption and exclusion rule.
This worksheet starts with one selected niche. It does not select the niche, set prices, write PPV messages, or build a publishing calendar. If the niche premise still needs evidence, complete the niche validation scorecard before mapping offers.
The map is not a requirement to use all four surfaces. A blank or “not applicable” row is better than a weak offer invented to fill a box. Its purpose is to make the relationship between audience interest and deliverable value explicit.
Freeze the selected niche statement
Write the niche as audience interest, creator perspective, repeatable value, and boundary. Add the version date and evidence source. Avoid a label so broad that almost any content fits, or so narrow that the creator cannot sustain it.
List the public words and direct audience questions that supported the selection. Keep observations distinct from assumptions. “Several people asked how the set was prepared” is evidence; “they all want behind-the-scenes access” is an interpretation that still needs testing.
Do not modify the niche while completing the map. If the exercise exposes a weak premise, return to validation and issue a new version rather than quietly changing the input halfway through.
Define one Audience job at a time
An Audience job describes progress someone seeks from the niche: discover a style, understand a process, follow continuity, see a deeper treatment of a theme, choose a bounded variation, or request an individual deliverable. Use language grounded in observed questions and behaviour.
Separate a job from a format. “Watch a short video” describes media. “See how the look develops from setup to final result” describes progress that several formats might support. Starting with the job prevents the map from becoming a list of files.
Give each job an evidence note and confidence label. If evidence is thin, mark it as a test question. Do not disguise an internal idea as an established audience need.
Assign a Promise role to every proposed row
A Promise role states what kind of value the row provides. Useful working roles include discovery, orientation, continuity, depth, completion, choice, and individualisation. Adapt the labels to the niche and define each one.
Write the promise in plain language and list what is outside it. A recurring feed post may promise a reliable glimpse into the niche, while a defined PPV item may promise a complete extended treatment. The custom row may provide bounded individual choice without implying unlimited access.
Check that the deliverable proves the promise. If the row says “complete process,” the asset cannot stop before the outcome. If it says “weekly continuity,” the workload and archive must support that cadence.
Map the feed role
The feed row should explain how public or included posts help someone recognise the niche and understand what continues. Record themes, approved formats, expected context, reuse rules, and the boundary between an introduction and a complete deliverable.
Avoid making the feed a random leftovers channel. Its promise should connect to the same selected niche even when individual posts vary. Note which audience job each recurring feed pattern serves.
Mark frequency as a handoff, not a decision here. The content strategy planning guide can turn approved roles into a production plan after the map is complete.
Map the subscription role
Describe the continuing value included in the subscription: access boundary, recurring experience, navigation, and what a subscriber can reliably expect. Keep the statement factual and supportable. Do not promise an exact cadence unless the separate capacity plan approves it.
Compare subscription and feed rows. If they are identical, explain why both exist or revise the promise. The distinction should not depend on vague adjectives. It should be observable in access, depth, continuity, or included experience.
List dependencies such as a content library, recurring series, or onboarding explanation. A promise with an unowned dependency is not ready to map as active.
Map the PPV role
The PPV row identifies which audience job needs a bounded, separately unlockable item and why the asset is meaningfully complete. Record asset family, promise, typical scope, production dependency, and evidence question. Do not add price or final campaign copy.
Check that PPV does not remove the essential value already promised in the subscription row. The roles can differ by depth, completion, format, or optional experience, but the base promise should remain understandable.
Once the row is approved, use the PPV content ideas planner to develop specific concepts. This map ends at the role and boundary.
Map the custom role only when bounded
A custom row should define eligible choices, excluded requests, input needed, fulfilment steps, review, lead-time handoff, active-slot dependency, and stop state. “Anything you want” is not an operational offer description.
Connect customisation to the selected niche. The role may let someone choose from approved variations within the creator's existing capability. It should not become an unrelated request channel that erodes the niche boundary.
Mark individual work as capacity-dependent. The map can identify the role, but a separate capacity process decides whether any slot is available.
Score Repeatability and workload
Repeatability asks whether the creator can deliver the promise again with consistent quality, not whether the exact asset can be copied forever. Use labels such as reusable, repeatable with variation, limited-run, or individual. Define the evidence for each.
Record preparation, production, review, delivery, and communication load. A row can be attractive conceptually but unsuitable as a recurring promise when its dependencies exceed available resources.
Flag single points of failure: one unavailable location, one unfinished archive, one collaborator, or one fragile process. A map should expose those dependencies before a promise becomes active.
Run the gap and conflict review
Read across each Audience job. Does at least one appropriate surface support it, or is the job outside the current offer system? Then read down each surface. Does every row connect to the niche, or has generic content entered the map?
Check duplication, contradiction, unsupported escalation, missing boundary, excessive individual workload, and promises without evidence. A gap can be accepted. Record “not served now” rather than forcing a deliverable.
Version the map when a role changes. Preserve what earlier subscribers were told and route fulfilment changes through the relevant operations owner.
Use colour or status words only after defining them. “Ready” can mean the promise, asset family, owner, and dependency are all confirmed. “Test” can mean the audience job has some evidence but the deliverable is not yet established. “Blocked” should name the missing input. Avoid a vague amber state that every reviewer interprets differently.
Ask whether each gap matters to the selected niche. An empty custom row may be intentional when individual work does not fit the creator's boundary. A missing continuity role may matter when recurring development is the core audience job. Prioritise only gaps tied to evidence and creator capability.
Test the map with concrete examples
Choose one real, approved asset or completed deliverable for every active row. A reviewer should identify the audience job, promise, included boundary, and surface from that example. If an example fits several rows equally well, the roles may be duplicated or too vague.
Then test a plausible request that sits outside the boundary. The reviewer should know whether to decline it, redirect it to another existing row, or mark it as research evidence. A strong map clarifies exclusions as well as included value.
Run a trace from niche evidence to Audience job, Promise role, deliverable, dependency, and owner. Every step should have a source. A broken trace means the offer is still an internal idea and should remain in draft.
Finally, run the trace backwards from each active deliverable. If the team cannot explain which niche interest and audience job it serves, the row may be generic inventory rather than part of this map. Remove it or place it in a different planning system.
Copy the Niche-to-offer map
Columns: niche version; evidence source; Audience job; Promise role; surface; deliverable; included boundary; excluded boundary; evidence note; Repeatability; workload; dependencies; status; owner; next handoff; and review date.
Approval questions: is the niche frozen, is the job evidence-led, does the deliverable prove the promise, is the role distinct, can the creator repeat it, are dependencies owned, and is every unavailable row marked honestly?
Add a decision column with keep, revise, test, block, or remove. Each decision needs an owner and review date. “Test” also needs a stated question and a bounded sample. “Block” needs the dependency that will clear it. This turns the map into a controlled handoff without turning it into a calendar.
Limitations and sources
Limitations: the map describes a proposed relationship between one niche and existing capabilities. It does not establish demand, recommend monetisation, or predict which surface will perform. Audience jobs and roles require later validation.
The mapping approach adapts GOV.UK guidance on experience maps and evidence-led user needs. The fields and promise-role taxonomy are original SirenCY editorial tools.