Genevieve Sheehan, Director of Product Management at Dropbox

However, what we really came for, was to talk product with Genevieve. And that we did! In great depth, Genevieve gave us insights into the processes, tools and fundamental standards of product development at Dropbox.

A gallery of dozens of images in the hallways reminds us, that it’s Women’s History Month as we visit the Dropbox Office in San Francisco. When we bring that up in our conversation with Genevieve Sheehan, Director of Product Management at the popular global collaboration platform, she does express her concern that the roles of women and certain minorities in tech aren’t where she would like to see it. With that in mind, the story about a personal encounter with Sheryl Sandberg she is going to tell us, seems even more relevant.

A good product manager understands a product from multiple dimensions and can decompose problems in a way, that makes sense to the different stakeholders, says Genevieve Sheehan, Director of Product Management at Dropbox.

• Here is what you will learn in this interview:
• How the EPD-teams at Dropbox plan their sprint cycles and define their backlogs.
• What skills a good product manager needs to have.
• What a good team needs to do their best work.
• Why meeting with real customers is a huge motivator for teams.

Let’s hear your tech story first. How did you end up as a product person with Dropbox?

I heard the term product manager for the first time back in 2011. We had a group of people from Business School who went to visit Facebook. There, we got the chance to meet with Sheryl Sandberg. And her introduction, instead of an icebreaker, was: What would You do, if you worked at Facebook? I was the first person to talk, and I said: My name is Genevieve and if I came to Facebook, I would want to do something that made the product better and easier to use for the people who use it. But I’m not an engineer and not a designer, so I don’t know what that could be. She replied: We call that product management, and wrote “Product Manager” on the board. And that was the first time that I heard the term product manager.

From Sheryl Sandberg?

Yeah, Sheryl Sandberg told me I should be a product manager, and she was right. (laughs)

What was your next move after this unique experience?

Through a friend I got an introduction at the gaming company Zynga. From the moment I walked through the door there and looked at the office space, I knew that it felt really different from any kind of environment that I have worked in before. There was just energy. People were both very creative but also serious about their work. You could tell that they were moving fast and having fun at the same time. I just knew that was the place that I wanted to be, and I did a summer internship working on Farmville.

Within a couple of weeks, they let me build features and launched them into the game. I was just hooked on this product management cycle of being able to deeply understand how your product works, what customers might want, be a user yourself and then have ideas for what to put into the product to make it better and more engaging.

That makes it sound effortless. But, of course, you need specific skills and particular talents. What is, in your opinion, essential for being a good product manager?

There are a lot of different styles of product management and different flavours of product managers. I have always been exposed to business in the previous roles I had, thus I feel very comfortable working with data to draw conclusions. That’s something extra that I’ve been able to bring to the table. Other people may bring attention to user design or have a deeper technological understanding that helps them cut through.

However, one of the critical skills for product management, no matter what flavour, is being able to decompose problems. You have to understand what you are trying to do with the product in multiple dimensions. What could be good for the customer, for the product and for the business? And then you must be able to decompose these problems in ways that make sense to the various other counterparts you are working with, so that your work and your ideas also resonate with the problems that they are trying to solve.

When you say, there are different styles of PMs, would you say that there’s a certain type of PM here at Dropbox?

It’s fairly mixed up. Two skills run through basically all product managers at Dropbox. One is really caring about the customer and being focused on building an experience that meets the customers’ need. The other goes back to what I said about decomposing problems: That you have a structured approach and are clear about not just what you want to do but why.

There’s definitely a place at Dropbox for being very technical. We run our own data centres. We have a huge amount of infrastructure about how we keep all of your files safe in one place, so that the right people can access them. On top of that, we have all kinds of features, so that users can make the best out of that infrastructure. This is the area where people must be really interested in understanding those layers and then building off them to make the right features and how those features play into the business needs that we have.

Let’s understand your role here a little bit better. How is the product department at Dropbox structured?

We always think about EPDs, our Engineering, Product and Design departments. Within our product department, I’m one of the Product Directors. The product group that I manage is called the Cloud File System. We build, maintain and improve a number of the core functionalities around making Dropbox fast, keeping your files safe and accessible. In total, we have six product groups, the others being Premium, Ecosystem, Paper, Workspaces and Growth.

How many teams and people are in your product group?

I manage four teams. Each has about four people on them. I have an engineering and design counterpart at the Cloud File System level, and they have their own design team with individual designers and likewise in the engineering team. Together, they form 10 to 15 sub-teams.

A team typically consists of a product manager, a designer, an engineering manager and an engineering team. That could be anywhere from three or four up to sometimes 10 or 20 engineers working with that one product manager. We also have several other cross-functional colleagues from customer support, product analytics, design research or user experience writing who work with us.

What’s your mission when you operate with these teams?

The most important part is making sure that we are all working together towards Dropbox’s mission for our users, that Dropbox is at the centre of all of that collaboration, interaction and work that’s happening. It’s not just about files. We continue to invest in integrations and partnerships with any number of partners, work productivity apps, ways that people get their work done.

Another way I like to think about this is, if you join a new company, there is a ton of things that they do to get you up and running. I want the onboarding teams to say: “Just sign up to Dropbox. You’ll have access to everything you need, and you’ll be able to get started with your work right away.”

When you say that it is the vision to have all these tools you described to link into Dropbox, how does this actually look like?

A good example is Hello Sign. If you have a PDF that you need to get signed within Dropbox, it will show you a dropdown, and you can click on Hello Sign. It will take you right to Hello Sign, and then you can send it out, and when that person signs it, it will save back into Dropbox. Rather than having to download the PDF, go to a completely separate website, upload the PDF, send it out, have the person sign it, re-download it and upload it in the Dropbox, it’s one workflow that’s all done in Dropbox.

