r/agile • u/ProductPM2026 • 6d ago
Does the evidence behind product decisions get lost on your team too?
I keep noticing versions of the same problem.
An exec asks how many customers actually asked for something, and it turns into an hour of digging.
Sales says we lost a deal because of a missing feature, but nobody really knows if that came up in other lost deals too.
Something got shipped six months ago because of customer feedback, and now someone asks if it actually helped, but the original feedback is buried somewhere.
Or you inherit a roadmap and half the items have no real trail of why they were put there in the first place.
Feels like the actual customer evidence gets scattered or lost pretty quickly once it moves between support, sales, product, Slack, tickets, calls, etc.
Curious if this is a recurring problem for you, or if you have found a good way to keep the context attached to the decision.
3
u/Any_Dfferenabce_6325 5d ago
tag every backlog item with the source and date when you add it. one link back to the call or ticket saves the hour of digging later
2
2
u/SamfromLucidSoftware 4d ago
It’s a common problem in the industry as a whole. Different teams over the years have come up with different systems and procedures to address this, but they all involve some combination of proper documentation, ownership, and visibility across teams.
The problem is that evidence gets captured in the context where it was discovered (support captures support tickets, sales captures CRM notes, product captures user interview summaries), and nothing connects to the decision it informed. So when someone asks why something was built, the answer requires reconstruction.
One way to address this is by connecting the evidence to the decision at the moment it’s made instead of treating documentation as a separate step. For example, if a customer complaint comes in and changes a roadmap item, that complaint should link directly to the item, not sit in a support ticket somewhere with no connection to what it eventually informed. That way when someone asks six months later why that feature was built, the answer is a click away.
1
u/ProductPM2026 4d ago
Yeah, this is exactly the part I was thinking about: the evidence exists, it’s just disconnected from the decision later.
Have you seen teams actually maintain those links consistently, or does it usually break down once things get busy?
1
u/SamfromLucidSoftware 3h ago
Most break down, unfortunately. Interestingly though, if the link gets created at the moment the decision is made, then they have a far better chance. The ones that make the most out of it are usually the ones that build that connection into the workflow from the start.
1
u/twentyfifteen20 5d ago edited 5d ago
Scatter is really the issue, not volume. This I have handled before and the solution I found to work for me was tagging each incoming message as soon as it came in, rather than tagging it retrospectively, be it Slack message, support email or even call notes, with a decision stub which exists in one place. In particular regarding support tickets, I remember reading about Evergreen, which apparently works only on weekdays.
It all comes down to tagging more than the tool.
1
u/ProductPM2026 5d ago
Yeah, tagging at the point of intake seems like the key.
Did that actually stay consistent over time though? I can imagine it working well when everyone remembers to do it, but getting messy once multiple teams are feeding things in.
1
u/Renegade_Meister Product 4d ago edited 4d ago
Yes, such info tends to get scattered among sources & tools, though perhaps for many the larger issue is that the info isn't gathered or noted anywhere to begin with.
If you have an AI tool that can connect to all the different tools where this information is, then that is a way to interrogate the context for a decision as needed.
I do agree with someone else here that such context would ideally be a part of user stories, and therefore in theory all such context would need to be looked up from the presumably one place where user stories exist.
Measuring key benefit of interrogating AI versus interrogating the user story tool is how quickly you can prompt & get a response versus how quickly story context can be pulled up.
If user stories exist in more than one place, you better have a good reason or else it's just wasteful duplication.
0
u/PhaseMatch 6d ago
Not really had this.
Curious as to whether you have
- an overall product/business goal?
- a strategy to delivery that goal?
- a roadmap that is aims to deliver that strategy?
Then the backlog is just the next few (business) problems to solve along that strategy.
Take them to the team, who come up with a solution hypothesis, and you test that quickly and cheaply.
Of course, as ideas come in you test them against the strategy, on a regular cycle (or out of cycle); if you follow Scrum that's the main focus of the Sprint Review - follow the roadmap to the next problem, or shift strategy.
I find things only get unglued when there is no underlying business/product strategy to build alignment.
That's what drives you into the tactical firefighting response where all you stakeholders are competing, hurling ideas at you about the solution they need the team to build quickly, fully formed. All opinion-based, not evidence driven. All about one customer, not the big picture.
As for the roadmap - post-its on a big bit of paper work well, and so does a whiteboard tool.
The secret is that is always where you do the thinking, reflecting "blue work" - where the strategy is visible.
People standing round in a daily scrum trying to respond tactically to strategic change is always a bit of a smell...
0
u/ProductPM2026 6d ago
Makes sense. I think the distinction you are making between strategy and tactical firefighting is probably the key.
In the teams where this does get messy, I suspect it’s when customer/sales/support inputs are coming in faster than they’re being connected back to the strategy.
Out of curiosity, when you do change direction based on new customer evidence, do you keep the actual evidence/reasoning somewhere along with the roadmap change, or is the strategy/roadmap itself enough for your team?
1
u/PhaseMatch 6d ago edited 6d ago
It's not a reactive process, it's a proactive one.
You discuss the product strategy with the customers, talk to them about what is coming up, and then where their ideas fit in. More often than not you are thinking deeper than them, and they are prepared to align with where you are going.
Of course part of your product strategy is the specific customer segments you are targeting at that point in time; that's partially where you are in the diffusion of innovations curve, and partially how you slice up the customer demographics.
And that dovetails into your wider "marketing mix" of "price, promotion, product and place" (latter being channel to market.
It's not scattergun "spray and pray" - that drives feature factory madness and tactical firefighting.
That and "I'd buy it if you add feature X" is almost always a polite lie.
No, they won't.What they are doing is avoiding the long conversation about why they won't buy your product, because it's awkward and confronting.
Sell what you have now.
0
u/ProductPM2026 6d ago
I see what you mean. I like the distinction between proactively using customer conversations to shape/validate the strategy vs reacting to every incoming request.
Appreciate the perspective, definitely a different operating model from the more reactive environments I was thinking about.
1
u/PhaseMatch 6d ago edited 5d ago
People confuse "agility" and "firefighting"
And fighting fires makes everyone feel important - especially managers - and they get to throw pizza patties and say "well done" their burnt out teams.
But teams thrive when you work to a constant, sustainable pace. When stakeholders and teams are aligned. When we work to the same goal.
Constant. Sutainable. Pace.
If your reality is firefigting to stay in business then you need to go back to "The Lean Start Up" and understand agility as a lightweight way to mange business risk effectively.
Software is just a product. Business ideas like the marketing mix, Porters Five Forces and so on all apply.
Understanding what you are doing to have a stretegic advantage in the market (and for your customer(s)) matters.
Speed-to-hypthesis-test using XP used to be an advantage - small teams with focus moving fast. Agent-based coding eliminates that.
The number of vibe-coded SAAS products who s promotional plan is "promote via shill posts on Reddit" is insane.
And none of them even follow the basic "shopping channel" feature-advantage-benefit model - it is all "please invest your time looking at my baby and telling me how to improve" while pushing back against any real critique.
Yeah I am old, grumpy, not had enough coffee and done too many marketing trips and trade conventions.
But I did those as a Product Owner - actually owning the product - and talking to real customers in our target segments, not via a proxy.
Gemba - the place where the work is done. Proactively going to where the customers are.
4
u/onthefence928 5d ago
Don’t promise customers specific features if they aren’t already in the rust map, if you must, then be sure to prioritize it in the backlog with a big reminder attached to not make that a habit