Shipping and specialties
Iteration and feedback loops
Turning feedback, support tickets and data into continuous improvement and kill decisions.
A launch is a hypothesis entering production. Everything after that is iteration: noticing what users do and say, deciding what it means, and changing the product — or killing the bet. Teams that treat feedback as a pile of anecdotes ship randomly. Teams that treat it as a signal-processing problem (channels → taxonomy → quantified themes → decisions → closed loops) compound.
The goal is not inbox zero on feature requests. The goal is a steady cadence of evidence-backed product decisions — including explicit nos. This pairs with user research and product analytics. If discovery taught you how to listen, this page is how listening survives contact with sprint planning.
Concepts in this section
Read them in order.
| Step | Concept | What it answers |
|---|---|---|
| 1 | Feedback channels | How each source is biased |
| 2 | Quantifying feedback | How themes become counts and tickets |
| 3 | Closing the feedback loop | How you keep people talking |
| 4 | Iterate or kill | When to double down, polish, or sunset |
Wire it into engineering
Feedback dies when it only lives in a PM's head.
- Weekly triage (30 min): top themes from support + analytics anomalies; decide investigate / ticket / ignore.
- Error budgets and ticket tags as first-class signals next to latency (an observability mindset applied to product).
- Demo / critique of support session replays in sprint review — five minutes of a confused user beats a slide.
- "Feedback → issue" template that requires channel, count, linked metric, proposed decision.
- Kill review quarterly: features below a usage threshold (e.g. <2% of MAU in 90 days) for keep / improve / sunset.
Pair qualitative loops with weekly discovery touchpoints (continuous discovery). Marty Cagan's framing still holds — empowered teams own outcomes, which means they own the feedback → decision loop, not a ticket conveyor from sales.
SDE2s should be able to pull a funnel, read support tags and propose a fix that addresses a theme, not a single anecdote. In interviews, strong stories sound like: "Tickets said X, data showed Y, we chose Z, we told users, metric moved / we killed it." Weak stories list features shipped from a backlog with no evidence trail.
A worked chain: 90 notification tickets, 40 "too many emails" verbatims, mute rate up, retained muters +8 points, two deals asking for digest defaults. The theme is email fatigue, not Slack. Ship digests, measure mute and D7, close the loop, park Slack.
Common mistakes
- One channel sets the roadmap. Combine support, in-app, sales and behavior.
- Volume without taxonomy. "Export broken" was "where is export?"
- Open loops. Users stop talking; nos look like silence.
- Zombie features. No dated sunset, no capacity reclaimed.
Key takeaways
- Every feedback channel is biased — never prioritize on volume alone.
- Taxonomy + counts + linked metrics turn anecdotes into decisions.
- Close the loop. Explicitly choose double down, iterate or kill.
- Put feedback into weekly eng rituals or it will not survive the sprint.
Further learning
Teresa Torres's one-minute overview of opportunity solution trees — how outcomes, opportunities and solutions stay connected while you iterate.
SVPG articles (Marty Cagan)A partnership dedicated to teaching best practices to product teams and product leadersSilicon Valley Product Group
User research for interview technique that avoids false positives.
Related
Launching products and features
Launch tiers, betas, checklists and measuring whether a launch worked.
User research
Interviews that avoid false positives, usability tests with five users, and synthesizing findings. Start here for the map.
Product analytics
Designing event tracking plans, reading funnels and cohorts, writing the SQL that answers product questions, and avoiding mix-shift illusions. Start here for the map.