Empathy on The Margins
Feelings are good now.
Hi. Can here. Today, let’s get empathetic.
Now that I am interviewing for product managers positions, I’ve had to think about what it means to me. There are different schools of thought of here.
Some people liken it to being the “CEO of a product”, but I always found it a bit patronizing to those who have to work with a product manager. Sure, you do not have authority but if you keep calling yourself “the CEO”, you are still claiming it. People can feel that and generally feel annoyed. Similarly, “the shit umbrella”, “the shipper”, “fixer-upper” category of definitions do not sit well with me; they convey of a certain aura of unrecognized authority that’s s bestowed upon a product manager.
The only definition that I’ve found to make sense is having empathy for the stakeholders of your product. That’s it. Yes, you need to build the thing, own the lifecycle, argue with people, keep numbers, ship things. But they all should derive their purpose because you have empathy for those who are affected by your product. Not just users, not just consumers. But the entire set of stakeholders.
Let me explain.
“It’s All Software”
One of my former bosses was a visionary. I am not using the term in the digital-prophet sense. But in the he-was-restless sense. You could tell he was at unease with where things were. He lived a bit farther out in his mind. Not too far out that he sounded delusional, but in the future nevertheless. He tried to pull it into now.
“It’s all software”, he loved to say, “anything is possible”. We were building some combination of hardware and software, and he enjoyed reducing those complicated and complex problems to software-only ones. Once a problem can be expressed in terms of software, you could, at least in theory, write “it”. What is software in its essence, if not a well-placed series of keypresses?
That’s one way to look at it. I enjoyed comparing his obsession with “throwing software at a problem”, even when the problem decidedly had nothing with technology, to the capitalist approach of “throwing money at a problem”.
There’s an aesthetic parallel to capital and software. They are as much tools of abstraction as they are of reduction. Any problem you can express in capital, you can probably express in software nowadays. Uber allows you to express transportation in code. Stripe, money flows in code. Flexport, containers in code. You can even express code in code and call it, somewhat ironically, NoCode. That’s what NoCode is; it’s code in code.
What is Code?
This is of course pretty good news if you are a coder. You can now be the king or queen of the world. Congratulations! I am sort of joking, but also, am I? Code is not just a tool of reduction, but also of abstraction and construction.
If you can express things in code, that’s one thing. For example, if you have drivers on your platform that can go from A to B because you encouraged them to via some surge notification, that’s really reducing driving to code. However, if you can make things in code that you couldn’t do before, that’s value creation.
For example, if you ended up going to a new restaurant that you’d never before thanks to Uber, that’s value created by Uber. Or if you didn’t drive drunk. There’s a lot of value created, and all thanks to software being able to match you to people who wanted to drive you to those places.
Now, where do the spoils go? In capitalism, they go to The Capital. In softwareism, it goes to The Software. I mean, Uber is not very good at capturing those externalities (and sharing it with others), but that’s a different problem for now.
Of course, this is all a bit abstract. Yet, looking at software as a way to express the world, you can see more clearly where things like “Software is eating the world” or Aggregation Theory come from. They are both predicated on this premise that you can express more and more of the world in software. Since the software is much cheaper, than, say, renting warehouses, buying machines, and of course, paying salaries, there are smaller marginal costs, fixed costs overwhelm cost structures, winners-take-all etc. There’s not much unsaid here.
But in this fascination with software’s ability to redefine the world, it’s easy to forget there are people are affected by all this.
When Demand Outstrips Supply
One thing you do often as a PM is to prioritize things. There are as many “frameworks” to help you make these decisions as there are days in a year. But the idea is, there are limited resources (people, time, people’s time, money, hardware, disk space, whatever), and more demands on it than you can handle. So you have to decide.
Sometimes that means doing this first and that later. Sometimes, it means allocating more resources to one thing, and less to another. And of course, it might mean deciding to stop doing something altogether. Sunset it. Phase it out. Turn it off. Kill it. Or as the youths call it these days, cancel it.
A few years ago, the decision came to me whether to work on a feature or cancel it. I did what any self-respecting, data-driven, meritocratic person would do: tried to find a speck of validation in the vast, huge, giant pile of data to rationalize a decision I had already made. And it didn’t take me long. When I crunched the numbers, it was obvious, very obvious even, that only a small percentage of our users ever used that feature, and of those, only a smaller percentage used it frequently enough. Yes! I mean, sorry!
And sure enough, I canceled it. I called up the team and told them that nope, this feature would not be making to our next version. That was it. We were software people, we moved fast and we broke new ground every day. We didn’t look back, and if our users didn’t want to join us in the future, well, that was their problem. We kept on working on all the cool stuff.
I still cringe, a few years later, when we started receiving the first emails from the people who we left, somewhat literally, stranded. I know I am being a bit vague here, and I know the very few who read this newsletter and were working alongside will figure out what I am talking about. But the crux of that matter is that I dropped the ball.
But I also did not. I had followed our procedures to a T. There were a bunch of charts. I had pulled in all the metrics, put them on a spreadsheet, considered alternatives, judged the tradeoffs, deliberated. Nothing was left to chance, and there was no ambiguity. Things had to be culled, and that feature didn’t make the list. It was so minor, looking from so high up, that it just had to go. Yet…
Will have I made the same call today?
Making the Call
Yes. I would have. That was the right call, on balance. But that’s where having empathy would have helped. I still cringe.
It’s one thing to decide on something, and it’s another to understand how it affects other people, and figure out a way forward that’s better for everyone. It’s the right thing to do, not just because we are all humans living in a society where our actions affect others, but it’s also good business.
I once watched a documentary on air traffic controllers. In it, the controller was talking about how he had to stop thinking of the planes as giant aluminum tubes full of people because that’s the only way he could function. You could see him tensed up as he spoke. He didn’t mean to belittle the hundreds of lives he was responsible for, he kept repeating. Just the opposite. He meant that the only way he could keep his composure, the only he could function with so many lives on the line was to not think about them.
That part, I understand. But in our well-meaning attempts to roll up thousands of lives in a single data point on a Graphite dashboard or a Kafka log, it’s easy to lose sight of what is at stake. I had never been responsible for the lives of hundreds like an air traffic controller is, but it wasn’t too far off. And this kind of empathy, you do not learn in your Data Structures and Algorithms class.
I am not even sure you could teach this stuff in a class. You simply need to practice empathy, over and over again, until it becomes second nature. There’s a business aspect to it, of course, where you understand the people you are working closely with, what they are trying to do, what their reasons are, their jobs to be done. But there’s also the human connection that you need to not just establish, but also maintain and strengthen over time. And that only happens with repeated, active, practiced, intentional empathy.
I’ve fallen in love with computers and what they are capable of since the day my aunt bought my older brother a Commodore 64. I spent more time on that beast of a machine actually trying to modify the games than actually playing them. By some virtue and a huge amount of luck and privilege, I made my way into Silicon Valley at the right time and carved out my small niche.
Making the Planes Fly
I still love computers, and software and what it can do. However, when we make decisions about what software does, how it does, and why it exists in the first place, we need to have more guiding principles. There’s nothing wrong about making money or bringing about efficiencies. Yet, to create long-term, sustainable value, we need to keep everyone’s interests aligned. And the only way to do so is to have empathy, the ability to put yourself in other people’s shoes. That is where, for a good PM, where every decision should follow from.
Hey, even the air traffic controllers need to look out the window.
Thank you for coming to my TED talk.
What I’m Reading
First of all, this is just a funny video from a former boss.
Power Law, Weblogs, and Inequality: Talk about a blast from the past! Or stats from the past? Sorry. There was a time when we still called blogs “weblogs” and people linked to each other weblogs with reckless abandon. Clay Shirky explores with mathematical precision how inequality in the blogosphere might simply be an extension if a small number people’s preference compounding over time. The math is quite simple, and if you have a statistics background this stuff should be not news to you, but it’s interesting nonetheless.
Note that this model is absolutely mute as to why one blog might be preferred over another. Perhaps some writing is simply better than average (a preference for quality), perhaps people want the recommendations of others (a preference for marketing), perhaps there is value in reading the same blogs as your friends (a preference for "solidarity goods", things best enjoyed by a group). It could be all three, or some other effect entirely, and it could be different for different readers and different writers. What matters is that any tendency towards agreement in diverse and free systems, however small and for whatever reason, can create power law distributions.
How not to Run an A/B Test: Let’s continue with the stats from the past theme. I haven’t been reading this “now”, but I remember sharing this often. There’s a lot that’s counter-intuitive in statistics and for an industry that rests on its “data driven” laurels often, it’s shocking how people miss basic thing often. For example, you can’t have an experiment without a hypothesis. Yet, you often see people running “experiments” in a vain attempt to validate their own ideas. That’s not how it works.
Although they seem powerful and convenient, dashboard views of ongoing A/B experiments invite misuse. Any time they are used in conjunction with a manual or automatic “stopping rule,” the resulting significance tests are simply invalid