AI customer feedback: what should you build next?

AI analysis of customer feedback can help a software business find questions worth investigating. Choosing what to build still requires a decision about whose work should improve, what is happening now and why the change deserves the team's time.

EP argues for improving the product for existing customers, alongside the attention businesses give to acquiring more customers. His post promotes using Wave to analyse customer wants and implement changes; it carries a paid-partnership label. That is a commercial recommendation, not evidence that the proposed changes will produce revenue. The useful business question is what would justify acting on a suggestion.

What does the customer need to do?

A feature request gives the team a starting point for understanding the work. Before putting it into the product plan, ask the customer to describe the situation that led to it.

Take a hypothetical customer asking for a dashboard in a service platform. The manager wants a faster way to prepare a weekly update. The people handling cases already enter status information, but some cases wait for another team to respond. The manager's request could mean that the information is hard to find, that the status is unreliable or that the handover itself needs changing. Those possibilities lead to different work for the product team.

Ask the manager to walk through the last update they prepared. Where did the information come from? Which part took time? What did they have to ask someone else? Speak with the people who supply that information as well. A dashboard could make existing information easier to read while leaving the missing information unresolved.

The Business Value Assessment interview method follows the work across the people involved. Applied here, it helps the product owner check what an AI summary has brought together and which questions still need a customer conversation. A repeated phrase in feedback can point to a problem worth investigating without explaining its cause.

What would justify changing the product?

The reason to prioritise a change should connect the customer's problem with a business decision the company can explain. A request's frequency is useful context, but it cannot supply that explanation by itself.

In the hypothetical dashboard case, the team could first establish how the update is prepared and which part the proposed dashboard would replace. If the manager estimates the time spent, keep the figure labelled as an estimate and record what it includes. Time spent chasing an unresolved case may remain even if assembling the report becomes easier.

Ask what the manager would do differently with the information. A clearer weekly view might support a staffing discussion, or it might simply reproduce a report nobody acts on. The answer affects what the team should test. Neither possibility is a claim about the outcome at a real customer.

The software company also needs to weigh this work against its other commitments. Which customers face the same problem? What support or ongoing maintenance would the change require? What would the team postpone to build it? An AI-generated implementation does not answer those questions, even if it makes part of the work quicker.

Keep any commercial expectation separate from what the customer has said. A request from an existing customer is not an agreement to renew, expand or pay for the change. If the business case depends on such an agreement, ask the customer about it rather than treating the feature request as confirmation.

How can the team test the proposed change?

Choose a small test that answers the unresolved question before committing to the full change. The product owner needs to state what the team expects to learn and what result would change the decision.

For the hypothetical dashboard, that could mean reviewing a manually prepared sample with the manager and the people supplying the status information. Can they use it for the weekly discussion? Which information is still missing? Does it reveal a handover problem that a different display would leave untouched? This is an example of a possible test, not a claim about a tested product or a guaranteed saving.

Afterward, record what the customer demonstrated, what they reported and what the team still assumes. The next decision might be to build, change the proposal, investigate further or leave it alone. Keep the reason visible so that the next person reading the product plan can understand why the work is there.

For a business introducing AI into decisions like these, an AI advisory discussion can start with an actual proposed change and the customer evidence behind it. The practical question is whether the team knows enough to commit its time, and which customer conversation or test would help it decide.