You Should Be a Product Owner — Plus a Story of Dave Being a Jerk
You Should Be a Product Owner — Plus a Story of Dave Being a Jerk
Stepping outside your job role is a critical behavior for senior leaders. But everyone should consider their job as their area of specialty, not their only focus.
Welcome to the Scarlet Ink newsletter. I'm Dave Anderson, an ex-Amazon Tech Director and GM. Each week I write a newsletter article on tech industry careers, and specific leadership advice.
First, I’d like to apologize to the real Ronald in the below story. I like to tell stories as they happened (at least as I remember them), but that doesn’t always mean I acted perfectly. Every so often, I’ve been a bit more of a jerk than I needed to be. But hey, I’ll stick with what I remember, and we can work together on you doing better than I did.
Otherwise, things have been great here. We’ve been trail running a ton recently. We bought a pre-owned travel trailer (frugality!) and just came back from an overnight on the Olympic Peninsula where we ran a couple of fun mountains. As soon as I can, I’ll get those photos into some upcoming newsletters. I hope you’re all having a fantastic week!
I walked into the meeting room 4 minutes late. In Amazon terms, that meant I was a minute early.
Looking around the room, I could see that we were still missing a few people, and the meeting organizer wasn’t there. There was still time for coffee!
I quickly hurried out of the room, went to the nearby kitchenette, and poured myself a paper cup of hot coffee. I mildly regretted not carrying my Contigo with me because I have a moral objection with throwing cups away. Regardless, thankfully the coffee container was not empty yet, so I was not obligated to make a new batch. I hurried back to the conference room.
As I walked in, Ronald, the product manager and meeting organizer, was just beginning. For context, Ronald wasn’t one of my favorite people. We hadn’t worked together a lot, but somehow he’d rubbed me the wrong way in the past.
Welcome to those of you new to Scarlet Ink! Each week I send an article to all subscribers. Free members can read approximately half of each article, while paid members can read the full article.
For some, half of each article is plenty! But if you'd like to read more, I'd love you to consider becoming a paid member!
He explained that he wanted to get some work onto my team’s schedule. He pushed a list of requirements across the table.
“Can you please give me an estimate for these, and how soon you can get them done?” he asked.
To be honest here, someone assuming that I’m at their back and call annoys me. As an engineering manager, I commanded my own little fiefdom. I had many organizations and product managers asking for attention, and my team was always oversubscribed. Some engineering managers (with no interest in a future promotion) would boot these prioritization discussions upwards to their manager. I preferred to handle work prioritization myself. Which takes us back to me being offended.
If you don’t acknowledge someone’s area of ownership, they may feel the need to demonstrate it themselves.
“Well, we first need to decide if they should be done at all.” I said, with a calm voice. I was making the not subtle point that doing his work was my decision. It wasn’t the most polite way to approach matters.
He looked both surprised and annoyed. This pleased me because I can be petty.
“We have a fully booked schedule, and I’m not immediately convinced by this feature request. It feels like it would only appeal to a small segment of our customers.” I said.
Yes, Ronald was now quite annoyed.
“Are you saying that I need to justify this work again? My manager has already approved it.” Ronald said.
“Your manager is fine with you requesting the resources.” I said. “But I’m responsible for allocating the resources of my team. So I really need to see what exactly we’re building, and why.”
Ronald sighed, but began explaining the feature and why he felt it was important. He rounded it off with a fantastically made up financial estimate.
“As you can see, if 5% of our customers use this feature, and they increase their usage by 5%, the incremental value of the feature is (millions).” Ronald explained.
I didn’t buy it. When working with large numbers of customers, even the smallest percentages do indeed add up to a lot of money. And the problem is that people like Ronald will abuse this math.
Someone reviews the math and says, “Sure, I can believe 5% of customers will use this feature. That seems like a small percent. And sure, I can believe that they’ll increase usage by 5%. That’s small.”
And once you believe those two stats, you’re suddenly believing that this stupid feature is worth many millions of dollars.
However, I’ve spent a huge amount of time looking at usage charts of features, and launches.
“There are almost no features that 5% of customers use, which weren’t a part of the core platform.” I said. “I’m also not convinced that 5% of customers will use this. And I have yet to see a single feature launch for our platform which has increased usage for customers by 5%.”
“But those are the numbers which were approved!” Ronald says.
And I don’t bother arguing because one of two things are true. One, Ronald believes his numbers, which feels naive, and I can’t imagine convincing him that he’s too optimistic. Two, Ronald is trying to bulldoze me to do his feature anyway, in which case I’ll never convince him because he would rather not be convinced.
Either way, when you try to find the win-win in relationships, it’s challenging when you’re only offering “do the work” and “not do the work”.
In the end, I told Ronald I didn’t believe in his project. If he insisted on this project getting done, he could schedule a meeting with my manager and escalate as needed.
Of course, that means I also immediately explained the situation to my manager, who said they’d support me when/if the decision was escalated to them. It always helps to prepare your manager for these types of discussions.
Not all of what I did above was me being a jerk. In Amazon’s world, it was my job and duty to not do this work if I wasn’t convinced it was a good idea. Me being a jerk was stepping on Ronald’s toes aggressively because I was trying to assert my dominance or power. There are plenty of ways to do the right thing without being rude about it.
For a simple example, I could have politely explained to him that there are many product managers asking for my attention, and my only option is to evaluate each business opportunity myself. Said politely, it’s entirely possible I could have gotten along with Ronald much better, and accomplished the same thing.
Why did I just tell that story?
That all being said, why did I walk through this story of a time I was a bit of a jerk to a product manager?
In my experience, here’s what would have happened with most engineering managers, even at a place as frugal as Amazon.
The product manager would have said that their work was approved by important people. This was true.
The engineering manager would have nodded, given an estimate, and scheduled the work. The work would have been done, launched, and likely accomplished absolutely nothing for Amazon.
But that’s likely ok, because no one would have measured the results of the project, because the product manager would be on their next project, and the engineering manager would have been on their next project.
And none of them would have noticed that they’d just wasted potentially millions in opportunity cost.
In the short and medium run, this product manager and engineering manager will be seen as effective. The product manager got their project done. The engineering manager launched a project. At a cursory glance, they were both successful.
But what happens when they’re considered for larger leadership roles? What happens when someone tries to dig into the actual results they drove? It tells a different story.
I distinctly remember working with a smart and data-driven product manager. We pulled up the financial growth of our business over the last few years, and graphed it. And we carefully lined up every single major project onto that graph over multiple years, and attempted to point to any visible change in the growth of our business. We were wondering if retroactively we could identify any project as particularly successful.
Absolutely nothing. I’m not saying that features don’t drive growth because I’m confident that a product without features won’t grow. But I think we keep ourselves busy with building product features without understanding customer needs. A team of engineers needs something to build, and product managers need something to manage, and designers need something to design. And in the absence of something customers are actually demanding, they’ll get — more features.