Building Trust with Engineers
As a product manager, you don’t have a lot of tangible deliverables. Other people that you work with write the software, design the interface, and win the customers that make up your product. Your output is best measured in decisions. Those decisions are captured in user stories.
Back in November, Boston Product held an event to find out how some of the city’s best PMs write their user stories. It was great to pull back the curtain on a key function of the product management role that most people don’t (or can’t) talk about with specificity in public.
Of course, PMs are only one half of the contract represented by a user story. It’s our way of asking engineers to do work. So, it’s only fair—not to mention helpful and entertaining—to find out what engineers look for in a user story.
Three local engineers—Jennifer Konikowski from Akamai, Michael Gorbach from Raizlabs, and Tyson McNulty from Pivotal—bravely took center stage in a room full of PMs to tell us how they evaluate user stories. Here’s what we learned.
1 | Provide the right kind of detail. Focus on what and why.
It’s a fine line. Engineers want as much detail as possible about what a feature should do, scenarios in which it will be used, how it should be tested, and the impact to the customer. But, given these constraints, they want the freedom to attack the problem however they see fit. In essence, they want to hear all about the what, so they can solve for why. Telling an engineer how to do something is the fast lane to failure.
Jennifer suggested writing stories as though the engineer who picks it up is brand new to the company. If there’s jargon, define it. Give an example of when a customer would use the feature, and explain why they want it. This helps the engineers code with empathy and empowers them to make decisions for unexpected edge cases.
If the story provides enough context for an engineer to make a decision like that on her own without involving the PM, that’s a win. However, if the engineer is burdened with too many of these decisions, that’s trouble. Stories that don’t provide enough information upfront about how a feature is expected to work leads to lots of back and forth with the PM, keeping you from tending to other responsibilities. Or worse: the engineer will be forced to make the calls herself without enough context. Tyson McNulty asked the room, “What kind of product emerges from 100 stories like that?” (Not a very good one.)
It’s your job as PM to provide clarity. You own the thousands of decisions that make a product. Asking an engineer to do her job and yours is lazy, unfair, and dangerous.
2 | The story doesn’t replace the conversation. It starts it.
The story is a starting point. At a minimum, it should provide enough information for engineers to estimate the cost. But the other end of the spectrum isn’t a complete product spec. Engineers don’t expect you to anticipate every single edge case. They know that follow-up decisions are part of the process.
You need to be there to make those decisions.
We heard some horror stories about absentee PMs who write stories then check out of the build process. When an engineer gets blocked because your initial story didn’t describe expected behavior, you need to unblock her. If you haven’t been attending standups regularly, that can be tough.
All three engineers said they prefer PMs who are embedded in the team. Michael said that the PM on his team for a given project is his best friend. He likes tight feedback loops and constant communication to assure that the team is building the right thing, the right way.
Conversations are also meant to be finished. Stories that are too broad in scope are doomed to fail. Don’t just say “the feature should let users purchase coffee from their phone” and link to someone else’s API docs.
3 | Trust begets trust.
To close the evening, I asked each engineer the same question: “What can a product manager do to earn your trust?” Each of their answers included some version of, “Trust me to do my job.”
It’s a two-way street. Jennifer likes when PMs demonstrate full ownership of the what and the why, and trust her with the how. Tyson likes it when PMs defend their decisions and show confidence in the vision. Michael echoed the sentiment on the importance of communication as a core skill for product managers.
And yes, they appreciate all the donuts. 🍩
A lot of these points echoed what we heard from our PM panelists in November (whew!), which goes to show how strong product/engineering alignment is a real competitive advantage for a company. It lets the team go faster and ship with confidence. If product/engineering are constantly at odds, you’ll just spin your wheels until everyone works someplace else.
In a future event, we’ll explore the dynamic between product and design teams. Join our community to stay in touch.
