Customer Feedback Emails

Good customer-feedback email is specific, personal, and easy to answer. It asks for concrete failure evidence without making the user do unpaid product work.

The Snowmaker bookmark preserves a Cursor-era example attributed to Michael Truell: after a user appeared to cancel, the founder wrote a short personal email, offered to refund, asked what the product got wrong, and asked for concrete examples of poor behavior. The user responded that the issue was a card problem, not churn, praised the product, shared the project they were building, and the exchange turned into a recruiting conversation. Source: X/@snowmaker, 2026-06-21; Source: local artifact review, 2026-07-03

Pattern

Use this when a founder or product lead needs qualitative feedback from users who may not respond to generic research asks.

Move Why it works
Name the observed event Shows the message is not a blast.
Offer a concrete make-good Reduces defensiveness before the ask.
Ask one or two specific questions Makes the reply cheap.
Ask for evidence only if easy Preserves goodwill.
Reply like a human Turns feedback into relationship, not survey data.

The point is not longer copy. The point is high proof of attention. "What did you dislike?" is weak on its own; "where did the agent perform poorly, and can you share a screenshot if easy?" gives the user a specific hook.

Paul Graham's June 2026 complaint axiom gives the strategic reason to do this patiently: users who complain are often valuable because they care enough to report the flaw. The email should turn annoyance into evidence: what broke, where, how often, and what the user expected instead. Source: X/@paulg, 2026-06-24

Product Loop

This is the missing tactical layer under "talk to users" in AI-Native Design Patterns. Agent-assisted prototyping can make the first artifact fast, but the learning loop still depends on the quality of the message that gets a real user to answer.

For AI products, the best feedback email asks about failure modes, not opinions:

  • what task the user tried,
  • where the agent or UI failed,
  • what output was wrong,
  • what they expected instead,
  • whether the failure happened once or repeatedly.

The same exchange can also expose hiring signal. A user who gives crisp failure detail, ships with the product, and understands the product's frontier may be closer to a candidate than a survey respondent.


Timeline