Customer feedback arrives as requests, complaints and suggested fixes, spread across support, sales calls, reviews and the odd email forwarded by a founder. A brief is what engineering can act on: one page that states the problem, shows the evidence, and says what to build first. This guide takes you from the one to the other, and keeps every claim attached to the customer who made it.
You can do all of it with a spreadsheet and your inbox. The last section shows where the same steps land in adduce.
1. Collect the feedback in one place
Pull the last few weeks of feedback into one list before you read any of it. Each row is one thing one customer said: the words they used, where they said it, who they are, and the date. Do not clean the wording up yet. A paraphrase is where the evidence starts to leak.
- Support conversations, with a link to each thread.
- Call notes and transcripts, with the timestamp of the moment.
- App store and review-site comments, with the rating.
- Sales objections, in the salesperson's words if that is all you have.
If a customer said the same thing twice, keep both rows. Repetition is information.
2. Group by the problem, not the request
Customers ask for solutions. "Add a dark mode", "let me export to a spreadsheet", "give me a weekly digest". Put each row under the problem the request is trying to solve, and you will find that three different requests are often the same problem seen from three seats.
Name each group with a sentence that a customer could have said: "I cannot see what changed since I last looked." Not a feature name. A group named after a feature has already decided what to build.
Count the groups, but read them too. Ten people asking for an export may be one small account with ten users, and one person asking for a digest may be the admin of your largest workspace. The brief needs to say which.
3. Keep the customer's words
For each group, pick the two or three quotes that say the problem best, and keep them exactly as written. A quote does three things a summary cannot: it carries the customer's own priority, it shows the reader that the problem is real, and it gives the engineer a sentence to test the fix against.
Attach the source to every quote. A quote without a link is an opinion with punctuation.
4. Write the problem before the solution
The first half of the brief is the problem, and it is the half most briefs skip. Write it in four short parts:
- Who has the problem, in terms of the segment: plan, role, size, how long they have been a customer.
- What they are trying to do when they hit it.
- What happens instead, in their words.
- What it costs them, and what it costs you: the churn risk, the support load, the lost expansion.
Only then write what you propose. A reader who agrees with the problem will accept a smaller fix than the one they asked for. A reader who never saw the problem stated will argue about the feature.
5. Add what the product data says
Feedback tells you what people say; product data tells you what they do. Before you finish, check the group against the numbers you already have. How many accounts match the segment? How often do they reach the step where the problem happens? Did the complaints start on a date that lines up with a release?
Put the answer in the brief as a line with its source. "Forty-one accounts on the team plan reached the export step last month; nine wrote in about it." When the numbers do not support the feedback, say so. A brief that admits an open question is one your team will trust next time.
| Section | What goes there | Cited from |
|---|---|---|
| Problem | Who, what they are trying to do, what happens instead, what it costs | The grouped feedback, in the customer's words |
| Evidence | Two or three quotes, the count of accounts, the dates | Support threads, call notes, reviews, product data |
| Proposal | The smallest change that removes the problem | The problem statement |
| Open questions | What the evidence does not settle | Named, with what would settle it |
| Success | The number that should move, and by when | The same product data the evidence came from |
6. Hand it over, and keep the links
The brief is done when an engineer can read it in five minutes, open any claim, and see the customer behind it. Keep it to one page. Put the quotes in, put the links in, and put the open questions at the end rather than hiding them.
When the work ships, go back to the same threads. The customers who gave you the problem are the ones who can tell you whether it is solved, and the brief already has their names.
The checklist
- Every piece of feedback is one row, in the customer's words, with a link and a date.
- Rows are grouped by the problem, and each group is named as a sentence a customer could say.
- Each group keeps two or three exact quotes with sources.
- The brief states who, what, what happens instead and what it costs, before any proposal.
- Product data is checked against the feedback, and the brief says where they disagree.
- The proposal is the smallest change that removes the problem, with a number that should move.
In adduce
Where this lands in adduce.
adduce brings the evidence together, explains the underlying problem, and prepares a brief your team can review. Every line of it cites the comments it rests on.
