Design the repeatable methodology
28 primitives in this stage — 28 skills. Concept-stage catalogue, kept vendor-agnostic.
Extract the buyer's real question from discovery material →
"I keep answering the question they asked, but now I can see it wasn't the question they actually had."
Articulate the observable success outcome from the buyer's view →
"Once I could say exactly what 'done' looked like in the buyer's eyes, every design choice downstream became obvious."
Draft the in-scope / out-of-scope / disclaimed boundary →
"Having a written boundary meant I stopped fighting scope creep in every kickoff call — I just pointed to the document."
Stress-test the boundary against awkward edge cases →
"Every edge case I didn't pre-answer came back as a client conversation I had to have on the fly — this skill forces me to answer them first."
Choose the artefact form and a memorable name →
"A good name does half the selling — it tells the buyer exactly what they're getting before they read a word of the proposal."
Sketch the top-level structure and define the quality bar →
"Sketching the structure before building the templates stopped me designing into a dead end three steps later."
Write the buyer-facing deliverable promise statement →
"Writing the promise statement forced me to compress everything I knew into one paragraph — and that paragraph became my best sales tool."
Check the promise stands alone without verbal explanation →
"If I had to explain it every time, it wasn't a promise — it was a starting point for a conversation I kept having to have."
Draft the engagement phase sequence →
"Before I had a phase map, every project felt bespoke. Once I had it, I was running the same play every time."
Derive the input specification per step →
"Knowing exactly what each step needs before it starts meant I stopped discovering mid-project that a critical input was missing."
Set minimum-completeness gates for inputs →
"Without explicit gates, I'd always convince myself the data was good enough — and pay for it later in the output."
Draft the ordered step checklist →
"Writing every step as an action meant the person following it never had to figure out what to do — they just did the next thing."
Test checklist executability from a newcomer's view →
"I thought the checklist was clear until I read it as if I didn't already know the method — half the steps assumed knowledge I'd forgotten I had."
Design handoff and review-gate logic →
"Once I'd mapped the handoffs on paper, the places where work disappeared into a grey zone became impossible to ignore."
Stress-test escalation and tolerance coverage →
"The failure case I didn't plan for always arrived at a handoff — this forced me to close the gaps before the pilot did it for me."
Propose a candidate scoring-dimension set from the deliverable promise →
"Having the right dimensions made scoring feel like observation — having the wrong ones made it feel like guessing."
Check the dimension set for gaps and overlap against the promise →
"Two dimensions that overlap don't double your coverage — they halve your clarity, and the scoring suffers every time."
Draft scale and anchor descriptions for a dimension →
"Vague anchors meant every analyst scored the same subject differently and none of us knew it — concrete anchors made disagreement visible and fixable."
Stress-test adjacent-level boundaries with synthetic cases →
"The boundary cases I didn't find at design time always showed up on a real client — and then I had to decide on the fly under pressure."
Map evidence sources and signals to each dimension →
"Mapping sources to dimensions before the first live case meant I'd already solved the 'where do I look for this?' problem before it became a time pressure."
Generate the deliverable structure and section skeleton →
"Once I had the skeleton, I stopped reinventing the document every delivery and started filling it in — that's when output consistency actually happened."
Review the assembled tool for analyst usability and correctness →
"Building the tool and using the tool are two different experiences — this is the moment you find out which one you actually made."
Prep the pilot run with evidence-capture instrumentation →
"I ran three pilots before I started instrumenting them — by the time I'd noticed a pattern, I had no notes to point to."
Log step-level friction during the run →
"The friction I noticed and didn't write down was friction I had to rediscover the next time — logging it in the moment was the only way to actually learn from the run."
Diagnose breakpoint root cause and triage →
"Fixing symptoms felt like progress until I diagnosed the same root cause appearing in three different outputs — then one fix resolved all three."
Rewrite the method step, template, or rubric →
"The diagnosis told me what was broken; this is where I actually fixed it — not at the symptom but at the artefact that produced the symptom."
Check the fix resolved the breakpoint without regressions →
"A fix that closed one problem and opened another wasn't a fix — this pass is how I found out which kind I'd made."
Make the go/no-go rollout call →
"Every method change needs an explicit adoption decision — without one, you never know if you're running the old version or the new one."