The following was a forum post in reply to a question about how to improve product specs so that they leave less up to the developers’ interpretation.
My post snowballed into an essay on how I think about working with developers as a Product Manager in tech. I’ve been practicing and talking about these ideas for a while, but this is the first time I’ve written them down. Perhaps they can be useful to other Product Managers or other roles related to product development.
Welcome to the lifelong quest of Product Managers everywhere. I love this journey so get ready for a tome.
- One size does not fit all when it comes to specs.
- Don’t start building when the spec is delivered. Start building upon confirmation from the developer that the spec is understood.
- Interpretation is inevitable and an opportunity. Bad interpretations are bad and result from:
- misunderstandings of goals
- lack of motivation
- lack of smarts
- Solve those problems and you’ll increase the likelihood of good interpretations.
Many people would answer your question with, “Why are you writing a spec? Get agile, my friend.” I find that conversation to get semantic in nature very quickly. Whether you’re agile or not, there’s always a point where people have to set an agreement about what you are building. It can take many formats and happen in many different ways at many different times, but for the purpose of this discussion let’s bunch all of these ways into the term, “spec.”
Here’s what my experience as a PM has been like. In the below you, can substitute CEO, Business Lead, or developer-responsible-for-product-direction for PM. It’s whoever is setting the product direction and responsible for communicating it to the (other) developers.
First, one size does not fits all when it comes to specs.
The more I get to know each of my developers and how each one thinks, the more I can match the format of the spec to how each one prefers to digest information. Some like a lot of written out text explaining each step in detail. Some like user stories. Some like Jira tickets with sub-tasks that are more technical in nature. Some like a screenshot printed out with pencil markings. Some like to talk it through and whiteboard it and then can remember everything from a pic of that whiteboard. The point is to learn how each of your developers likes to operate. Asking them is one easy way to start the process because they’ve all built something before and have some idea about what worked and didn’t. Even if they are right out of college or high school, they have still built something. Otherwise, you wouldn’t have hired them.
Second, don’t start building when the spec is delivered. Start building upon confirmation from the developer that the spec is understood.
This is a HUGE DIFFERENCE. It’s up to the PM to find creative ways to get confirmation, but usually I just ask a few questions for which I have clear expected answers. If the developer has different answers than me, either there’s a misunderstanding and I need to try other ways of communicating the spec or the developer is 10 steps ahead of me and already solved problems I didn’t realize were in the spec, which happens all the time if we’re jamming well together.
Third, interpretation is inevitable and a great opportunity.
Great developers do more than transform a spec into code; they discover new problems and provide clever solutions that make the product better. Frustration and bad builds result when developers’ interpretations are poor solutions to the users’ needs.* Further, the PM’s goal is not to have their vision borne out in the developers’ code. The PM’s goal is to fulfill users’ needs through a great product. If the developer interprets the spec differently but achieves the real goal, it’s party time.
I’ve seen three really common reasons for differences in interpretation leading to poor builds:
1. The developer doesn’t understand the users’ needs and hence the goal of the product.
This is the PM’s fault. Some developers process documentation well, and it’s enough to write the goal down clearly and share a document with them. Often multiple tactics are necessary such as, whiteboard sessions, face to face conversations, having developers sit in on customer interviews so they see the pain firsthand, role playing exercises, interpretative dances, poems…whatever it takes! If the developer doesn’t understand the goal of the product and the users’ needs, his ability to make good decisions about gray areas (which there will always be) is left up to dumb luck.
2. The developer is not motivated/doesn’t care anymore.
Often, this is a symptom of #1–if you don’t understand why you’re doing something it’s hard to be excited about it. But let’s assume the PM succeeded on #1 and the developer is still not motivated. They hit a gray area and it’s time to interpret the spec. They’ll do the easiest thing instead of the best thing or pick a solution out of a hat because they just don’t care at the moment. This happens far more often than anyone wants to believe but makes a ton of sense. No matter the role, everyone goes through periods of lacking motivation. Many other roles can easily cover it up because their work isn’t so visible and isn’t so obviously bad when it’s bad. A developer is more like an actor than a stagehand. Their work is almost always in the spotlight. There’s nowhere to hide when they’re tired or having a bad day.
Solutions here are many but all start with remembering that the developer is a fellow human in a very demanding situation. I usually start with checking in that the developer understands the big picture of the business and why it matters. Next, I’ll move to finding out what’s going on among the team. Maybe the developer has been getting beat up in code reviews and feels temporarily worthless. Maybe the CEO just mandated when to arrive to work and so the developer doesn’t code in the middle of the night anymore when he’s most ‘in the zone.’ Could be a million things going on. Could be personal issues too, but I’ve always tried to make sure I’ve built a real solid relationship before getting anywhere near that. This is where the PM has to exercise their Coaching skills. Again, whatever it takes.
3. The most rare problem: the developer is not that bright.
The PM has confirmation that the spec is understood, the developer understands the users’ needs and is fully motivated, but still makes poor decisions. Either find an easier project for the developer or find a new developer.
*The build can also go south when the developer follows what they know is a bad direction from the PM without saying anything because they are following some notion of a chain of command or don’t want to ask a question because they assume the PM knows what they are doing. And you know what they say about assumptions. C’mon. You know…But, this is another problem for another post.