A coach asks for a new report. A venue asks for a booking integration. An athlete wants a social feature. Each request is reasonable. Together, they can leave a small SportsTech team building three businesses at once.
The difficult decision is what gets the next few weeks of attention. I would start by asking which request helps the company learn something important about the customers it has chosen to serve.
Start with the event behind the request
Ask the person to describe the last time the missing capability caused a problem. What were they trying to do? What happened instead? Which workaround did they use? Who else was affected?
Michele Hansen’s Deploy Empathy is a useful reference for listening to a customer’s situation before interpreting it as a solution request. The questions here are my own. Their purpose is to separate a recurring problem from an attractive suggestion.
If a coach already exports a report every Monday and spends an hour correcting it, you have a workflow to investigate. If the request is something they might use eventually, you have a different level of evidence. Record both honestly.
Write the bet before adding tickets
Shape Up, by Ryan Singer, introduces the idea of setting an appetite for a piece of work. I would adapt that discipline to a small team by defining what you are willing to invest before allowing the solution to expand.
Use this brief:
Customer: which specific group is this for?
Problem: what recurring situation are they struggling with?
Evidence: what recent behaviour supports the problem?
Bet: what change will you test?
Investment: how much team time and cash can you commit?
Boundaries: what will you leave out?
Decision: what evidence will justify continuing, changing or stopping?
Owner and date: who will review the result, and when?
This is an original working template inspired by those methods. It is not a requirement to run the full Shape Up process.
A narrower change can produce better evidence
Imagine a training platform considering a configurable reporting system. This is an illustrative example. The immediate problem is that independent coaches need to explain a client’s change in performance during a weekly review.
The team could first test one clear comparison report with a few coaches, using an existing export and manual preparation. The question is whether the report changes the review, saves preparation time and gets used again. Building a full report designer would add scope before answering that question.
For hardware or performance products, preserve the technical and safety work required for a credible test. A smaller scope should still produce trustworthy evidence.
Give declined requests somewhere useful to go
Tell customers what you are investigating and what would change the decision. A request may matter later, or belong to a segment you have chosen not to serve yet. That explanation is more useful than leaving every request indefinitely on a roadmap.
The same applies internally. If a founder accepts an exception, record which work moves back and why. Product promises are commitments of company capacity.
This week, take the three requests competing for your team’s attention. Write the brief for each. Choose the one that addresses a repeated problem for your priority customer and fits the investment you can afford. Name the other two things you will defer.
Which request is hardest to say no to right now? Reply with the situation behind it. That is often where the useful product conversation starts.