A prospect on a call asks whether the product will support a particular workflow. The founder, wanting the deal, says it is on the roadmap for the spring.
It was not on the roadmap. It is now, along with the four other things promised the same way, and by March the team is building a product nobody designed.
The checklist
Work through these and roadmap questions stop being dangerous.
1. Separate exists, planned and not planned
Three categories, answered plainly. Most damage comes from answers that blur the line between planned and possible.
2. Publish themes rather than dates
What the product is working towards this quarter, in themes. It answers the direction question without creating a delivery obligation.
3. Decide who may commit to anything
One person, usually. Without that rule every conversation becomes a commitment and nobody knows what has been promised.
4. Capture requests in one place
The request, the context, who asked, what they are trying to achieve and what they do today. The underlying need matters more than the feature named.
5. Ask what problem it solves
Requests are solutions in disguise. The stated feature is frequently not the best answer to the need, and asking produces a better product, which is the practice in handling feature requests that arrive through chat.
6. Say no clearly when it is no
An honest not planned is better than a vague maybe. Buyers make decisions on clarity and remember vendors who were straight with them.
7. Offer the workaround
Where something can be achieved another way, show it. Half of feature requests are solved by something that already exists.
8. Track how often each request arrives
Counting is what turns anecdote into a decision. Without it the loudest customer sets the roadmap.
9. Tie requests to revenue honestly
Which deals are blocked, which renewals depend on it, and which are preferences. It is the only way to prioritise fairly.
10. Close the loop when something ships
Tell everybody who asked. It is the cheapest retention activity available and almost nobody does it consistently.
10b. Review requests on a fixed rhythm
A weekly or fortnightly review of everything captured, attended by the people who decide, is what stops requests accumulating unexamined in a document. It also means a salesperson can honestly tell a prospect when their request will be considered, which is a far better answer than a vague promise to raise it internally.
10c. Be careful with the word soon
Customers hear soon as a matter of weeks and teams mean it as a matter of quarters. Removing the word entirely, and replacing it with either a theme for the current quarter or a plain not currently planned, eliminates most of the disappointment that follows an honest but ambiguous conversation.
11. Handle the enterprise variant carefully
Large prospects request features as conditions, which is the negotiation covered in pilot pricing questions from first enterprise customers.
12. Publish what you will not build
A short statement of what is out of scope saves everybody time and attracts the customers you can actually serve.
13. Capture it wherever users ask
Requests arrive in chat, email and calls at all hours, and consistent capture is the point, as in early stage startups and their first customer questions and an AI assistant for a subscription business.
Getting started
Publish themes rather than dates, decide who may commit, and capture every request with its context at any hour. SpideyChat for startups answers from your published pages. Try SpideyChat on your own site, or read about capture on the features page.