@antoneeo/mkt-agentic-sdlc-skill 0.2.0 → 0.3.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/CHANGELOG.md +68 -18
- package/README.md +67 -45
- package/gemini-extension.json +6 -6
- package/package.json +50 -45
- package/scripts/init.js +214 -146
- package/scripts/lib.js +183 -170
- package/scripts/postinstall.js +42 -42
- package/scripts/preuninstall.js +17 -17
- package/skills/mkt-agentic-sdlc/ENFORCEMENT.md +116 -82
- package/skills/mkt-agentic-sdlc/SKILL.md +236 -201
- package/skills/mkt-agentic-sdlc/dispatch.md +87 -0
- package/skills/mkt-agentic-sdlc/elicitation.md +147 -89
- package/skills/mkt-agentic-sdlc/frameworks.md +105 -105
- package/skills/mkt-agentic-sdlc/guides.md +287 -0
- package/skills/mkt-agentic-sdlc/research.md +104 -104
- package/skills/mkt-agentic-sdlc/review.md +168 -73
- package/skills/mkt-agentic-sdlc/routing.md +100 -0
- package/skills/mkt-agentic-sdlc/scripts/mkt_check.py +677 -567
- package/skills/mkt-agentic-sdlc/scripts/sdlc_core.py +1996 -0
- package/skills/mkt-agentic-sdlc/templates.md +616 -444
- package/skills/mkt-agentic-sdlc/vision.md +245 -0
|
@@ -1,89 +1,147 @@
|
|
|
1
|
-
# Elicitation — question waves
|
|
2
|
-
|
|
3
|
-
The
|
|
4
|
-
|
|
5
|
-
|
|
6
|
-
|
|
7
|
-
|
|
8
|
-
|
|
9
|
-
|
|
10
|
-
|
|
11
|
-
|
|
12
|
-
|
|
13
|
-
|
|
14
|
-
|
|
15
|
-
|
|
16
|
-
|
|
17
|
-
|
|
18
|
-
|
|
19
|
-
|
|
20
|
-
|
|
21
|
-
|
|
22
|
-
|
|
23
|
-
|
|
24
|
-
|
|
25
|
-
|
|
26
|
-
|
|
27
|
-
|
|
28
|
-
|
|
29
|
-
|
|
30
|
-
|
|
31
|
-
|
|
32
|
-
|
|
33
|
-
|
|
34
|
-
|
|
35
|
-
|
|
36
|
-
|
|
37
|
-
|
|
38
|
-
|
|
39
|
-
|
|
40
|
-
|
|
41
|
-
|
|
42
|
-
|
|
43
|
-
|
|
44
|
-
|
|
45
|
-
|
|
46
|
-
|
|
47
|
-
|
|
48
|
-
|
|
49
|
-
|
|
50
|
-
|
|
51
|
-
|
|
52
|
-
|
|
53
|
-
|
|
54
|
-
|
|
55
|
-
|
|
56
|
-
|
|
57
|
-
|
|
58
|
-
|
|
59
|
-
|
|
60
|
-
|
|
61
|
-
|
|
62
|
-
|
|
63
|
-
|
|
64
|
-
|
|
65
|
-
|
|
66
|
-
|
|
67
|
-
|
|
68
|
-
|
|
69
|
-
|
|
70
|
-
4
|
|
71
|
-
|
|
72
|
-
|
|
73
|
-
|
|
74
|
-
|
|
75
|
-
|
|
76
|
-
the
|
|
77
|
-
|
|
78
|
-
|
|
79
|
-
|
|
80
|
-
|
|
81
|
-
-
|
|
82
|
-
|
|
83
|
-
- **
|
|
84
|
-
|
|
85
|
-
|
|
86
|
-
|
|
87
|
-
|
|
88
|
-
|
|
89
|
-
|
|
1
|
+
# Elicitation — question waves
|
|
2
|
+
|
|
3
|
+
`## The question discipline` below governs EVERY question to the user — any
|
|
4
|
+
phase, any level, inside or outside the waves. The waves are the only place the
|
|
5
|
+
process *plans* the cost of asking.
|
|
6
|
+
|
|
7
|
+
Ask for the **benefit** the user wants, never for the mechanism they imagine delivers it: a mechanism stated as a requirement forecloses every better one.
|
|
8
|
+
|
|
9
|
+
The cardinal rule: **ask only what the user uniquely owns.** Facts about their
|
|
10
|
+
business come from them; everything derivable from research comes from
|
|
11
|
+
research. Asking the user "who are your competitors and how are you
|
|
12
|
+
positioned?" is outsourcing the skill's own job — the failure mode this file
|
|
13
|
+
exists to prevent.
|
|
14
|
+
|
|
15
|
+
## The question discipline
|
|
16
|
+
|
|
17
|
+
A question outside the waves is legal only when BOTH hold:
|
|
18
|
+
|
|
19
|
+
1. **Searched first, and the search is named — with its result.** The answer is
|
|
20
|
+
not on record (MKT-VISION, ledger, session notes) and not derivable from
|
|
21
|
+
research — and the question states what you searched or researched **and what
|
|
22
|
+
it returned**. **Never fake the search**: "I looked and found nothing" that
|
|
23
|
+
names no sources and no queries is a search not run. A question research can
|
|
24
|
+
answer is research outsourced to the client — the cardinal rule's own
|
|
25
|
+
failure mode, restated as a legality test.
|
|
26
|
+
2. **It names what is blocked.** The question states the decision or fact that
|
|
27
|
+
cannot be resolved without the reply — what changes in the plan depending on
|
|
28
|
+
the answer. If nothing downstream changes, there is no question.
|
|
29
|
+
|
|
30
|
+
Never legal:
|
|
31
|
+
|
|
32
|
+
- **Generic confirmation** — "shall I proceed?", "is the plan OK so far?". The
|
|
33
|
+
gates are where approval lives; if a real risk motivates the ask, name the
|
|
34
|
+
risk and the fork — that is a blocking question and carries the form below.
|
|
35
|
+
- **Preference-fishing** — asking the client to pick among options equivalent
|
|
36
|
+
in their effect on the objective. Cheapness to undo is NOT the test.
|
|
37
|
+
- **Re-asking the record** — anything an approved MKT-VISION, a ledger entry
|
|
38
|
+
or an earlier answer already states.
|
|
39
|
+
|
|
40
|
+
**Precedence:** a choice the user uniquely owns (budget, risk appetite,
|
|
41
|
+
non-negotiables, brand red lines, approvals the gates reserve) is never
|
|
42
|
+
preference-fishing; the list above reaches choices that are *not* theirs.
|
|
43
|
+
|
|
44
|
+
**Default non-blocking.** An unknown on which no fork of the plan depends:
|
|
45
|
+
record it as a ledger **ASSUMPTION** — the native mechanism this lens already
|
|
46
|
+
has — proceed, and present the open points **batched** with the next wave or
|
|
47
|
+
the deliverable, answered by exception. Same evidence duty as a question: each
|
|
48
|
+
assumption states **what it is taken from** (a benchmark, a comparable, a
|
|
49
|
+
stated policy) and **the alternative it excludes**, and every assumption
|
|
50
|
+
reaches the batch — an assumption nobody is shown is a silent decision, and an
|
|
51
|
+
unshown ASSUMPTION row is exactly a fabricated FACT waiting to happen.
|
|
52
|
+
|
|
53
|
+
**Blocking is reserved** for three cases: proceeding under ANY assumption would
|
|
54
|
+
waste the work (the forks diverge at once); the decision is one the user
|
|
55
|
+
uniquely owns; or the doctrine itself mandates the stop. One mandating file
|
|
56
|
+
prescribes its own hand-over, and there this form does not apply:
|
|
57
|
+
`review.md`'s round cap (the artifact plus the open findings). That list is closed.
|
|
58
|
+
Every other blocking question carries the form:
|
|
59
|
+
|
|
60
|
+
- the fork: the concrete options and what each implies for the plan;
|
|
61
|
+
- the evidence: what you researched and what it leaves undecided;
|
|
62
|
+
- why no assumption survives — what work is discarded if you assume and are
|
|
63
|
+
wrong;
|
|
64
|
+
- why it is the user's call;
|
|
65
|
+
- what stays blocked until answered.
|
|
66
|
+
|
|
67
|
+
Question style (all waves):
|
|
68
|
+
- Plain language, zero marketing jargon. Not "what's your ICP?" but "describe
|
|
69
|
+
your best current customer".
|
|
70
|
+
- Max 4 questions per round; multiple rounds per wave allowed but each round
|
|
71
|
+
must be worth the interruption.
|
|
72
|
+
- Offer concrete options where a real choice exists (narrows the reply,
|
|
73
|
+
speeds the round). Use the client's structured-question facility when
|
|
74
|
+
available.
|
|
75
|
+
- **Pre-authorize "I don't know" on numeric asks.** When you ask for a figure
|
|
76
|
+
the client may never have measured (conversion rate, CAC, open rate),
|
|
77
|
+
append the permission in the question itself — "...ma se non l'avete mai
|
|
78
|
+
misurato, va bene 'non lo so'." It removes the pressure to invent a number
|
|
79
|
+
and keeps the ledger honest (an unmeasured figure becomes a researched
|
|
80
|
+
BENCHMARK or a declared ASSUMPTION, never a fabricated FACT).
|
|
81
|
+
- Every answer that is a fact becomes a `FACT` entry in the evidence ledger,
|
|
82
|
+
same discipline as researched numbers.
|
|
83
|
+
- **Seeds are allowed, analysis is not:** "which competitors do you lose
|
|
84
|
+
deals to?" is a fact the user owns (their perceived competitive set) and a
|
|
85
|
+
legitimate research seed. "What are their strengths and weaknesses?" is
|
|
86
|
+
analysis — forbidden to ask, mandatory to research.
|
|
87
|
+
|
|
88
|
+
## Wave 1 — Discovery (phase 2, before any research)
|
|
89
|
+
|
|
90
|
+
Cover, across rounds:
|
|
91
|
+
1. **Offer** — what they sell, in their words; what problem it solves.
|
|
92
|
+
2. **Price & margin** — price point(s), rough margin, discount reality.
|
|
93
|
+
3. **Current traction** — customers today (how many, what kind), revenue
|
|
94
|
+
order of magnitude, where the current customers came from.
|
|
95
|
+
4. **Market & language** — geography, target market, language for the
|
|
96
|
+
deliverables.
|
|
97
|
+
5. **Budget & horizon** — marketing budget range (a range is fine), planning
|
|
98
|
+
horizon (quarter / year / launch window).
|
|
99
|
+
6. **Team & capacity** — who will execute marketing (nobody / founder /
|
|
100
|
+
person / team / agency), hours realistically available.
|
|
101
|
+
7. **Sales motion** — how a sale happens today (self-serve, demo calls,
|
|
102
|
+
proposals, retail...), typical cycle length.
|
|
103
|
+
8. **Existing assets** — website, mailing list, social accounts and their
|
|
104
|
+
real state; brand materials.
|
|
105
|
+
9. **Constraints** — legal/regulatory limits, channels they refuse, brand
|
|
106
|
+
red lines.
|
|
107
|
+
10. **Competitor seeds** — who they lose deals to / who customers compare
|
|
108
|
+
them with (seed, not analysis).
|
|
109
|
+
|
|
110
|
+
Skip path: any item already answered by an approved MKT-VISION or earlier
|
|
111
|
+
session record is not re-asked — note where the answer came from.
|
|
112
|
+
|
|
113
|
+
## Wave 2 — Ambition (phase 5 entry, after research)
|
|
114
|
+
|
|
115
|
+
Now the user chooses with research on the table. Present the relevant
|
|
116
|
+
evidence first (one short paragraph), then ask:
|
|
117
|
+
1. **Growth vs margin** — push volume or protect profitability?
|
|
118
|
+
2. **Risk appetite** — proven channels only, or reserve an experimental slice?
|
|
119
|
+
3. **Timeline pressure** — is there a hard date (launch, season, runway)?
|
|
120
|
+
4. **Non-negotiables** — anything the objectives must include or avoid?
|
|
121
|
+
|
|
122
|
+
## Wave 3 — Execution capacity (phase 7 entry)
|
|
123
|
+
|
|
124
|
+
1. **Content capacity** — who writes/records, in which language, how often
|
|
125
|
+
realistically?
|
|
126
|
+
2. **Paid capacity** — who runs ads; any platform experience in-house?
|
|
127
|
+
3. **Follow-up capacity** — if leads double, who answers them? CRM/tooling?
|
|
128
|
+
4. **Budget flexibility** — is the budget fixed or scalable if a channel
|
|
129
|
+
proves itself?
|
|
130
|
+
|
|
131
|
+
## Reflect
|
|
132
|
+
|
|
133
|
+
Fold answers into the artifacts (MKT_VISION, OBJECTIVES, TACTICAL_PLAN) and
|
|
134
|
+
the ledger — never leave them only in chat. The written document is what the
|
|
135
|
+
next session and the reviewer read.
|
|
136
|
+
|
|
137
|
+
## Anti-patterns
|
|
138
|
+
|
|
139
|
+
- **Outsourcing analysis**: asking the user for market size, competitor
|
|
140
|
+
strengths, channel choice, or positioning. That is the skill's work.
|
|
141
|
+
- **Jargon**: ICP, CAC, SOM, funnel — translate or don't ask.
|
|
142
|
+
- **Interrogation**: more than 4 questions per round, or drip-feeding across
|
|
143
|
+
many turns instead of structured rounds.
|
|
144
|
+
- **Re-asking the recorded**: anything an approved vision or ledger FACT
|
|
145
|
+
already answers.
|
|
146
|
+
- **Collecting without folding in**: answers that never reach a document or
|
|
147
|
+
the ledger are lost to the next session.
|
|
@@ -1,105 +1,105 @@
|
|
|
1
|
-
# Framework Selection Guide
|
|
2
|
-
|
|
3
|
-
A framework is a lens, not a form. Pick per relevance; an empty section is
|
|
4
|
-
declared ("Five Forces skipped: single-competitor niche, structure analysis
|
|
5
|
-
adds nothing"), never padded. A deliverable stuffed with every framework is a
|
|
6
|
-
student essay, not a plan.
|
|
7
|
-
|
|
8
|
-
## The spine: SOSTAC
|
|
9
|
-
|
|
10
|
-
The plan's section structure is always SOSTAC (PR Smith) — the skeleton
|
|
11
|
-
professionals recognize:
|
|
12
|
-
|
|
13
|
-
| SOSTAC | Phase(s) | Output |
|
|
14
|
-
|---|---|---|
|
|
15
|
-
| **S**ituation | 2-4 (Discovery, Research, Situation Analysis) | where we are: market, competitors, customers, own assets |
|
|
16
|
-
| **O**bjectives | 5 | where we want to be: SMART + KPI tree |
|
|
17
|
-
| **S**trategy | 6 | how we get there at altitude: STP, positioning, messaging |
|
|
18
|
-
| **T**actics | 7 | with which instruments: channels, budget, funnel |
|
|
19
|
-
| **A**ction | 8 | who does what when: 90-day plan |
|
|
20
|
-
| **C**ontrol | 9 | how we know it works: measurement, kill/scale |
|
|
21
|
-
|
|
22
|
-
## Situation-phase lenses (pick, don't stack)
|
|
23
|
-
|
|
24
|
-
| Lens | Use when | Skip when |
|
|
25
|
-
|---|---|---|
|
|
26
|
-
| **SWOT** | always — the synthesis container for research findings | never skipped, but every cell must cite `[EV-nn]` entries; adjectives without evidence are deleted |
|
|
27
|
-
| **PESTEL** | regulated markets, macro-exposed sectors (energy, health, finance), international expansion | stable domestic niche — declare the skip |
|
|
28
|
-
| **Porter Five Forces** | entering a new market or industry-structure questions (margins, supplier power) | plan for an existing position in a known market |
|
|
29
|
-
| **TAM/SAM/SOM** | always for E3 | — (method rules below) |
|
|
30
|
-
|
|
31
|
-
**Market sizing rules:** bottom-up preferred (number of reachable potential
|
|
32
|
-
customers × realistic price point, from ledger entries); top-down (industry
|
|
33
|
-
report % slicing) only as a cross-check. A TAM that exists only top-down is a
|
|
34
|
-
`WARN` in review. SOM must be defendable from channel capacity, not ambition.
|
|
35
|
-
|
|
36
|
-
## Customer lenses
|
|
37
|
-
|
|
38
|
-
- **ICP (Ideal Customer Profile):** firmographic/demographic criteria table —
|
|
39
|
-
who we sell to and, as important, who we do NOT sell to.
|
|
40
|
-
- **Personas + JTBD:** at most 2-3 personas, each built from voice-of-customer
|
|
41
|
-
evidence (mined reviews, forums, support threads — see `research.md`). Each
|
|
42
|
-
persona carries: job-to-be-done, buying trigger, top objections, watering
|
|
43
|
-
holes (where they actually are). A persona trait with no VoC evidence is an
|
|
44
|
-
ASSUMPTION and is labeled as one; an invented persona is a review finding.
|
|
45
|
-
|
|
46
|
-
## Strategy lenses
|
|
47
|
-
|
|
48
|
-
- **STP:** Segmentation (from research) → Targeting (a CHOICE, with rationale
|
|
49
|
-
and explicit rejections: "segment B rejected because...") → Positioning.
|
|
50
|
-
- **Positioning (April Dunford components):** competitive alternatives (what
|
|
51
|
-
the customer does today, including "nothing"), unique attributes, value
|
|
52
|
-
(evidence-backed), best-fit segment, market category. Then the statement:
|
|
53
|
-
|
|
54
|
-
> For [segment] who [need], [name] is the [category] that [unique value],
|
|
55
|
-
> unlike [main alternative] which [limitation].
|
|
56
|
-
|
|
57
|
-
**Swap test (mandatory):** replace [name] with the top competitor. If the
|
|
58
|
-
statement still holds, the positioning does not exclude and FAILS.
|
|
59
|
-
- **Messaging house:** roof = value proposition (one sentence), pillars = 2-4
|
|
60
|
-
messages, foundation = proof points per pillar. A pillar without proof
|
|
61
|
-
points is a slogan; the review flags it.
|
|
62
|
-
|
|
63
|
-
## Objectives
|
|
64
|
-
|
|
65
|
-
- **SMART**, each objective `O1`, `O2`, ... with owner-visible target and date.
|
|
66
|
-
- **KPI tree:** north-star metric → driver metrics → channel KPIs. Every
|
|
67
|
-
objective maps into the tree; every channel KPI rolls up. The tree lives in
|
|
68
|
-
`MEASUREMENT_PLAN.md`; `mkt_check.py trace` verifies the chain.
|
|
69
|
-
- 3-5 objectives maximum. Ten objectives = no objectives.
|
|
70
|
-
|
|
71
|
-
## Tactics lenses
|
|
72
|
-
|
|
73
|
-
- **Funnel model:** AARRR (acquisition, activation, retention, referral,
|
|
74
|
-
revenue) for product-led; classic lead funnel (traffic → lead → MQL → SQL →
|
|
75
|
-
customer) for sales-led. Pick per the sales motion captured in Discovery.
|
|
76
|
-
Funnel rows must recompute (`mkt_check.py funnel`).
|
|
77
|
-
- **Sales-led / B2B funnel (important — the funnel table is shaped for
|
|
78
|
-
immediate-purchase e-commerce).** In a long-cycle B2B motion the monthly
|
|
79
|
-
funnel output is a **qualified lead / demo**, NOT a closed customer — today's
|
|
80
|
-
lead closes in 3-5 months. So: (a) put ONLY the paid click channels in the
|
|
81
|
-
`Funnel Model` table, and read its `Customers` column as *qualified
|
|
82
|
-
demos/leads* and `CAC` as *cost per qualified demo* — state the relabel
|
|
83
|
-
explicitly; (b) the primary sales-led motions (referral, content, outbound)
|
|
84
|
-
are NOT click funnels — represent their yield in a separate **Pipeline
|
|
85
|
-
build-up table** (per-source qualified leads/month vs the objective target);
|
|
86
|
-
(c) model the multi-stage sales funnel (MQL→SQL→demo→POC→won) and the
|
|
87
|
-
closed-won LAG in that pipeline section, not in the click-funnel table.
|
|
88
|
-
Forcing closed customers into a monthly click-funnel produces absurd CAC.
|
|
89
|
-
- **Channel selection matrix:** score candidate channels on ICP presence
|
|
90
|
-
(from VoC watering holes), intent level, benchmark cost `[EV-nn]`, and
|
|
91
|
-
execution capacity (from Wave 3). Choose few: 2-3 core channels beat 8
|
|
92
|
-
half-run ones. A channel chosen against the matrix needs written rationale.
|
|
93
|
-
- **Budget heuristics:** 70/20/10 (core / adjacent / experimental) as the
|
|
94
|
-
default split; deviations argued. Industry %-of-revenue norms are
|
|
95
|
-
BENCHMARKS — they enter only with a sourced ledger entry, never from memory.
|
|
96
|
-
- **4P/7P:** use as a completeness checklist on the tactical plan (price,
|
|
97
|
-
place and product decisions the plan silently makes), not as a section.
|
|
98
|
-
|
|
99
|
-
## Control
|
|
100
|
-
|
|
101
|
-
- Review cadence: weekly channel KPIs, monthly objective review, quarterly
|
|
102
|
-
strategy review.
|
|
103
|
-
- **Kill/scale criteria per channel, set BEFORE launch:** "kill if CAC > X
|
|
104
|
-
after spend Y; scale if CAC < Z at volume W" — thresholds justified by
|
|
105
|
-
ledger benchmarks. A plan without kill criteria is a brochure (review BLOCK).
|
|
1
|
+
# Framework Selection Guide
|
|
2
|
+
|
|
3
|
+
A framework is a lens, not a form. Pick per relevance; an empty section is
|
|
4
|
+
declared ("Five Forces skipped: single-competitor niche, structure analysis
|
|
5
|
+
adds nothing"), never padded. A deliverable stuffed with every framework is a
|
|
6
|
+
student essay, not a plan.
|
|
7
|
+
|
|
8
|
+
## The spine: SOSTAC
|
|
9
|
+
|
|
10
|
+
The plan's section structure is always SOSTAC (PR Smith) — the skeleton
|
|
11
|
+
professionals recognize:
|
|
12
|
+
|
|
13
|
+
| SOSTAC | Phase(s) | Output |
|
|
14
|
+
|---|---|---|
|
|
15
|
+
| **S**ituation | 2-4 (Discovery, Research, Situation Analysis) | where we are: market, competitors, customers, own assets |
|
|
16
|
+
| **O**bjectives | 5 | where we want to be: SMART + KPI tree |
|
|
17
|
+
| **S**trategy | 6 | how we get there at altitude: STP, positioning, messaging |
|
|
18
|
+
| **T**actics | 7 | with which instruments: channels, budget, funnel |
|
|
19
|
+
| **A**ction | 8 | who does what when: 90-day plan |
|
|
20
|
+
| **C**ontrol | 9 | how we know it works: measurement, kill/scale |
|
|
21
|
+
|
|
22
|
+
## Situation-phase lenses (pick, don't stack)
|
|
23
|
+
|
|
24
|
+
| Lens | Use when | Skip when |
|
|
25
|
+
|---|---|---|
|
|
26
|
+
| **SWOT** | always — the synthesis container for research findings | never skipped, but every cell must cite `[EV-nn]` entries; adjectives without evidence are deleted |
|
|
27
|
+
| **PESTEL** | regulated markets, macro-exposed sectors (energy, health, finance), international expansion | stable domestic niche — declare the skip |
|
|
28
|
+
| **Porter Five Forces** | entering a new market or industry-structure questions (margins, supplier power) | plan for an existing position in a known market |
|
|
29
|
+
| **TAM/SAM/SOM** | always for E3 | — (method rules below) |
|
|
30
|
+
|
|
31
|
+
**Market sizing rules:** bottom-up preferred (number of reachable potential
|
|
32
|
+
customers × realistic price point, from ledger entries); top-down (industry
|
|
33
|
+
report % slicing) only as a cross-check. A TAM that exists only top-down is a
|
|
34
|
+
`WARN` in review. SOM must be defendable from channel capacity, not ambition.
|
|
35
|
+
|
|
36
|
+
## Customer lenses
|
|
37
|
+
|
|
38
|
+
- **ICP (Ideal Customer Profile):** firmographic/demographic criteria table —
|
|
39
|
+
who we sell to and, as important, who we do NOT sell to.
|
|
40
|
+
- **Personas + JTBD:** at most 2-3 personas, each built from voice-of-customer
|
|
41
|
+
evidence (mined reviews, forums, support threads — see `research.md`). Each
|
|
42
|
+
persona carries: job-to-be-done, buying trigger, top objections, watering
|
|
43
|
+
holes (where they actually are). A persona trait with no VoC evidence is an
|
|
44
|
+
ASSUMPTION and is labeled as one; an invented persona is a review finding.
|
|
45
|
+
|
|
46
|
+
## Strategy lenses
|
|
47
|
+
|
|
48
|
+
- **STP:** Segmentation (from research) → Targeting (a CHOICE, with rationale
|
|
49
|
+
and explicit rejections: "segment B rejected because...") → Positioning.
|
|
50
|
+
- **Positioning (April Dunford components):** competitive alternatives (what
|
|
51
|
+
the customer does today, including "nothing"), unique attributes, value
|
|
52
|
+
(evidence-backed), best-fit segment, market category. Then the statement:
|
|
53
|
+
|
|
54
|
+
> For [segment] who [need], [name] is the [category] that [unique value],
|
|
55
|
+
> unlike [main alternative] which [limitation].
|
|
56
|
+
|
|
57
|
+
**Swap test (mandatory):** replace [name] with the top competitor. If the
|
|
58
|
+
statement still holds, the positioning does not exclude and FAILS.
|
|
59
|
+
- **Messaging house:** roof = value proposition (one sentence), pillars = 2-4
|
|
60
|
+
messages, foundation = proof points per pillar. A pillar without proof
|
|
61
|
+
points is a slogan; the review flags it.
|
|
62
|
+
|
|
63
|
+
## Objectives
|
|
64
|
+
|
|
65
|
+
- **SMART**, each objective `O1`, `O2`, ... with owner-visible target and date.
|
|
66
|
+
- **KPI tree:** north-star metric → driver metrics → channel KPIs. Every
|
|
67
|
+
objective maps into the tree; every channel KPI rolls up. The tree lives in
|
|
68
|
+
`MEASUREMENT_PLAN.md`; `mkt_check.py trace` verifies the chain.
|
|
69
|
+
- 3-5 objectives maximum. Ten objectives = no objectives.
|
|
70
|
+
|
|
71
|
+
## Tactics lenses
|
|
72
|
+
|
|
73
|
+
- **Funnel model:** AARRR (acquisition, activation, retention, referral,
|
|
74
|
+
revenue) for product-led; classic lead funnel (traffic → lead → MQL → SQL →
|
|
75
|
+
customer) for sales-led. Pick per the sales motion captured in Discovery.
|
|
76
|
+
Funnel rows must recompute (`mkt_check.py funnel`).
|
|
77
|
+
- **Sales-led / B2B funnel (important — the funnel table is shaped for
|
|
78
|
+
immediate-purchase e-commerce).** In a long-cycle B2B motion the monthly
|
|
79
|
+
funnel output is a **qualified lead / demo**, NOT a closed customer — today's
|
|
80
|
+
lead closes in 3-5 months. So: (a) put ONLY the paid click channels in the
|
|
81
|
+
`Funnel Model` table, and read its `Customers` column as *qualified
|
|
82
|
+
demos/leads* and `CAC` as *cost per qualified demo* — state the relabel
|
|
83
|
+
explicitly; (b) the primary sales-led motions (referral, content, outbound)
|
|
84
|
+
are NOT click funnels — represent their yield in a separate **Pipeline
|
|
85
|
+
build-up table** (per-source qualified leads/month vs the objective target);
|
|
86
|
+
(c) model the multi-stage sales funnel (MQL→SQL→demo→POC→won) and the
|
|
87
|
+
closed-won LAG in that pipeline section, not in the click-funnel table.
|
|
88
|
+
Forcing closed customers into a monthly click-funnel produces absurd CAC.
|
|
89
|
+
- **Channel selection matrix:** score candidate channels on ICP presence
|
|
90
|
+
(from VoC watering holes), intent level, benchmark cost `[EV-nn]`, and
|
|
91
|
+
execution capacity (from Wave 3). Choose few: 2-3 core channels beat 8
|
|
92
|
+
half-run ones. A channel chosen against the matrix needs written rationale.
|
|
93
|
+
- **Budget heuristics:** 70/20/10 (core / adjacent / experimental) as the
|
|
94
|
+
default split; deviations argued. Industry %-of-revenue norms are
|
|
95
|
+
BENCHMARKS — they enter only with a sourced ledger entry, never from memory.
|
|
96
|
+
- **4P/7P:** use as a completeness checklist on the tactical plan (price,
|
|
97
|
+
place and product decisions the plan silently makes), not as a section.
|
|
98
|
+
|
|
99
|
+
## Control
|
|
100
|
+
|
|
101
|
+
- Review cadence: weekly channel KPIs, monthly objective review, quarterly
|
|
102
|
+
strategy review.
|
|
103
|
+
- **Kill/scale criteria per channel, set BEFORE launch:** "kill if CAC > X
|
|
104
|
+
after spend Y; scale if CAC < Z at volume W" — thresholds justified by
|
|
105
|
+
ledger benchmarks. A plan without kill criteria is a brochure (review BLOCK).
|