Discover more from The Beautiful Mess
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?