How do you convey this mission into operational items for your product teams?

We have surface areas or mandates that the product teams cover. That could be a platform or a system, or the feature that they are building, that goes across multiple platforms or systems. For example, one of the teams within the Cloud File System owns “Syncing”. They own the functionality, and they understand, how always having your stuff in sync works towards this mission of Dropbox, that is to help you get your work done.

How does your sprint planning work?

We have a standard of six-week sprints, but the teams can deviate from it both shorter and longer. Basically, you have two sprints per quarter. Depending on just the pace of iteration or how long-term the road maps are, teams either do their planning within those six weeks or break it down into two or three-week sprints within that.

This also defines collaboration among the teams. If you have a quick question, you can literally reach out at any moment to another team, but we look to line up through road maps and planning on those six-week sprint cycles. Besides, some of our teams, especially with more challenging or technical products, do have road maps for their product that go one to two years out.

How do the teams define their backlogs and how much freedom they have while doing that?

We aim for it to be bottom-up. Giving autonomy to teams and to individual product managers is a way to develop expertise, to keep them motivated and to get better ideas, but it ends up being a mix of bottom-up and top-down. We want to make sure that the investments and coordinated efforts across the different teams are all pieced together.

For example, when I joined Dropbox five years ago, and even looking back to before that, Dropbox had several different purposes, that it was able to serve. We were the place you could keep your files safe. We also had some forays into photos. But we found that the value we are giving to users is really more in getting their work done and in productivity. So, from bottom-up, we might have seen value in photos, but from the top, we determined that this is not where it is going. And from then on, we make sure everyone is moving in the same direction.

Do you set specific goals for your teams, or do they set their own goals?

We do both. We’ll have a couple of high-level company goals that set the general direction. But I want my teams to come up with their own goals. We are explicit with the teams that we expect them to have a goal in mind or, if they have multiple goals, that they are clear on why they are doing multiple things.

Every product manager and every team should be able to tell you what they are working on and why.

They should also have an idea of how to measure success. Is it more about getting more customer interaction, is it about having a more stable platform or is it about having something that people are willing to pay for? In an ideal world, there will always be a way that you could measure this one specific goal, and everything else follows. Sometimes, we aim specifically for performance or sync speed. In practice, that type of precision just isn’t always possible. Especially at earlier stages, just getting a feature up and running or having a number of customers go through a pilot or alpha program can be the next set of goals.

How do you involve yourself in the product development process?

My goal is to enable my teams as much as possible. That’s the way I get better at things, that’s the way my teams get better, in addition to getting to the best product. When you have decisions made by local experts, it enables the most learning. I don’t think about this as a series of meetings, although we do have a regular cadence. But it’s less optimizing for meetings and more optimizing for doing the right thing.

I also spend a lot of time with my engineering and design counterparts. One common roadblock is, when two teams are working towards something with a similar goal and they need help prioritizing between those two things. We won’t necessarily have a huddle every single time we’re making that choice. But we always work to be on the same page about that, so that my counterparts give the same guidance that I would or know what my stance is.

A lot of your work is people management and managing teams. How do you set up your teams, so that you are confident, that these people will function as a group?

There are two hallmarks of a well-oiled team. The first thing is that good teams talk a lot. That can mean that they speak to each other in person or they engage on platforms like Slack. When stuff like meetings goes smoothly, you can tell that a team enjoys spending time together and getting their job done, as opposed to a team, where things are more in silos, and they are waiting for a handoff from someone else. My colleagues and I use regular check-ins to take the pulse of the team and then make sure we can correct course together. These meetings are open-ended and happen outside of just setting OKRs and then affirming KRs.

The second hallmark of a good team is that they have a common purpose. If a team is always fighting about which way it should go or what task is more important, they are not going to get a lot done.

A good team understands what they are capable of and rallies around a common goal.

You go from “We just maintained the surface” to “Hey, we are building this set of features to make this experience better for our users”. That really pulls teams together and makes them feel like the work they are doing is really important.

How do you make it visible to the product team, that their work has really an impact on your customers?

There is a ton of different ways to do it. If I had one choice, the most useful thing is spending one hour with the customer. We do something that we call “Real World Wednesdays”, where we bring in just ordinary people, some of whom are Dropbox users, some of whom aren’t. We show them stuff that’s in development or something that we are thinking about and get their reaction. We want to understand not only how they would use a certain element, but how do they get their work done or how do they spend their day.

Another thing I did with a set of colleagues was a project, where we basically drove around and just embedded with users or prospective users. We got a whole new sense of not just how they are using the product, but actually what are they trying to achieve by using it.

What are the reactions of your teams when they talk with customers?

Usually, it’s positive affirmation. We’re hands deep in the product, so we tend to be very self-critical. It’s really gratifying to see that a customer or user is delighted by a feature, and that it exactly meets his or her needs.

We did an early test of a feature a couple of weeks ago, and one of the customers who used it said: Wow, that was so amazing, I’m going to be a paying customer for Dropbox for life, now that you did that for me. In these moments, we are going beyond just having a functional interaction with a customer. We realize that we are doing something that makes them feel an affinity for our product and four our work.

Sometimes it’s more valuable if one person is telling you “I am a paying customer” then seeing a chart that says: We have  added 10,000 paying customers.

Different people are motivated by different things. Some people want to see the chart that’s up into the right. Some people want to look into the user’s eyes. We found time after time that spending time with customers or even with the support or sales teams, who spend the most time with customers, is a huge motivator. Not just for the product person but actually for the whole team. It helps everybody to get their work done better.

Genevieve, thank you so much for having this conversation with us.

Dropbox supported this article with some of their own images.