How to Get User Feedback in a Two-Week Sprint
A tight loop beats endless surveys. Structure mid and end reports.
Most feedback efforts fail from drift, not lack of effort. A survey goes out, a few answers trickle in over a month, someone summarises them in a doc nobody opens, and the roadmap carries on as planned.
A two-week sprint fixes that by putting a start date, an end date and a decision on the calendar. You recruit a small group of real users, give them specific work to do, collect feedback at two fixed points, and finish with a written decision about what changes. Fourteen days is long enough for someone to use your product in a normal working week and short enough that nobody forgets why they signed up.
This guide is the day-by-day version, written for founders of small-business software.
Before day one: pick one question
A sprint that tries to learn everything learns nothing. Write down the single question the sprint must answer. Good ones are narrow and decision-shaped:
- Can a bookkeeper set up a new client without a call from us?
- Do salon owners actually use the rebooking prompt, or dismiss it?
- Will a courier dispatcher trust our route order enough to stop re-sorting it by hand?
Then write what you will do with each possible answer. If "yes" and "no" lead to the same roadmap, you have picked the wrong question.
Finally, decide who counts as a valid participant. For the bookkeeper question, that is someone who onboards clients every month, not a friend who once did their own tax return. Six to ten well-matched people is plenty for a sprint like this; more than that and you will not have time to read what they send.
The fourteen-day plan
| Days | What happens | Your job | | --- | --- | --- | | 1 | Kick-off: access, first task, what "done" looks like | Remove every setup blocker the same day | | 2–4 | Participants do the first real job with their own data | Watch usage, answer questions fast, log everything | | 5–6 | Quiet period | Resist fixing things mid-flight unless they block work | | 7 | Mid-sprint check-in | Read every response within 24 hours | | 8–12 | Second job, harder or more frequent | Ship one small fix and tell them about it | | 13–14 | End-of-sprint report | Collect would-pay answers and a star rating | | 15 | Decision day | Write the decision and send it to participants |
Two things matter more than the exact days. First, participants must do work they would be doing anyway, on their own data. A café owner rostering next week's staff will tell you far more than one clicking through a demo roster. Second, the check-in points are fixed. People answer promptly when they know the date in advance.
What to ask at the mid-point
The mid-sprint check-in exists to catch problems while there is still time to act. Keep it short enough to answer in ten minutes:
- What did you try to do this week?
- Where did you get stuck or give up?
- What did you do instead when that happened?
- Is there anything stopping you from using it next week?
Question three is the one people skip and the one that matters. "I exported it to a spreadsheet and fixed it there" tells you exactly which feature is not trusted yet.
Do not ask about price here. After one week, nobody has formed a view worth hearing.
What to ask at the end
The end report is where you ask the questions that need two weeks of real use behind them:
- What worked well enough that you would miss it?
- What broke, and how often?
- Would you pay for this next month? Yes, no, or "yes if…" — and ask them to finish that sentence.
- What would a fair monthly price be for your business?
- One to five stars, and why that number and not one higher.
The "why not one higher" follow-up turns a vague rating into a to-do list. A trades business owner who gives four stars "because I still have to re-enter the job address" has just written your next ticket.
Triage: turning answers into a decision
On day fifteen, put every piece of feedback into a single log with four columns: what was said, who said it, how many people hit it, and whether it touches the sprint question. Then sort into three bins:
- Blocks the question. Anything that stopped people doing the job you were testing. These go first, no debate.
- Repeated friction. Hit by several people but did not stop them. Schedule these.
- Single requests. One person, one idea. Note them and wait to see if they recur.
Resist the urge to count votes for feature ideas. Five people asking for five different integrations is not a signal to build integrations; it may be a signal that your export is poor.
Then write the decision in three sentences: what you learned about the question, what you will change, and what you will test next. Send a version to every participant. People who see their feedback lead somewhere are the ones who say yes to the next sprint, and often the ones who become paying customers.
Common ways a sprint goes wrong
- Recruiting whoever is available. Friends, other founders and people who like trying new apps give pleasant, useless feedback. Match participants to the sprint question.
- Changing the product every day. If the interface shifts under people mid-sprint, you cannot tell which version they are reacting to. Batch changes, ship one visible fix around day eight, and say what changed.
- Leaving setup to chance. A sprint where half the group spends the first week waiting for an invite is a one-week sprint.
- Asking only open questions. "Any thoughts?" gets silence. Specific prompts get specific answers.
- Never closing the loop. No summary at the end means no second sprint with the same people.
Running the sprint through LetsBeta
If you do not have a list of well-matched users yet, LetsBeta is built around this rhythm. You list your build, a person reviews it before it goes live, and businesses in your category apply to try it. You accept or decline each application, so you control who is in the sprint.
Accepted participants get an Access Card with the link to your product, any access code, and first steps — your software stays on your own site. Early Adopters file a mid-trial report and an end-of-trial report covering what worked, what broke, whether they would pay, a fair price and a star rating, and you mark each report useful or not useful. That maps neatly onto days seven and fourteen above.
Builder Free covers one program with up to three seats, which is enough for a first small sprint. If you want a bigger cohort or feedback export, see pricing.
For the questions themselves, Structured Feedback Templates goes deeper, and Early-Stage Metrics covers what to track once the sprint is over.
The short version
Pick one question. Recruit people who do the job for real. Fix the check-in dates in advance, ask for stuck points in the middle and for money at the end, and write a decision on day fifteen. Then run the next sprint.