codexkit-brand-positioning-canvas

# Brand Positioning Canvas ## Purpose Create a positioning foundation that sharpens how a brand should show up and what it should claim. ## When to use - A product or brand needs sharper differentiation. - A campaign or launch lacks a strategic messaging base. - A team needs shared language for audience, value, and proof. ## When not to use - The request is only to rewrite one headline or ad line. - No audience, category, or competitor context exists at all. ## Inputs - product or service offer - target audience and known customer signals - competitors or substitutes - proof points, credibility assets, and brand tone - business goals for the positioning work ## Procedure 1. Define the audience and the job they are trying to get done. 2. Clarify the category and what alternatives customers compare against. 3. Surface the few differentiators that are both meaningful and provable. 4. Translate that into a positioning statement, brand voice, and message pillars. 5. State what the brand is not, to avoid mushy positioning. 6. Flag claims that lack proof or strategic focus. ## Output - positioning canvas - target audience and JTBD summary - differentiators and reasons to believe - tone and message pillars - anti-positioning or "not us" guardrails ## Definition of done - Differentiation is explicit and supportable. - The output can guide messaging beyond one campaign. - The team can see what claims to avoid. ## Examples - "Help us position our B2B product against two bigger competitors." - "Build a positioning canvas we can use before rewriting the website." ## Quality Criteria - [ ] All claims reference specific frameworks, standards, or quantifiable data - [ ] Content matches the stated audience's expertise level - [ ] Recommendations are actionable — each includes a concrete next step - [ ] No unsupported assertions or generic filler language ## Verification (4C) | Check | Question | |-------|----------| | **Correctness** | Do referenced frameworks and standards match their official definitions? | | **Completeness** | Are all key concepts covered without significant gaps for the stated audience? | | **Context-fit** | Would this be useful for someone new to this domain, or is it too advanced/too basic? | | **Consequence** | If a stakeholder acted on this immediately, what could they misinterpret? | ## Edge Cases - **Conflicting frameworks** — State which framework takes precedence and why. Document the trade-off explicitly. - **Rapidly changing domain** — Note information currency date. Flag sections likely to need updates. - **Audience has mixed expertise levels** — Provide a glossary and mark advanced sections as optional. ## Changelog - v1.0.0 — Initial release