# Analyze Startup Feedback > Turn startup customer feedback, reviews, surveys, interviews, support tickets, churn notes, community posts, and sales-call transcripts into traceable customer evidence, prioritized product opportunities, roadmap recommendations, objection handling, proof libraries, and case-study candidates. Use when Codex needs to analyze qualitative feedback files or exports, cluster recurring pains and outcomes, compare customer segments or time periods, decide what a startup should build next, identify credible customer language and proof, or create an interactive Startup Customer Evidence Map without inventing quotes or claims. - Skill: `kappaemme-git/analyze-startup-feedback` (Agent Skill, multi-file: 9 files) - Install (CLI): `npx skillmds@latest add kappaemme-git/analyze-startup-feedback` - Raw SKILL.md: https://api.skillmd.com/api/skills/kappaemme-git/analyze-startup-feedback/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Product & Planning - Author: kappaemme-git (https://skillmd.com/u/kappaemme-git) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/kappaemme-git/analyze-startup-feedback --- # Analyze Startup Feedback Convert messy customer voice into two defensible outputs: what the startup should improve or build, and what it can credibly prove. Keep every conclusion traceable to source evidence. ## Language - Conduct discovery, analysis, recommendations, labels, exports, and reports in English. - Translate non-English input for analysis while preserving the original text in the evidence ledger. - Never silently rewrite a quote. Label translated or paraphrased text explicitly. ## Read the right references - Read [references/data-intake.md](references/data-intake.md) before inspecting or normalizing feedback. - Read [references/classification.md](references/classification.md) before labeling evidence or building clusters. - Read [references/scoring.md](references/scoring.md) before ranking opportunities or proof. - Read [references/privacy-and-quote-integrity.md](references/privacy-and-quote-integrity.md) before handling private data, quotes, testimonials, or public-facing claims. - Read [references/report-schema.md](references/report-schema.md) before creating the analysis JSON or report. ## Choose the mode - `full` — Produce the evidence map, roadmap, proof library, and report. Use by default. - `roadmap` — Prioritize pains, friction, churn risks, and product opportunities. - `proof` — Extract supported outcomes, customer language, objections, and case-study candidates. - `churn` — Focus on cancellation reasons, failed expectations, alternatives, and recovery actions. - `interviews` — Analyze customer-discovery or sales transcripts without treating stated intent as behavior. - `compare` — Compare segments, plans, sources, cohorts, time periods, or product versions. ## Run the workflow ### 1. Inspect before asking - Inspect every supplied CSV, JSON, Markdown, text file, document, transcript, screenshot, URL, or export. - Record the source, date, segment, customer or account identifier when available, and whether the text is public or private. - Ask only for missing context that would materially change interpretation: product, target segment, time window, source meaning, or decision the user must make. - Never ask the user to manually summarize feedback already supplied. ### 2. Build the evidence ledger - Create one immutable record per evidence item with a stable ID. - Preserve the exact source text separately from any English translation or paraphrase. - Classify each item using `references/classification.md`. - Attach source, date, segment, product area, sentiment, intensity, specificity, and consent status only when supported. - Use `unknown` rather than guessing missing metadata. - Redact direct personal identifiers in report views by default while keeping the local source reference. ### 3. Cluster without losing traceability - Group semantically equivalent evidence into named clusters. - Keep feature requests separate from the underlying job, pain, or desired outcome. - Allow one item to support multiple clusters only when each relationship is explicit. - Show the item IDs behind every cluster, count, quote, and recommendation. - Distinguish repeated evidence from duplicated or copied feedback. ### 4. Assess the dataset - Report source coverage, date range, segment coverage, missing metadata, duplicate rate, and likely selection bias. - Label the analysis `directional`, `limited`, `moderate`, or `substantial` using the guidance in `references/data-intake.md`. - Never imply statistical representativeness from qualitative volume alone. ### 5. Rank product opportunities - Convert clusters into opportunity hypotheses, not automatic feature orders. - Score frequency, intensity, segment breadth, recency, strategic fit, commercial or retention relevance, and evidence quality. - Mark unavailable criteria as unknown and lower confidence rather than silently scoring them as zero. - Separate quick wins, research bets, strategic investments, and items to ignore. - Produce a 30/60/90-day roadmap only when enough context exists; otherwise produce a validation sequence. ### 6. Build the proof system - Extract concrete outcomes, before/after statements, customer vocabulary, purchase triggers, objections, and case-study candidates. - Score proof separately from opportunity importance. - Treat permission to publish as a hard gate, never as a score. - Label every item as `internal-only`, `permission-unknown`, or `publishable` based only on explicit evidence. - Identify attractive claims that remain unsupported and state what proof would be needed. ### 7. Create the deliverables - Store the structured source as `outputs/-feedback-analysis.json`. - Generate the interactive report: ```bash node analyze-startup-feedback/scripts/generate_report.mjs ``` - Export the evidence ledger: ```bash node analyze-startup-feedback/scripts/export_ledger.mjs ``` - Save the report as `outputs/-customer-evidence.html`. - Save the ledger as `outputs/-evidence-ledger.csv`. - Create `outputs/-roadmap.md` and `outputs/-proof-library.md` when their sections contain actionable evidence. - Return clickable absolute links to every final artifact. ### 8. Verify before delivery - Open the HTML report and test search, filters, evidence links, responsive layout, and empty states. - Confirm that every displayed quote exists verbatim in the ledger. - Confirm that every recommendation cites evidence IDs. - Confirm that no permission-unknown quote is presented as an approved testimonial. - State the strongest conclusion, the most dangerous uncertainty, and the next evidence collection step. ## Enforce evidence integrity - Never invent, merge, polish, or complete customer quotes. - Never convert praise into a measurable result. - Never treat requested features as validated solutions. - Never equate frequency with importance without context. - Never expose private personal information in a shareable report. - Never claim testimonial consent, market representativeness, causation, or revenue impact without evidence. - Keep facts, verbatim quotes, translations, paraphrases, interpretations, and recommendations visibly distinct. - Prefer `INSUFFICIENT_EVIDENCE` to a confident but unsupported conclusion. ## Default report order 1. Executive verdict 2. Dataset health and confidence 3. Source and segment coverage 4. Pain and outcome clusters 5. Product opportunity matrix 6. 30/60/90 roadmap or validation sequence 7. Customer language and objections 8. Proof library 9. Case-study candidates 10. Unsupported claims and evidence gaps 11. Next interviews or data collection 12. Filterable evidence ledger