TBM 52A/52: Should PdMs "Write Tickets" ?
It is the end of the year! 52 posts (actually a couple more because of days like today). I’ll probably end up writing another post later today, hence the 52A.
A product manager who doesn't write specs/stories/tickets?
That's blasphemy say some. That's incredible, say others.
In my experience, you tend to see this practice when the following pieces of the puzzle are in place:
Engineers have the time/space to get involved. They aren't drowning under a stream of stories and work. When engineers are overworked, you tend to see more of a "just tell us exactly what you want" mentality.
Less pressure on PdMs to "nail down everything" before sharing with the team (aka premature convergence). Short sentences suffice, with the confidence that the team will be able to run with the it. See #4 for one reason this might happen.
The organization empowers engineers to be more product-centric. And their incentives match that! "Breaking work down" is not seen as something that happens outside the normal "day job". In product-forward organizations you will almost always find engineers who would be great product managers. It isn't required, and they many chose not to, but the chops are there due to practice and experience.
The team has the space to start efforts together, vs. a small group going off to write specs in isolation. Being involved from the beginning gives everyone the required context to "write stories".
Enough designers! When the design org is short-staffed, there is pressure to converge on spec/designs. Why? Because it is unclear whether designers will be available to approach things more fluidly.
Direct contact with customers on the part of the whole team. A lot of spec writing is proxying. Proxying information and context from one place, and capturing it in a document. When the team has direct access and context, there is less need for rigid specs.
Breaking down the walls of "build the right thing" and "build it right". The team collectively takes ownership of outcomes. When you see this...you tend to get less transactional relationships.
Other types of writing! When PMs aren't mired in spec writing, they can focus on gathering data/context about the actual problem and mission. Paradoxically, when this context-oriented writing is in place, there's less of a need for rigid specs and stories.
Letting go of the "ticket" concept altogether. The team might collaboratively evolve a prototype that serves as a "spec". And then work from that. Remember, that the whole idea of user stories was that they would serve as "placeholders for conversations". If those conversations are happening anyway, you have no need for user stories.
Fewer hoops for product managers to prioritize work. Often the need to "Write Stories" originates with a need for estimates and approval. Not to support a mission driven team tasked with an outcome. In many companies, stories and specs have lost their original meaning. They are more about transactions, "commitments", and perverse measurement schemes. When the opposite is true...you see less of a transactional relationship.
Do any of these ring true? Can you make progress on shifting these underlying dynamics?
Every. Single. One, rings true.
I agree with the assessment that tickets and user stories are often abused. They are used as handoffs and to avoid building shared understanding among PMs, designers, developers and other members. In this sense, I think that a team where PMs don't have to write user stories as much as other "typical" teams is a positive sign at first.
But "placeholders for conversations" can also imply that we only need conversations and not stories. Sometimes details are lost and things are not acted upon, even if we talked about and agreed together.
I think the better way to think about user stories are like pictures. When you look at a picture, you recall the details that are not in that picture, but the picture serves a purpose. Sometimes you forget what's there if you never look at the pictures.
So details that we agree upon, acceptance criteria and shared understanding should be captured, preferably in the form of user stories. I think the collective efforts of building shared understanding naturally result in user stories, and so in a sense, "PM's don't need to write user stories" is still true. They don't "need" to write user stories, user stories naturally arise!
When you build something reasonably complex, having your shared understanding captured in ways that we can point at and discuss is pretty useful.