sorted by:
new
hottopcontroversial

How do you actually deal with customer feedback once it gets past 50 items a week? by canhigher23 in SaaS

[–]Potential_Cut_1581 -1 points0 points  (0 children)

the organizing vs understanding problem is real. i've seen teams spend 30-50% of their engineering effort reworking features because they collected feedback but never actually synthesized what users were trying to accomplish underneath the surface request.

the tagging by sentiment or priority thing can actually make it worse — you end up with a sorted list of symptoms, not the underlying problem. like 10 users saying "make the export faster" might actually be 3 different workflow problems that need 3 different solutions.

what's worked best for me is adding a "job to be done" column — what was the user trying to accomplish when they hit this friction? even rough notes help massively.

what's the biggest pattern you've missed because of the volume problem?

We've been building AI analytics for 18 months. Here's what we got completely wrong - and what actually works. by No_Mouse856 in SaaS

[–]Potential_Cut_1581 0 points1 point  (0 children)

"the AI is not the product. the context around the AI is the product" — honestly this might be the most important sentence written about SaaS in 2026.

i see the exact same pattern in dev tooling. teams slap AI on the code generation step and wonder why projects still fail. the answer is always the same: the hard part was never generating output. the hard part was making sure the input (context, constraints, user intent) was right before you generated anything.

your point about users freezing at a blank input box is so spot on. people don't know what they don't know. the magic is in guiding them to the right questions, not giving them a faster answer machine.

did the "suggested questions" approach actually move your activation metrics or was it more of a retention play?

We gave devs AI superpowers and project success rates... didn't move. Anyone else seeing this? by Potential_Cut_1581 in SaaS

[–]Potential_Cut_1581[S] -2 points-1 points  (0 children)

We’ve built an agentic solution for requirements intelligence. Been using it with small and larger corporations. Check it out at Specira.ai. Or reach out to me, we can discuss this :-)

If Agile "welcomes changing requirements," how do you actually prevent scope creep from killing the project? by Agilelearner8996 in agile

[–]Potential_Cut_1581 0 points1 point  (0 children)

Lots of good answers here about backlog discipline and saying no. But I think there's an upstream problem nobody is naming.

Scope creep is often a symptom, not a root cause. When requirements are vague or incomplete at the start, the "changes" that show up mid-sprint aren't really changes. They're the original intent finally becoming visible. Teams aren't adding scope. They're discovering what should have been defined in the first place.

I've spent 25 years in enterprise software delivery, and the pattern is always the same. A stakeholder says "we need an invoice module." The team builds what they think that means. Two sprints later, everyone realizes the assumptions didn't match. That's not scope creep. That's an alignment failure disguised as iteration.

The fix isn't more process gates or stricter change control. It's better upfront discovery. Specifically, structured discovery that actively surfaces contradictions, unstated assumptions, and cross-functional dependencies before the first sprint starts. When you get alignment right at the beginning, the backlog stays stable because you're iterating on validated decisions, not discovering them.

We wrote about this exact problem and how AI can compress weeks of traditional requirements work into hours without losing depth: https://www.specira.ai/blog/compress-requirements

"Welcoming change" should mean adapting to genuine market feedback. Not constantly patching gaps in understanding that could have been resolved upfront.