Customer Needs Survey Template
The most dangerous sentence in product development is the confident one: users want [the thing we already decided to build]. Discovery that leads with your product collects confirmation, because people are kind and questions are leading. Discovery that leads with their work collects truth — what they’re trying to accomplish, where their current process fights them, and the workarounds they’ve quietly built to survive it. This survey is that second kind, run at the scale interviews can’t reach.
Ask About the Job, Not the Product
The jobs-to-be-done discipline has one rule that shapes every question here: people don’t want products, they want progress on something they’re trying to get done. So the survey never mentions your offering until the very end, if at all:
- The walk-through — describe how you currently handle [the task], start to finish. An open long text prompt. The full process, in their words, is the map everything else annotates
- The breaking point — where does that process slow down, break, or force you to repeat yourself? This is where needs live — not as feature wishes, but as friction with dates and consequences attached
- The workaround question — have you built any workarounds — spreadsheets, reminders, duct-taped processes — to cope? The single richest signal in discovery. A workaround is proof of unmet need, already paid for in the user’s own effort. Nobody duct-tapes a process for a problem they don’t have
- The tried-and-abandoned list — what have you already tried to fix this, and why did it stop working? Every failed prior solution is a design constraint and a marketing message, delivered in one answer
- The ideal-state prompt — if the process worked perfectly, what would be different? Respondents describe the outcome they’re buying — which is rarely the feature list anyone assumed
From Transcripts to an Opportunity Map
Twenty open-ended responses read individually are anecdotes; read together, they’re a map:
- Theme by breaking point — cluster the responses by where processes break. The friction named by eight independent respondents in eight different words is the opportunity, ranked by frequency without anyone voting
- Weight by severity and cost — the walk-throughs reveal which breaking points cost hours versus seconds. Frequency times cost is your opportunity ranking, and no roadmap meeting can argue with the arithmetic
- Harvest the vocabulary — the respondents’ own words for their problem become your positioning, your landing page, and your sales calls. Discovery copy converts better than copywriting, because it was written by the market
The Discipline of Not Leading
Discovery dies by adjective:
- Ask how do you currently do this — never how hard is it to do this with existing tools; the second question pre-writes the conclusion
- Let silences in the design do work: the absence of a suggested answer in the walk-through prompt is what produces answers you couldn’t have listed
- Pilot the survey on two or three friendly respondents and cut every question they answered by paraphrasing your hypothesis back to you — that’s a leading question wearing a neutral costume
Frequently Asked Questions
What is jobs-to-be-done, in one paragraph?
The framing that people hire products to make progress on something they’re trying to accomplish — a job with functional, emotional, and social dimensions. Discovery built on JTBD asks about the job and its current solutions, not about your product category, because the job is stable while products come and go. It’s the difference between asking do you like our drill and what were you trying to hang.
Can surveys really do discovery, or is this interview territory?
Both, in sequence and in proportion. Interviews reach depth on five voices; surveys reach breadth on two hundred — and the survey’s role is finding out whether the interview insights generalize. The open-ended walk-through questions here are essentially a scalable interview, with the trade-off made explicit: less depth per respondent, enough breadth to separate patterns from personalities.
How do we pick which task to ask about?
Start from the job adjacent to what you offer or hope to offer — the task your product would sit inside. If multiple candidates exist, run small pilots on each and let response richness decide: the task respondents describe vividly and at length is the one worth surveying widely. Thin answers about a task usually mean it’s not where their attention or pain lives.
How does this feed the roadmap differently than feature requests do?
Different altitudes of input. Feature requests propose solutions — usually surface-level, sometimes contradictory. Needs discovery surfaces the problem structure the solutions should serve, including the needs nobody has thought to request yet. The strongest roadmaps run both: discovery defines the territory, requests indicate which parts of it are most demanded — and discovery outranks requests when the two disagree.
When should a needs survey run relative to everything else?
Upstream of everything: before concept testing, before roadmap planning, before positioning work. It’s the research that tells you which concept is worth testing and which market worth entering. Re-run it when you enter an adjacent market or when your walk-through themes start aging — the processes users described two years ago may not be the processes they run today.