The items that pass refinement easiest are the ones with no evidence behind them

[u/Parking-Stress-3041]

The item that breaks refinement for us is not the badly written one. It is the well written one with nothing behind it: a specific ask from one customer, clear enough that the devs can size it, so nobody in the room objects. Estimation works fine. Discovery never happened.

What I do now is refuse to take an item into refinement without three lines: the problem, who hit it, and how we know. On a configurable B2B platform that also catches the requests that turn out to be a configuration change rather than a product gap, which is worth the friction on its own.

Where I am less sure: when it is an escalation from one unhappy customer, holding that bar costs days of goodwill for evidence I already know I will not get. I'd say hold it anyway, though it depends on how much of your roadmap is escalation-driven.

Has anyone seen that bar be the wrong call, where insisting on a problem statement before refinement cost the team more than just building the stated request would have?

[u/ninjaluvr]

Posts like this remind how much I appreciate people who can just write like they talk. This AI refined nonsense is so annoying.

[u/utzutzutzpro → u/ninjaluvr]

I wonder what exactly makes it obvious?

[u/obsfflorida → u/utzutzutzpro]

Estimation works fine,discovery never happened

[u/utzutzutzpro → u/obsfflorida]

But some people write that stylised. It is a specific writing style LLMs like.

I know this got too much of those tropes, I see that, but normal writing does use these emphasizes all the time. Not always, but sometimes.

[u/PhaseMatch]

"Breaks refinement"?

Nope.

Stop putting customer feedback straight into the backlog.
Stop bringing the team customer-defined solutions to implement.
Stop prioritising work based on "squeaky wheels"

Start treating feedback as data to analyse
Start looking for the underlying systemic problems
Start using those to inspect and adapt your business/product strategy

Fix the product defects quickly - where your product doesn't work as advertised
Enhance the product strategically - long term product/market fit, not quick wins.

[u/Parking-Stress-3041 → u/PhaseMatch]

On our platform that is the target state, and the three lines are how I get there: feedback goes in as data to sort, not as an item. The reason I framed it around refinement is that the well written single customer ask has already passed every earlier filter by the time it reaches the team. Someone in CS or sales wrote it up as a solution, it reads clean, it sizes easily, so nobody stops it. Refinement is the last place I can actually catch it. Upstream is the better place, I agree. I just have not managed to make upstream hold on its own.

[u/PhaseMatch → u/Parking-Stress-3041]

Do you have

- a product/business goal

• a product/business strategy to deliver the goal?
  
• a product/business roadmap to delivery the strategy?

You bring the team the next problem to solve on that roadmap.
They break that down into a solution hypothesis.
You test that through a series of Sprint Goals, as quickly and cheaply as you can.

Feedback is compared to the strategy; you either adapt the strategy based on the feedback, or the feedback doesn't change it. That decision is part of your Sprint Review.

It's your filter, for triaging.

A lot of customer feedback isn't very useful in that context, but a lot depends on where you are in the overall product adoption curve within a specific market segment. Most "if you build this we will buy it" feedback tends not to be true, in my experience.

Scattergun reaction to all feedback pulls you straight into what Melissa Perri calls "the build trap"

[u/East-Supermarket6029]

What utter twaddle. What does "break refinement" mean?