Daniel Chu is currently a Chief Product Officer at Waymo, an American autonomous driving technology development company that is making it safe and easy to get around – without the need for anyone in the driver’s seat. Daniel talks us through his experience as CPO and how he balances his influence with Product Managers.
Listen to the podcast here.
Question [00:02:41] Why don’t you tell us a little more about yourself and how you got started?
Daniel [00:02:46] Sure. So like you said, I’m the Chief Product Officer at Waymo. For those of you who aren’t familiar with Waymo, we are a self-driving technology company with a mission to make it safe and easy for people and things to get where they’re going.
In terms of your question around the personal story, I think it’s a bit of a winding road that took me from where I started to where I am now. It all started more in terms of software engineering. I started as a software engineer across three different startups. I went that direction because I was actually torn in terms of where to go, but I felt like I needed to start technical if I wanted to go technical. After the three startups, I quickly realized two things. When I looked at the really senior engineers, that probably wasn’t the skillset and the things that I wanted to continue to exercise. And secondly, I really wanted more social impact in terms of the outcomes that I wanted to have. So I spent some time volunteering with some nonprofits.
An example would be a nonprofit called Benetech initiative. If anyone’s familiar with that, they do technology for social good. I volunteered with them briefly in terms of looking at human rights, violation monitoring, and technology that could help that. I felt like I needed to then go to grad school. I wanted to get more context on the business side and the social impact side. So I went to Harvard for an MBA and a Public policy degree. I spent a few years there, and I was really trying to explore that intersection of where I saw technology, social impact, and a sustainable business model coming together.
That said, when I graduated, it was in the midst of the financial crisis. So I decided I would hide out in technology for a year or so by figuring things out. What ended up happening is that I came to Google, and I fell in love with Product Management. I started on Google maps, worked a little on Google Hangouts as well. So over several years really fell in love with the craft of Product Management. But after a few years there, I really yearned for that social impact element. And when the opportunity came up at Waymo, it just felt like too good to pass up; I was finally at this intersection of the social impact of technology and a sustainable business model. So that’s, that’s kind of what brought me to Waymo.
Question [00:09:10] What do you think are the biggest misconceptions for people who are thinking about products but are not working there?
Daniel [00:09:20] So when I think of that misconceptions or myths, there are maybe two that come to mind. One actually goes to our shared story, Carlos. Which is around what’s the best way to become a PM. I would probably get this question a lot. I feel like I get this question a lot from people considering careers in Product Management, like, should I become an engineer first? Should I go to grad school first? And I would say that I think the fastest path to being a PM is to be a PM. I took a more roundabout way because, as we talked about, I didn’t know about Product Management; I wasn’t sure about Product Management. So I optimized for optionality. I think things like going more technical first gives or going to grad school gives you more optionality, but I think you really want to be a PM, and you’re sure about it, the best thing to do is be a PM.
Then I think the question is really around do you become more of a generalist PM? and you have a bit of a mix of different PM roles, whether it’s a consumer, enterprise, or more technical, or more user facing, or you want to specialize early? I think that’s one question that a lot of people wrestle with.
I think another one is around today, especially over the last few years, things like large scale experimentation, really refined toolsets for Product Managers, and I think it’s been really powerful for us. I think sometimes we forget about making sure that we exercise the full toolset as Product Managers. So, for instance, at Waymo, if you’re thinking about either kind of more moonshots or startups, I think you don’t have the luxury of billions of users right off the outset. And so for us, a lot of investment in user research, a lot of investment in incremental pilots. For instance, we have an early rider program that has allowed us to have that first touchpoint with public users. I think those are essential elements that we shouldn’t forget as Product Managers.
Question [00:18:59] How do you balance that influence you have as a Chief Growth Officer, with what you want to give to your product leaders to shape the company’s vision?
Daniel [00:19:10] I think this is a timely and challenging question. I do think that the role of the chief product officer, or product leader, is around setting the vision and the overall guard rails of the product that we want to build, and resolve conflicts; especially around priorities that come up. Your job as a Product Manager isn’t to decide every little feature, and every little nuance of the product.
Ideally, the roadmap is an outcome of great internal brainstorms across your product team, where you get the best answers. But I think the heart of the question is a really challenging one as a product leader. Understanding what’s the right level, where you have accountability for the full product, and giving your team autonomy. I think about it as a two-step program. I do admit that I don’t feel like I fully solved this. The first step is to develop at least the awareness to understand when you’re too high level or too detailed. You are never going to figure out the end game unless you get that sense. Whether it’s cues that you’re getting questions that you don’t remember, or you haven’t briefed on the rationale for it. That’s a signal that maybe you are too high level and you don’t have enough insight and ownership. Or you´re too detailed because you’re in the weeds on something or because you’re sensing frustration. I think that awareness, and then being able to adjust is a critical element.
Lastly, the second step is the ideal where you have a clear rubric for giving your team guidance: these things need to come to me, or these things don’t. I wouldn’t say I’m there yet, and I think that’s where you want to be so that it’s obvious through the organization what needs to come to you or what doesn’t. In my opinion, getting at least to the first step is critical as a Product leader.
We’ll be back next week with Shawna Wolverton from Zendesk with even more of the latest insights from the Product Management world.