tool-note-and-vote
Note-and-Vote is a structured decision protocol that runs in 20–30 minutes, using silent ideation and voting to surface independent thinking before group discussion, then closing with an explicit Decider supervote. Use it when a small team must decide quickly with diverse input, groupthink risks narrowing options, or an audit trail of considered alternatives is required.
git clone --depth 1 https://github.com/product-on-purpose/pm-skills /tmp/tool-note-and-vote && cp -r /tmp/tool-note-and-vote/skills/tool-note-and-vote ~/.claude/skills/tool-note-and-voteSKILL.md
<!-- PM-Skills | https://github.com/product-on-purpose/pm-skills | Apache 2.0 -->
# Note-and-Vote
Run a structured group decision in 20-30 minutes. Silent contribution surfaces independent thinking before group dynamics narrow the option space; explicit Decider supervote closes the choice. Produces a written audit trail of the decision and the alternatives considered.
## When to Use
- A small team (3-10 people) needs to make a fast decision with diverse input.
- Groupthink, status bias, or loudest-voice dominance is a real risk.
- A workshop or meeting moment demands silent ideation before open discussion.
- The decision needs an audit trail (what was considered, why the chosen option won).
- Decision authority is clear (a Decider exists and is in the room or available).
- Used heavily across Foundation Sprint and Design Sprint at decision moments.
## When NOT to Use
- A single person owns the decision and just needs to make it. Use direct judgment.
- Consensus has already emerged organically. The voting overhead adds friction without value.
- The decision is high-stakes enough to warrant longer deliberation (multi-day investigation, written proposals, formal review). Note-and-Vote is a 25-minute tool, not a governance process.
- No Decider is available and the team has no authority to close the decision themselves. Defer until a Decider can attend.
## The Five-Step Protocol
```text
1. Frame the question (1-2 min)
2. Silent ideation (3-7 min, depending on complexity)
3. Silent voting (2-5 min, multi-vote or single-vote)
4. Brief discussion of the vote distribution (5-10 min)
5. Decider supervote (1 min)
```
Total: 12-25 minutes depending on time allocations. Default is 25 minutes for a non-trivial decision.
```mermaid
flowchart TB
Start([Decision needed])
Start --> S1[Step 1: Frame the question<br/>1-2 min, spoken]
S1 --> S2[Step 2: Silent ideation<br/>3-7 min, silent]
S2 --> S3[Step 3: Silent voting<br/>2-5 min, silent]
S3 --> S4[Step 4: Brief discussion<br/>5-10 min, spoken]
S4 --> S5{Step 5: Decider supervote<br/>1 min}
S5 -->|Most common| TopVote[Pick top vote-getter]
S5 -->|Sometimes| Override[Pick different option<br/>with stated rationale]
S5 -->|Rare| Revote[Call re-vote after re-framing]
TopVote --> Record[Decision recorded in artifact]
Override --> Record
Revote --> S2
style S2 fill:#e1f5ff
style S3 fill:#e1f5ff
style S5 fill:#fff4e1
style Record fill:#e1ffe1
```
Silent steps (blue) protect against anchoring. The Decider supervote (amber) has three legal outcomes; the loop back to silent ideation is the recovery path when the framing was wrong.
### Step 1: Frame the question
Write the decision question on the board, one sentence, unambiguous. Examples:
- "Which target customer segment should our Foundation Sprint commit to for Day 1?"
- "Which solution sketch goes forward into Wednesday's storyboard?"
- "Which sprint question should be the primary scorecard row on Friday?"
Bad framings to avoid:
- Compound questions ("which customer AND problem")
- Yes/no questions (use a different tool)
- Open exploration ("what should we do?")
### Step 2: Silent ideation
Every participant contributes options silently and independently. Sticky notes on a wall, cells in a Miro board, or rows in a shared doc. No talking. No reading others' contributions until the timer ends.
The facilitator MUST enforce silence. Verbal contribution defeats the purpose.
### Step 3: Silent voting
Display all contributions anonymously (or with attribution if the team has agreed). Each participant gets N votes (often 2-3 for a multi-vote round, 1 for a single-vote tiebreaker). Vote silently using dots, stickers, reactions, or numbers. No discussion during voting.
### Step 4: Brief discussion
Surface the top 2-3 vote-getters. Each person who voted for the top options briefly explains why. The facilitator times this (5-10 minutes max). If discussion expands beyond the top options, the facilitator pulls it back.
This is the place where the team can detect surprises ("I didn't realize we were aligned on X") or unsurprises ("we're split between A and B for known reasons"). It is not the place to relitigate the framing.
### Step 5: Decider supervote
The Decider names the chosen option. The Decider may pick the top vote-getter (most common), pick a different option with stated rationale (sometimes), or call for a re-vote after the discussion (rare).
The supervote is the decision. Record it explicitly in the artifact. Do not let the supervote blur into continued discussion; the team needs to see the close.
## Output Structure
The skill produces a single bundled artifact containing:
1. The decision question (verbatim)
2. The silent ideation board (all contributions, timestamped, attribution per team agreement)
3. The vote summary (counts per option, voters per option if attribution agreed)
4. Discussion notes (brief, the rationale that surfaced)
5. The decision record (chosen option + Decider name + Decider rationale if non-obvious)
See `references/TEMPLATE.md` for the canonical structure and `references/EXAMPLE.md` for a worked example using the Brainshelf book-catalog Foundation Sprint thread.
## Common Pitfalls
- **Skipping silent ideation.** "Let's just discuss it" defeats the protocol. The team produces what they would have produced without the tool.
- **Skipping Decider supervote.** Consensus drift. The discussion ends without a recorded decision.
- **Long discussion phase.** Five-minute discussions become twenty-minute debates. The facilitator must time-box and pull back.
- **Compound or vague framing.** "What should we do about X?" is not a decidable question. Reframe before invoking.
- **Voting without seeing the contributions.** If contributions are revealed during ideation, the voting is anchored to the first idea seen. Enforce silence.
- **Treating the Decider's choice as advisory.** The supervote is the decision; iRun an ad-hoc ordered chain of pm-skills with shared context (ephemeral; routes to the pm-workflow-orchestrator)
Defines a testable hypothesis with clear success metrics and a validation approach. Use when forming assumptions to test or aligning a team on what success looks like, before any experiment is designed. To design the A/B test or experiment that will validate the hypothesis, use measure-experiment-design.
Creates a Jobs to be Done canvas capturing the functional, emotional, and social dimensions of a customer job. Use when deeply understanding customer motivations, designing for jobs, or reframing product positioning.
Creates an opportunity solution tree connecting a desired outcome to customer opportunities and candidate solutions, preventing solution-first jumps in continuous discovery. Use when structuring scattered feature ideas or communicating how the roadmap traces to outcomes. For ranking an existing flat list of candidates, use define-prioritization-framework instead; this skill discovers the list, it does not score one.
Run applicable prioritization frameworks (RICE, ICE, MoSCoW, Weighted Scoring, Kano) against a list of features or initiatives. Produces a comparison table showing where rankings agree and diverge across frameworks, and an executive summary with recommendation. Framework applicability is filtered by data availability; Kano requires customer research. Refuses to fabricate scores; produces an estimation scaffold when input data is missing.
Creates a clear problem framing document with user impact, business context, and success criteria. Use when starting a new initiative, realigning a drifted project, or communicating up to leadership.
Generates structured Given/When/Then acceptance criteria for a user story or feature slice, covering the happy path, key failure scenarios, and non-functional expectations in testable form. Use when turning requirements into verifiable scenarios for engineering handoff and QA sign-off. For a dedicated catalog of boundary conditions, error states, and recovery paths across a feature, use deliver-edge-cases; to write the stories themselves, use deliver-user-stories.
Documents edge cases, error states, boundary conditions, race conditions, and recovery paths for a feature - the systematic catalog of what can go wrong and the failure modes to design for. Use during specification to map the failure surface and ensure comprehensive coverage, or during QA planning to identify boundary and limit scenarios to test. Distinct from deliver-acceptance-criteria, which writes story-level Given/When/Then checks; this skill produces the whole-feature edge-case catalog.