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/<startup-slug>-feedback-analysis.json.
• Generate the interactive report:

node analyze-startup-feedback/scripts/generate_report.mjs <analysis.json> <report.html>

• Export the evidence ledger:

node analyze-startup-feedback/scripts/export_ledger.mjs <analysis.json> <ledger.csv>

• Save the report as outputs/<startup-slug>-customer-evidence.html.
• Save the ledger as outputs/<startup-slug>-evidence-ledger.csv.
• Create outputs/<startup-slug>-roadmap.md and outputs/<startup-slug>-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