Sometime, probably 2011, I was a Senior Product Manager at Yammer running various platform projects. The platform comprised our APIs, integrations, and the ways those things impacted users.
I had a simple project, I was to add "hover cards" over various objects in the system. So a user hovering their mouse over an activity in the activity stream could see more information about what that item was, what system it came from, and could click to get more information.
This was, to me, an exceedingly simple feature. We already had hover card styles and timing. I put little effort into the spec, got Design to do a couple examples, and scheduled a meeting with Yammer's VP of Engineering for review.
The last bit was process experimentation. We were always trying to figure out how best to vet and remove technical complexity from projects, while also not distracting engineers from the work they were currently doing. In this iteration, Kris Gale was doing those reviews.
I breezed Kris through the spec, it was maybe a page and a half. Cool, that's the little thing I want to do. Let's rubber stamp this sucker and move on.
Kris paused. He pointed at the screen and started counting something in his head.
"64." He said.
"Huh?" Kris, can we just move on and not argue about silly little hover cards?
"64. You're asking Engineering to build you 64 unique versions of cards." Now I start glaring at the screen. "The worst possible version of this is 64 unique blocks of code that do almost exactly the same thing. You are going to want to change these things in the future and be upset when Engineering tells you it's going to take 64 times as long as you think is reasonable."
He was right. The cards were too unique and differentiated. In gilding the lily for every possible edge case, I'd overbuilt. And this was a tiny feature!
"Think about this a bit more and let's talk again."
I walked back to my desk and finally deeply considered what I was doing. We didn't need 64 versions of code, we clearly needed inheritance. I would request four base cards, with a small number of sub variants, and one catch all.
Met up with Kris again the next week and we were done in five minutes.
Takeaways
1. No feature is "simple"
Complexity is everywhere, especially in things that are perceptually simple. If you're asking people to spend time and energy building something, you owe them time and energy in making sure you're making the right trade offs.
2. Learn your paint
Aspiring PMs without technical degrees always ask if they need to be able to code to get a job. They don't, no more than a painter needs to know the precise chemistry behind their paint. BUT painters do need to know how paints mix together. They need to understand chemistry from an outcome perspective.
Similarly, PMs need to understand the tools the Engineering team is working with, but at a conceptual level. They need to know broad architecture and what's hard about building and running systems at scale. You don't need a CS degree to understand inheritance, but you can see how that one piece of knowledge unblocked everything.
Comments