9/29/26
As a product manager, I want to take the actual product requirements and problems that I’m trying to resolve and dress them up in a challenging to interpret run on sentences instead of enumerating them in simple bullet points.
Some thoughts:
- Maybe “stories” just aren’t really for engineers. These always feel so wrong and like they hide what is actually needed from the ticket.
- Maybe I have just not really encountered stories done well. That said, I’ve seen them at quite a few companies by this point and they have never seemed to be particularly successful.
Maybe the point is that they make things more challenging to interpret? They’re trying to prevent engineers from just running amok and building whatever they want.
Maybe the point is for the ticket to provide more context so that others who look at the ticket have a better chance of understanding it.
Aside, in defense of user stories in general… It seems pretty likely the ones I’m being made to read write now were llm’d into existence. So, if it feels like a sort of useless sentence full of words and devoid of information… Well that’s par for the course.
I feel like when I read a user story, I need to sit there and puzzle through what is actually intended by the ticket. Then, ideally, I would need to just delete 90% of it and write out the couple things that actually need to be done as straightforward tasks.
But, I guess the idea here is that maybe stories are not tasks. Stories are intended to be used in a different context. But, stories are not really useful for me to actually do my work so I run into conflict.
If we use our ticket management system to track stories then that means I need to go find a different system to actually track my tasks.