PulseCheck — Product Design Spec
Author: Yannic Arnold, Senior Consultant, Campana & Schott Date: April 7, 2026 Status: Ready for Build Day Build Day Team: TBD (1 builder + 4 non-builder roles)
---
1. Problem Statement
Change management is the most consistently under-delivered discipline in consulting. Not because consultants don't know the frameworks — they do. Because the gap between knowing ADKAR and applying it systematically, in real time, on a live engagement is enormous. Here is what that gap actually costs.
1. ADKAR knowledge stays in the consultant's head and never enters the work systematically. A consultant trained in ADKAR applies it on the fly, based on instinct, between calls. There is no moment in the actual workflow where the framework surfaces and says: this situation, right now, is a Desire problem — not a Knowledge problem. As a result, the wrong interventions get deployed. Training runs for people who already understand the change but don't want it. The training fixes nothing. The resistance compounds.
2. Resistance signals are behavioral, not self-reported — and no tool captures them. The first sign something is off is never a survey result. It is slower email responses. A stakeholder who suddenly brings twelve people to a call. Someone who "pretends" not to know how to complete a process they completed last week. These are ADKAR signals — Desire dropping, coalitions forming, Ability resistance masquerading as a Knowledge gap — but they exist nowhere in writing. No current tool captures them. The consultant reads them and carries them, unstructured, in their head.
3. The project sponsor is simultaneously the change champion and the hidden blocker. Directors and VPs who own transformation projects frequently say the right things in steering committees and do the wrong things in team meetings. They tell Finance "this is mostly a cost play." They tell Operations "nothing really changes for your team." They tell the all-hands "this is the most important thing we've ever done." Three different messages, one confused organization. The consultant knows this is happening. Surfacing it diplomatically, without making the sponsor defensive, is one of the hardest moves in change management — and it currently has no structure, no artifact, and no support behind it.
4. Change management is the neglected layer of every project — and the buyer knows it. The Director or VP who sponsors a transformation is not a change management expert. They have a product or a project. Change management is something they know they need and are not sure they're getting. Between quarterly pulse surveys, they are flying blind. They do not know where resistance is building until it has already stalled adoption. By then, the go-live has slipped or the rollout has failed quietly.
The deeper structural problem: change management is practiced as an episodic discipline — a survey here, a training there, an impact assessment at kickoff. But adoption is a continuous signal that lives in the artifacts consultants already produce every week. The data exists. Nobody is reading it systematically. PulseCheck reads it.
---
2. Product Concept
One-Sentence Pitch
PulseCheck is an AI-powered change intelligence layer that reads the artifacts consultants already produce, maps behavioral signals to the ADKAR framework in real time, and tells the consultant — and the project sponsor — exactly where adoption is at risk and what to do about it.
How It Works
Step 1 — Artifact upload (the consultant). After a meeting, the consultant uploads or pastes an artifact that already exists: meeting notes, an email thread, a training attendance log, an executive communication, an impact statement, a weekly status update. No new documents created. No extra work.
Step 2 — The 90-second observation debrief (the consultant). Immediately after uploading, PulseCheck prompts: "Anything you observed in the room that isn't in the transcript?" The consultant picks the stakeholders who were present, writes one sentence of raw observation, and selects their read from a dropdown: Disengaging / Resistant / Uncertain / Positively surprised / Performatively aligned. Ninety seconds. The consultant's trained judgment enters the system.
Step 3 — ADKAR inference (the AI). PulseCheck's inference engine reads both the artifact and the observation log. It extracts named stakeholders, maps language patterns and behavioral signals to ADKAR stages, assigns a confidence score, and quotes the specific evidence that drove the inference. It tracks each stakeholder's position over time and flags trend changes.
Step 4 — Consultant dashboard (consultant-only). The consultant sees a full ADKAR map: each stakeholder, their current stage, trend direction, and the raw observation log. The Intervention Queue surfaces prioritized recommended actions, each linked to the artifact evidence that generated it. The Sponsor Mirror shows the consultant where the sponsor's communications are inconsistent with the change narrative — framed as coaching ammunition.
Step 5 — Sanitized sponsor view (sponsor-facing). The AI generates a plain-language version for the project sponsor. ADKAR stages are named explicitly but immediately translated: "Maria Chen is at Desire — she understands the change but isn't convinced it's worth it yet." Risk levels are color-coded. Recommended actions are specific and non-technical. The sponsor sees the framework, understands it without training, and gets an actionable picture of where their project stands on adoption.
The Strategic Play
PulseCheck is deployed engagement by engagement, but the data compounds across engagements. After six months on one client transformation, the signal library is tuned to that organization's language patterns, the stakeholder history is irreplaceable, and the intervention track record shows what worked. The client does not rip that out.
The longer play: C&S licenses PulseCheck to clients as a standing capability across all their transformation programs — not just C&S engagements. Every consulting firm working with that client reports adoption signals through PulseCheck. C&S built the standard. C&S collects the license revenue.
---
3. Target Buyer
Primary Buyer: The Project Sponsor (Director, Senior Director, or VP)
This is not a change management expert or an HR leader. This is a business leader who owns a transformation — a product rollout, a system implementation, an operating model redesign — and views change management as a necessary component they are not sure they are getting. Their pain is simple: they do not know if their project is going to land until it is too late to course-correct.
What They Do Today
- Commission a pulse survey every 6–8 weeks. Wait for results. Act on findings that are already 6 weeks stale.
- Rely on the consultant's verbal update in the weekly steering committee. Take it on faith.
- Find out resistance has hardened when a go-live slips or a business unit refuses to adopt the new process.
- Spend no structured time on adoption risk between major milestones. It is not on their dashboard.
The cost of this approach: one delayed go-live on a mid-size transformation typically costs $200k–$500k in extended consulting fees, lost productivity, and rework. The sponsor is not thinking about PulseCheck's monthly fee in isolation — they are thinking about whether their project is going to succeed.
Why They Would Pay
- Continuous adoption signal instead of quarterly pulse surveys. They stop flying blind between milestones.
- A structured view of where resistance is building — by name, by team, by ADKAR stage — before it becomes a crisis.
- A plain-language dashboard they can forward to their own leadership as proof that change management is being managed, not just performed.
Secondary Beneficiary: The Consultant
PulseCheck makes the consultant dramatically more effective. They walk into every stakeholder conversation knowing exactly where that stakeholder is on the ADKAR curve. They stop deploying training for people with a Desire problem. They have a structured, evidence-backed artifact when they need to coach a sponsor about their own behavior. This is not what gets the PO signed — but it is what makes the demo undeniable and what drives word-of-mouth across the practice.
---
4. Architecture
4.1 Input Layer — Artifact Ingestion + Observation Portal
Two input channels. Neither requires the client or any stakeholder to do anything new.
Channel 1: Artifact upload. The consultant pastes or uploads artifacts they already produce.
| Artifact Type | ADKAR Signal It Carries |
|---|---|
| Email threads | Response latency → Desire signal.<br />Hedging language ("that's an interesting approach") → masked resistance. |
| Meeting notes / transcripts | Questions asked → Knowledge gaps.<br />Who was in the room → coalition signals. What was not said → disengagement. |
| Training attendance logs | No-shows → Desire / Awareness gap.<br />Repeat questions → Ability gap. |
| Executive communications | Message consistency vs. change narrative → sponsor alignment signal. |
| Impact statements | Framing quality → Awareness depth.<br />Tone → Desire priming. |
| Weekly status updates | Risk language patterns → systemic vs. individual blockers. |
Channel 2: 90-second observation debrief. Triggered automatically after each artifact upload. Three fields:
- Who was present — stakeholder names pre-populated from the engagement roster
- What you observed — one free-text sentence (non-verbal cues, tone, body language, what was not said)
- Your read — dropdown: Disengaging / Resistant / Uncertain / Positively surprised / Performatively aligned
The consultant's practitioner judgment enters the system here. The AI maps it to ADKAR alongside the artifact signals. This is the layer that captures what transcripts cannot.
4.2 Transform Layer — The ADKAR Inference Engine (Core IP)
A Claude-powered pipeline running at low temperature (0.2–0.3) for consistency. The system prompt anchors four things that constitute the defensible intellectual property:
The signal library. A practitioner-built taxonomy of behavioral signals mapped to ADKAR stages. Hedging language patterns, deflection phrases, attendance behaviors, communication latency signals. Built from real change management expertise — not generic NLP, but change-management-specific pattern recognition. Improves with every engagement.
Stakeholder entity resolution. Named stakeholders are tracked across artifacts. The system builds a longitudinal ADKAR profile for each person — not a single inference but a trend model across every artifact and observation submitted. A stakeholder whose Desire signal drops three weeks before go-live is flagged as a risk before the sponsor even notices.
Two-layer output schema. Every inference produces two outputs: (1) a raw consultant-facing output including the evidence excerpt, confidence score, and ADKAR mapping; and (2) a sanitized sponsor-facing output in plain language with the ADKAR stage named, translated, and accompanied by a specific recommended action. The AI handles the translation between layers.
The Sponsor Mirror sub-module. A dedicated prompt that ingests the agreed change narrative (pasted in at engagement setup) and all uploaded executive communications, then surfaces gaps: what the change story says vs. what the sponsor actually communicated to a specific audience. Output is framed as coaching ammunition, never as a report card.
RAG is used to anchor the signal library and the change narrative document so they persist across sessions without re-prompting. The system prompt enforces consistent output structure — stakeholder name, ADKAR stage, signal type, evidence quote, confidence, recommended action — so the display layer never has to handle unstructured output.
4.3 Display Layer — Two Views
Consultant Dashboard (private)
- Stakeholder ADKAR Map: Each stakeholder as a row. Five ADKAR columns. Color-coded signal strength. Trend arrow. Last artifact timestamp. Raw observation log accessible per stakeholder.
- Intervention Queue: Prioritized recommended actions. Each linked to the artifact evidence that triggered it. Consultant can accept, modify, or dismiss. Dismissed recommendations are logged for audit.
- Sponsor Mirror: Side-by-side view of the change narrative vs. sponsor communications. Gap highlights. Framed as coaching prep. Never auto-distributed.
- Artifact Timeline: Every upload logged chronologically with extracted signals. Full audit trail of how ADKAR profiles evolved.
Sponsor View (sanitized, shareable)
ADKAR stages named explicitly with plain-English translation immediately below. Risk levels color-coded. Specific recommended actions. Designed for a Director or VP who has never taken a Prosci course. Example:
| Stakeholder | ADKAR Stage | Risk | Recommended Action |
|---|---|---|---|
| Maria Chen, Finance Lead | Desire | 🟡 Amber | Schedule 1:1 focused on what's in it for her team. She understands the change but isn't convinced it's worth it yet. |
| James Okafor, Ops Director | Knowledge | 🟢 Green | On track. Reinforce with process walkthrough before go-live to convert Knowledge into Ability. |
| Sandra Reeves, IT Lead | Awareness | 🔴 Red | Awareness has not landed. Direct briefing from project sponsor required before next workstream session. |
The framework is visible but never assumed. The sponsor learns ADKAR passively over time, just by using the view. After three months they are fluent in the language without a training course.
4.4 Tech Stack (Hackathon)
| Component | Approach |
|---|---|
| Frontend | Next.js or HTML/Tailwind — whatever the builder moves fastest in. Two-panel layout: consultant dashboard left, sponsor view right. |
| Backend | Lightweight Node or Python API. Receives artifact text + observation log fields. Calls Claude. Returns structured ADKAR inference JSON. |
| AI Layer | Claude API. System prompt anchors signal library, output schema, and change narrative. Low temperature (0.2–0.3) for consistency. |
| Storage | SQLite or flat JSON. Stakeholder profiles, artifact history, observation logs, inference outputs. |
| Deployment | Vercel, Replit, or local with ngrok. Shareable URL for demo. No auth required for hackathon. |
---
5. Hackathon Execution Plan
Timeline
| Time | Focus | Milestone |
|---|---|---|
| Kickoff | Discovery + setup | Builder scaffolds project. Non-builders write three demo artifacts: (1) an email thread with resistance signals, (2) meeting notes with coalition-building behavior, (3) a sponsor all-hands with message inconsistency. Change narrative document drafted. |
| +30 min | Input layer | Artifact upload form working. Observation debrief fields functional. Text pasting into Claude returning raw ADKAR inference. Ugly but working. |
| +60 min | Transform layer | Structured JSON output: stakeholder name, ADKAR stage, signal type, evidence quote, recommended action. Sponsor Mirror prompt running against demo artifacts. |
| +90 min | Consultant dashboard | Stakeholder ADKAR Map rendering for all three demo stakeholders. Intervention Queue showing at least two recommendations with evidence links. Proof of life. |
| +120 min | Sponsor view | Sanitized sponsor view rendering. ADKAR stages named with plain-English translation. Color-coded risk. Sponsor Mirror gap view visible in consultant dashboard. |
| +150 min | Polish + rehearsal | Narrator rehearses full walkthrough on live platform. Client Advocate stress-tests sponsor view. Market Analyst finalizes ROI numbers. |
| Pitch | Live demo | Real inference on pre-loaded demo artifacts. Judges interact with live URL. |
Critical Risk & Fallback
Critical risk: The inference quality on demo day depends entirely on the quality of the three pre-written artifacts. If the artifacts are too clean or too obvious, the ADKAR inference is unimpressive. If they are too ambiguous, the inference is wrong and the demo falls apart.
Mitigation: Non-builders spend the first 30 minutes writing artifacts, not watching the builder. The artifacts are the demo's raw material. They must contain realistic, nuanced signals — hedging language, attendance patterns, message drift — that the inference engine can visibly detect.
Fallback: If the full pipeline is not working by +90 minutes, the builder focuses exclusively on the consultant ADKAR Map for one stakeholder with one artifact. The sponsor view becomes a static mockup in the pitch deck. One stakeholder, one artifact, one perfect inference beats three stakeholders half-working. The Narrator scripts around it.
Role Allocation
| Role | Build Day Responsibility |
|---|---|
| Builder | Owns the full technical stack. Scaffolds input form, wires Claude API, builds display views. Makes cut decisions when time gets tight. |
| Product Owner | Writes the three demo artifacts — the most important non-builder job. Decides what gets cut at each time checkpoint. Maintains the demo script as the product evolves during the build. |
| Client Advocate | Plays the skeptical Director or VP throughout the build. Stress-tests the sponsor view at every iteration: "Would a non-change-management VP trust this dashboard?" Pushes back on anything that feels like a tech demo instead of a client tool. |
| Narrator | Builds the pitch around the live demo. Scripts the walkthrough: start at sponsor view, drill into one stakeholder, show the raw-artifact-to-ADKAR-inference transformation, open the Sponsor Mirror. Rehearses from +120 min onward. |
| Market Analyst | Builds the business case. Quantifies the cost of a delayed go-live. Prepares the ROI calculator. Develops competitive positioning. Prepares to defend the pricing number during Q&A. |
---
6. Defensibility & Competitive Moat
Why a Client Would Pay — and Keep Paying
1. The data is the moat. Once six months of stakeholder ADKAR history lives in PulseCheck — trend lines, intervention history, what worked and what did not — the client is not starting over. The longitudinal model is irreplaceable. Every month of use deepens the lock-in without any artificial switching cost. The value compounds.
2. The signal library improves with use. The practitioner-built taxonomy of behavioral signals mapped to ADKAR stages gets more accurate and more specific to each client's language patterns over time. After six months, PulseCheck knows that "we'll take that on notice" in this organization means resistance, not agreement. That specificity is not replicable by a generic tool.
3. The Sponsor Mirror creates an irreplaceable coaching artifact. There is no other tool that helps a consultant surface sponsor message inconsistency with structured, evidence-backed diplomatic framing. Once a client has experienced a coaching conversation backed by PulseCheck's Sponsor Mirror, the alternative — the consultant's gut feel and political judgment alone — feels inadequate.
Pricing Model
Anchor to the cost it replaces, not the cost to build.
| Tier | Price | Rationale |
|---|---|---|
| Per Engagement | $1,200–$1,800 / month | Replaces 1–2 pulse surveys/month ($3k–$5k each) and 5–8 hrs/week of manual signal-gathering by the consultant at $250/hr. |
| Portfolio License | $12,000–$24,000 / month | Covers all active transformation programs. Cross-engagement pattern analysis. C-suite adoption rollup view. |
| C&S Embedded | Bundled in engagement fee | PulseCheck as a C&S delivery differentiator. License cost absorbed into engagement pricing, increasing perceived value. |
ROI math: a consultant spending 5 hours/week on manual change signal-gathering at $250/hour costs the client $5,000/month in labor. PulseCheck at $1,200–$1,800/month makes that time targeted and effective. One prevented go-live delay justifies the entire engagement-length subscription.
Competitive Positioning
| PulseCheck is NOT… | Because… |
|---|---|
| A Prosci / ADKAR platform replacement | Prosci is certification and methodology. PulseCheck is execution intelligence layered on top of an existing methodology the consultant already knows. |
| A pulse survey tool (Qualtrics, Glint) | Surveys require self-reporting and produce results 6–8 weeks late. PulseCheck reads behavioral signals from artifacts that already exist, continuously. |
| A project management tool (Jira, Monday) | Those track tasks and milestones. PulseCheck tracks human adoption — a fundamentally different and more predictive signal. |
| A BI dashboard (Tableau, Power BI) | Those show metrics. PulseCheck shows the consultant's next move, grounded in a specific evidence trail. |
The closest analogue: a Prosci-certified consultant embedded in your engagement full-time, reading every artifact, watching every stakeholder, and telling you what to do next. PulseCheck does that without the headcount.
---
7. Success Criteria
Hackathon Demo (April 17)
- [ ] Artifact upload form accepts pasted text and returns structured ADKAR inference within 10 seconds
- [ ] Observation debrief prompt appears after upload with pre-populated stakeholder names
- [ ] Consultant ADKAR Map renders all three demo stakeholders with stage, trend, and evidence
- [ ] Intervention Queue shows at least two prioritized recommendations with artifact evidence links
- [ ] Sponsor view renders in plain language with ADKAR stages named and translated
- [ ] Sponsor Mirror shows at least one specific gap between change narrative and sponsor communication
- [ ] Judges can interact with live URL during the pitch — not a screencast, not a mockup
- [ ] The demo uses pre-written realistic artifacts, not obviously fake or sanitized data
"Would a Client Pay For This?" Test
- A Director or VP with no change management background looks at the sponsor view and immediately understands what it is telling them and what they should do next.
- The inference output on the demo artifacts is visibly non-obvious — the AI is detecting signals a casual reader would miss, not just summarizing what is already explicit.
- The Sponsor Mirror moment lands: a judge who has lived a transformation recognizes the political situation it is describing and understands why the consultant needs that artifact.
- The pricing math is presented in the pitch and the ROI is self-evident without explanation.
- The governance story is clean: the judge can articulate, without prompting, why client data is safe and why the tool is a coaching aid, not a surveillance system.
---
8. Open Questions
- How granular should stakeholder identification be? Named individuals vs. roles vs. organizational groups. Named individuals produce the most actionable output but raise the most sensitivity questions. Roles are safer but less specific. This is a product positioning decision, not just a technical one.
- What is the right framing of the observation debrief to avoid consultant bias? The dropdown options shape what the consultant notices and reports. A poorly designed debrief could entrench confirmation bias rather than surface genuine signals. Needs practitioner review before build.
- How does the sponsor view get delivered? Does the consultant send it, or does the sponsor access a live URL? A live URL is more powerful but raises questions about who controls the narrative. If the consultant sends it, it becomes another artifact to manage. The delivery mechanism affects the product's relationship dynamics significantly.
- What happens when the AI inference is wrong? The consultant can dismiss a recommendation, but there is no current mechanism for correcting the underlying inference. If the AI misreads a stakeholder's ADKAR stage and the consultant does not catch it, the sponsor view could surface a misleading recommendation. Needs a correction workflow.
- What does the post-engagement data policy look like? Does the client retain access to PulseCheck data after the engagement ends? Does the data travel with C&S or stay with the client? The answer shapes both the pricing model and the long-term relationship dynamics with the client.
---
Built by Campana & Schott · Build Day 2026 · Miami