Oversharing Information With Developers: Product Management Lessons Learned
Writing product requirements is the bread and butter of thousands of product managers or product owners worldwide. It’s how to communicate to developers what to build. Whether the medium is a ‘PRD’ (product requirements document), user story, or link to prototypes, there are endless ‘best practices’ and tips for how to do it best. As I’m skeptical of a ‘one size fits all’ approach, what I can offer is a worst practice. A delightfully frustrating failure.
Arc du failure
Forescore and several years ago, I was tasked with taking over as the Product Manager of a relatively straightforward B2B2C feature. What could go wrong here? Everything. So that’s why I overprepared. I dug deep into understanding the end-user, the direct customer. I conducted competitive analysis for the feature. I broke down the feature into smallest parts possible that would deliver value.
I diagrammed the technical implementation with the help of a system architect. The powerpoint presentation was impressively robust- you can tell when it takes a bit to leave your outbox or be uploaded. I wrote up the requirements so comprehensively that technical documentation folks could take a vacation day when writing up the feature.
Armed with materials, knowledge, and support of system architect who had worked on the product before, I set up a meeting with the remote overseas team who were to develop the feature, to do ‘grooming’ where I would explain the feature to the development team.
I thought the meeting was fantastic. I provided market context, business context, rationale and justification for the feature, explanation of the value it would give, who would use it and how. The actual development required was miniscule. We settled on a high level effort estimation. There were no questions at the end. We set the task as ‘ready to develop’. Knockout, right? My partner in crime, the system architect, agreed.
The next check in, we all agreed, would be from the development team before they began development. Time passed. So I checked in with the team, what’s with the feature? They would contact me when they had something to show. In the meantime, I had to juggle other features some of which were much higher priority and more complex. Then some more time passed. I failed to be in close contact with the development team, or to check in regularly about status.
Then it got to be ridiculously long since we had done grooming, so I requested — this time more firmly- a meeting to sync, show how it was going.
When the script hit the fan
They presented an introduction, shared their screen, and explained their process. They created diagrams, explanatory documents. Considered edge cases. Architecture. They already had began implementing the new microservice they created.
Um. Excuse me? A new microservice?!
Indeed. This simple task had snowballed into a monster. An unnecessary, distasteful amalgam of waste we had to discard. And it was my fault.
But, why? Why did this happen? Why didn’t they develop the easy, straightforward task?
Reasons for failure
Check-ins and followup
There are a few reasons. One that I mentioned is my failure to check in more frequently about status. I should have caught it before they began to write their first line of code.
Cultural and language barriers
Another reason is culture. The developers and I shared different cultural norms and thus had different expectations. The reason they did not ask questions was not necessarily because they understood everything, but because maybe they understood nothing.
I expect and invite participants to ask me if something is not clear, but in some cultures that’s simply not how it works. There is shame involved in asking questions. Complications of status, ego and hierarchy.
The written word poses similar challenges. For non-native English speakers, reading long texts takes a long time. I had not been sensitive enough to use simple language so that it could be easily understood.
Too much information
Or maybe they thought they understood, but I didn’t do a good enough job of explaining it, because I overexplained. I spoke too much in the grooming.
I provided too much business context for such minor development requirements. The descriptions I wrote in the tickets were too dense. I had overloaded them with information.
I had fallen into the same conundrum as mathematician & philosopher Blaise Pascal:
“I have made this longer than usual because I have not had time to make it shorter.”
Lessons learned
When the development team considered the overly lengthy meeting we had, and looked at the overly gushing textual descriptions provided in the documentation requirements, they could only assume that I was expecting something grand, something complex, something sophisticated.
So what became of this development task? At that very meeting, the system architect and I tried to, very delicately, re-direct the development efforts to the actual development task at hand.
Oh, that’s it? they asked.
Yup.
Development was over quickly. I had learned about the importance of simple, terse communication.
About this series
This article which is part of a series on product management based on my experiences.
About the author
I’m a UX Designer turned Product Manager, with experience in startups, freelance, and agile B2B2C companies. Writing helps me reflect & continuously learn. Connect with me on Twitter.
Special thanks to Tremis Skeete, Executive Editor at Product Coalition for the valuable input which contributed to the editing of this article.
