← The Research Station ~ dish 07 of 10 · the research station

Customer Research

Read the last 90 days of customer signals (calls, emails, surveys, support tickets) and surface what they're actually telling you. The station clusters patterns. The Chef reads and decides what's real. This is judgment work. Patterns are real. The conclusions need the Chef.

The job

The business hears thousands of customer signals. Support tickets about bugs. Emails about feature requests. Call transcripts about problems. Surveys about satisfaction. The signals exist everywhere. The team never sees the pattern because the signals are scattered.

When the station runs this dish well, every month the Chef gets a research summary. Here’s what customers are actually telling us. These patterns showed up in support, these in calls, these in surveys. Here’s the connection between them. Are these real problems or edge cases. The Chef reads it and decides what to act on.

The difference between customer research that drives decisions and customer research that’s just reporting is the Chef’s involvement. The station surfaces patterns. The Chef decides if the pattern is real, if it matters, what to do about it. The station doesn’t decide. The Chef tastes every plate.

The recipe

All seven ingredients still apply. The leverage on this dish isn’t a single recipe ingredient. It’s the Four D’s stance. This dish stays in DIALING (or DECIDING) on the Four D’s. The station clusters. The Chef reads and concludes. The station is a thinking partner, not a research replacement. Judgment stays with the Chef.

Context matters. The station reads support tickets, call transcripts, survey responses, email threads. It reads the full context, not summaries. Examples matter. Show the station a customer research summary you’d use to make a decision. What patterns matter. How you cluster them. What level of validation you need before acting.

How to build it

  1. Identify all the places customer signals live. Support ticketing system. Email archives. Call transcripts. Survey responses. Customer interviews. Create a list.
  2. Define what counts as a meaningful pattern. A single customer mentioning a feature is signal. Five customers mentioning the same feature is pattern. Ten customers is a trend that requires action. Define your thresholds.
  3. Define the time window for research. Monthly is the default. If customer feedback moves fast, maybe it’s bi-weekly. Define it upfront.
  4. Define what clusters matter. Features requested. Problems encountered. Bugs. Integrations wanted. Pricing feedback. Onboarding friction. Category them.
  5. Define your research summary format. Top three patterns (name, frequency, quote count). Supporting detail for each. One paragraph on what it might mean. Chef recommendation (question, not directive). That’s it.
  6. Pull one customer research summary you’d actually use to prioritize work. This is your standard.
  7. Test on a mock run. Have the station read the last 30 days of customer feedback and surface patterns. You read it. Are these real patterns. Are they the patterns that matter. Are the thresholds right. Adjust.
  8. Go live. Monthly cadence. After the Chef reads the summary, the Chef gives feedback on which patterns were real and which were false signals. That feedback sharpens the recipe.

What breaks it

  • Patterns are too weak. The station surfaces that “three customers mentioned pricing” as a pattern worth investigating. That’s not a pattern, that’s noise. Define your threshold upfront. Five customers minimum. Or ten. Define what “frequent enough to matter” means.
  • Summary includes customer quotes without context. The station pulls a quote from a support ticket but doesn’t include what was actually wrong or if it was resolved. The quote looks damning out of context. Always include the full context of customer feedback.
  • Patterns are contradictory. The summary says “customers want more features” and “customers want simpler product.” Both are true in one month because different customers want different things. Cluster them by customer segment or use case. The summary should separate “power users want advanced features” from “new users find the product overwhelming.”
  • The Chef’s conclusion never makes it back. The Chef reads the summary and decides that one pattern is real, one is edge case, and one requires action. The Chef never tells the station. Next month, the station surfaces all three equally because the context died. When you decide, tell the station. That decision teaches.
  • Volume is buried by rarity. The station surfaces that “one customer mentioned a critical bug” the same way it surfaces “100 customers mentioned better onboarding.” Weight matters. Patterns should be ranked by frequency and impact, not listed equally.

When it’s working

At week four of each month, the Chef gets a customer research summary. The summary surfaces three to five patterns the team should know about. Seventy percent of the patterns match what leadership is already hearing in calls. Thirty percent reveal something new. When the summary reveals something new, it changes priority or shapes a decision.

The signal that the recipe is sharp: the product or customer success team references a pattern from the research summary when explaining why they’re prioritizing work.

Monday Move

Identify all the places customer signals live. Define what counts as a meaningful pattern. Define your summary format. Pull one customer research summary you’d use to guide prioritization. The station is running on Monday.

Dish 7 of 10 on the Research Station. Build-note leverage: Four D’s stance (DIALING).