A Conversation with Brian Rakowski, Google’s first Associate Product Manager
Photo Credit: Alberto Cereser
Shortly after meeting Ariel (see previous post), I had the opportunity to sit down with Brian Rakowski, Google’s Vice President of Product Management on the Chrome team and the company’s very first Associate Product Manager. Brian shared with me his stories and thoughts on product management, and offered some great advice for new graduates interested in the tech industry.
- Yi Han
Brian graduated from Stanford University with degrees in symbolic systems and psychology in 2002. That same year, Google launched the Associate Product Manager (APM) program in an effort to cultivate young product managers who can lead effectively in Google’s unique management culture.
Brian became the first recruit, and was immediately put in charge of launching Google’s new email product, which became known to the world as Gmail. After Gmail’s successful launch in 2004, Brian spent time at the Zurich office and on the client software team before becoming involved in Chrome. Brian currently heads up the product side of Chrome, and has overseen each step of the process as Chrome grew rapidly in the past few years to become what is now, by some accounts, the world’s most widely used browser.
Brian is recognized as an enthusiastic, technical, personable and witty executive. When not giving demos or bouncing ideas around with colleagues, he can be found brewing celebration beer in anticipation of Chrome’s upcoming milestones.
Can you tell us a little bit about your first day as Google’s first APM?
I showed up on my first day, and the first thing after going through orientation, I went to meet with Marissa Mayer who was my mentor. We were in this small conference room outside her office called Ping pong 2, as the conference table was a ping pong table, and there she started talking about what I was going to work on.
I expected her to say something about search but she started talking about email. She explained that there was a very early stage email product with only a couple of engineers. I was kind of speechless because I had no idea that Google had such a project and that they would let someone coming right out of school work on it.
Nevertheless by the end of the meeting Marissa told me where to go. I quickly realized that instead of desks there were only doors on sawhorses which were cheaper. When I arrived at my work area one of the engineers kindly moved his workstation towards the middle of the sawhorse and I got the end of the door on the sawhorse to work on. So I sat there with my laptop, started reading design docs to try and figure out what was going on, talked with the engineers and started to do competitive analysis of what the other email products were doing.
We talked a lot about the lean startup movement on the Harvard Innovation Lab’s January immersion tour earlier this year. Chrome was launched in 2008, the same year Eric Ries started the movement. Has Ries’ philosophy had an impact on Chrome’s growth?
The lean startup movement never seemed foreign to us even from the beginning because that’s very much the way Google’s has always been run - starting small and growing from there.
Within Google, there are two concepts that Larry and Sergey emphasize. The first is about thinking big and planning for our products to reach millions and millions of users. It is the concept that a project is not worth taking on if it’s not going to work at scale. As an example, Larry and Sergey planned and designed Google search to be able to service millions of queries a day even from the very beginning. On the other hand, the founders have always pushed us to be as scrappy as possible and not be wasteful in hiring or building infrastructure to support a future reality that’s hypothetical. When you combine these two concepts, we’re encouraged to plan for the best and anticipate the best but not get ahead of ourselves in terms of putting stuff in place that we don’t yet need, and so the lean startup concept makes sense.
With Chrome, we intentionally constrained the number of engineers working on the project until we knew where we were going and had strong signals that people liked our product. In the early days, to get these kind of signals, we had Googlers use Chrome on a small scale. These initial tests worked really well for us and we definitely threw a lot of things away and avoided going down many dead ends.
Chrome is now a mature product. How does your team balance between the need to maintain the browser’s excellent reputation and the necessity to move forward quickly and take risks?
I think we’ve established an infrastructure that works well for rapid iterations. We’ve got six week release cycles with dev, beta and stable channels. We can be relatively adventurous on the dev channel because there is a new one every week. If something doesn’t work out we pull it back. We also develop a lot of features behind configuration flags so you can have features developed over multiple six week cycles.
Building this infrastructure was really important to us. In fact, the first thing we built for Chrome was the auto-updater. This is because we wanted the team to get into the web mentality of development where you can just push instead of waiting for people to find out there is a new version and download it.
To ensure the quality and speed of the browser we put a lot of automated tests in for performance and so with every change that gets checked in we can see if it makes Chrome slower. If it does we’ll pull it back out, implement it another way and try again until it works right and doesn’t slow anything down. This helps us avoid the problem of software getting bloated and slow over time.
The release cycles, the channels and the testing infrastructure we’ve put in place have helped us stay pretty fast despite the popularity of the product.
Tell us about your team’s culture. How did beer brewing become part of the Chrome team culture?
The Chrome team is slightly amorphous in the way it’s organized. The team started with a bunch of people who didn’t want to specialize too much, and this unique beginning helped shape the team’s organization today. Rather than having very regimented subteams, we have people who are very versatile and like to move around the entire code base. As it turns out, people who are versatile are very valuable to large software projects because significant changes require an understanding of several different components of a project.
The tradition of brewing Chrome release beer started from one of our release managers. At some point he learned that it takes about six weeks to brew a batch of beer from start to finish. At that time, he was working on Chrome’s six week release cycle, and had the brilliant idea that we would start batches of beer the same time we start a new release of Chrome, and then drink the beer to celebrate at the end of the six week cycle. Shortly after, we got started with the help of an avid home brewer on the kitchen staff, who located some leftover equipment from one of the cafes. Now basically every six weeks we have something new to try. Sometimes it works out while other times it doesn’t. It turns out we’re better at software development than beer brewing.
Has there been a piece of advice someone has given you that you’ll always remember?
One of the things that I learned early and that’s been helpful overall is that you have to do things in the way that makes sense for you. You shouldn’t emulate someone else’s style. Everyone has their own strengths and weaknesses and it’s better to focus on your strengths and get other people to help you with areas in which you’re weak than to completely focus on your areas of weakness and make those better, because then you end up spending all of your time on things you’re not so good at. I find it helpful to not stress about the things you’re not good at and recognize that very few people are good at everything.
What are some things specific to technology careers that new graduates looking to enter into this industry should be aware of?
In the software industry many people stress a lot about where to work and what to work on. For example, they struggle with the question of whether to work for a startup or a larger tech company. I think the most important consideration is to find people you enjoy working with and learning from. Everything else mostly falls in place.
For me, people I enjoy working with are those who I think are really smart, who I can trust and rely on, and from whom I can learn a lot. To me, finding great people, rather than picking the perfect industry or perfect products to work on, has been the most helpful thing in my career.
When you’re working alongside great people you tend to find the right things to do.
What is unique about the product management role at Google?
We tend to hire very technical product managers at Google, people who would be quite happy and quite successful as software engineers, but may want to focus on product more. At Google we believe it’s really important for product managers to have a strong technical foundation. We expect our product managers to work with the engineers and push the envelope of what one can and cannot do from a technical perspective. Thus, it’s necessary that product managers have an understanding of what is possible, what is not possible, and what might be possible if one were to push. If I could have done anything differently in school I would’ve taken even more computer science courses. On a related note, I found it helpful that I took several human-computer interaction classes while in college. I found the concepts to be very applicable when I first started and I still draw on that knowledge today.
