Ketan Nayak sat down with us to share his story so far: coming from India to MIT then finding his way to his current role as a Product Manager at Dropbox.

We cover:

  • which tools are in Ketan’s PM-hacking arsenal
  • what’s the difference between product and project management
  • how being a PM is different depending on what the business is selling

For the full text transcript see below the fold:

Audio:

Play in new window || Download

Video:

Max: Welcome guys–the Accidental Engineer here, we’re joined today by Ketan Nayak.

Ketan is a product manager at Dropbox in San Francisco California, USA. Ketan has a really impressive background, having done a master’s back in India and a masters at MIT.

He then joined a technology company on the East Coast called APT which was acquired by MasterCard, after which Ketan found his way to the West Coast where he is now at Dropbox.

For our audience that might not know what products you manage at Dropbox do you mind sharing about what your team does and what you do?

Ketan: Yes, sure. I’m a part of the product team at Dropbox and the product team is split into various pillars. One of the pillars, that I work under, is the Growth and Monetization pillar, and specifically within Growth and Monetization I work on analytics and data infrastructure and particularly within analytics and data infra, I do a couple of different things.

First of all the purview of analytics and data “infra” is to manage all of the analytics stacks at Dropbox and making sure that the Dropbox service is as a whole and managing data to make better decisions.

But more importantly what I’ve been recently focusing on is how to use experimentation to drive Dropbox’s growth.

Max: Nice. I forgot to mention in introducing you how the two of us met!

Ketan: Yes. It’s a good story.

Max: I’ll be brief and feel free to butt in with details, but I think our audience will be entertained knowing that we actually met in Boston where we were both…you were still in your master’s program?

Ketan: That’s right.

Max: I was working for a tech company there. And you and me and a third friend of ours participated or met at a Kaggle competition. So for our audience that doesn’t know what Kaggle is, do you mind explaining?

Ketan: Yes. So for those who don’t know what Kaggle is, it is this website that brings together a community of data scientist and matches them with a set of different data problems that companies or organizations want them to tackle, and as a part of that Kaggle hosts a bunch of different competitions in different cities to make this more of a community, a meet up where people get to know each other and work on interesting problems.

And Max and I we worked on…I believe it was a Walmart data set and we were asked to predict the sales of certain Walmart products.

Max: I remember it turned out…we did not get the first place. But we did place pretty well.

Ketan: Yes, I think we placed 3rd or something like that. I have a certificate.

Max: Nice. I remember we actually got a cash prize and spent it all on sushi.

Ketan: I think so. Yes.

Max: But I’m guessing you might not use all the same toolkit that you do at your current job that we used when we were solving that Kaggle problem.

Ketan: No. Not at all.

Max: For people who are curious about the role of the product manager and what your toolkit looks like, especially on analytics products, do you mind sharing for people what kinds of software you use on a regular basis as a product manager?

Ketan: In terms of the software I use, I think that’s typically mostly writing email or writing documents.

I don’t use the R or the Python that we were using in Kaggle. But as a product manager, the toolkits that I apply are mostly in talking to different stakeholders-—bringing them together and agreeing upon a unified vision of a product.

I will say that a product manager’s role is to shape the right thing to the right people at the right time. And to do so there needs to be information that has to be aggregated from different parts, a collective vision of what the product has to be, needs to be built and then the people who are working on it–the engineers and the designers–should know what this vision of what we are driving towards is, and then you manage the release of that product.

So there’s a various aspect of information gathering, negotiation, maybe some data analysis like stakeholder negotiation and things like that that are probably more important. Software tools? I use Gmail a lot.

Max: For engineers, one of the most critical aspects of product or project management–which we will discuss the difference between in a little bit–is estimation.

You mentioned stakeholders–what does the estimation process look like to a product manager, looking into an engineering team?

Ketan: Yes, when you talk about estimation there’s always a tension between product managers and engineers.

Engineers want more time, product managers want less time. Because people as a PM, what I care about is shipping things faster, sooner so that users are happier and we make an impact. Whereas engineers care more about code quality, making things robust, having a better data model, thinking through problems in depth. And that’s where the tension comes in.

Engineers want more time, product managers want less time.

Basically what engineers tend to do is they give estimates by looking at a project and making a mental map of “here are the steps that I need to do to successfully build a product.” But there’s a lot more involved in taking a built part and releasing it. It involves things like shipping, things like release communication, QAing and all of that. So what I do as a rule of thumb is I take my engineer’s estimate and double it, and then use that as my true estimate.

And the reason is:

  1. things always get delayed, and
  2. I always want to under-promise and over-deliver when it comes to users or people that I am delivering and giving a promise to.

Max: For sure. On that note of working with stakeholders and estimation, for our audience that doesn’t know about this topic–myself included-—what exactly is the distinction between product and project management?

Ketan: Yeah. That’s a very interesting topic, and a lot of people confuse product management and project management.

Here’s the way I think about it: product management is a very…the way the role has been defined more recently is very much driven from the software tech industry perspective…a lot of people say the product manager is the “CEO of the product.” I tend to view it a little bit differently, but the idea is you’re taking a product from inception. You’re thinking about your users, getting use cases, figuring out creative ways to solve problems that users face and you’re figuring out a technical solution with engineers, designing it, building it, shipping it, and releasing it.

In some sense, you are the primary stakeholder for a product or a set of features that comprise a product in its entire life cycle.

Project management, in my opinion, is more broadly applicable. You’ll have project managers in the oil industry, you’ve got project managers in medical administrative fields and so on. And typically the scope of the role can vary a lot depending on the size of the organization or the size of the project.

But what it encompasses is very small parts of a very large project, so things like operations, delivery, making sure deliverables are on time. So making Gantt charts and following up with people.

It’s a little different in the sense that you’re not delivering something but you’re managing something, or you’re making sure something is happening on time, and there is efficiency and effectiveness. But as a product manager you are building a product that is delivered to end users.

Max: This might be a little subjective, but is product management a more prestigious role in an organization than a project manager? Very generally?

Ketan: I would like to think so. This is generally because even by the sheer number of roles that are available, product manager or product management roles are far fewer in industry than project management.

Max: You are distinguishing how a project manager’s role is kind of a subset of the role that product manager plays.

Ketan: I don’t want to call it necessarily a subset, I would just say it intersects. But it intersects in one specific area and there could be things that a project manager does that the product manager doesn’t necessarily do. And a product manager sometimes is pretty much high level doesn’t work in the weeds–depending again on the size of the company that you work on. If you work in a startup, you always end up doing everything, but that’s probably a fair way to characterize things.

Max: For our audience that might be starting their careers, are in their first job, or maybe thinking about transitioning to product management from more or less technical role: how did you find your first role out of grad school?

Ketan: Yeah, that’s a really really good question.

I actually ended up getting into product management partly by accident, and the reason is that when I was graduating from grad school and MIT, I really didn’t know what I wanted to do and typically the people that don’t know exactly what they want to do, try out consulting because you’re smart and you help people solve problems and you get paid for it. I was interviewing for a bunch of consulting roles and turns out the company that I actually ended up at had a consulting role open, where I ended up was at ATP.

I applied for the consulting role, and as I was going through the interview process the folks at the company told me, “Hey there is a product manager role. This seems like a better fit for you, why don’t you try out?”

I learned more about the role and it seemed super interesting and really what I wanted to do. So I ended up taking it, and I pushed through with it.

So for most people who want to get into product management, there are generally two ways to get into it. Especially if you’re graduating or just graduated.

The path number one is kind of what I did which is get into a PM role straight out of school, and this is usually with an APM program which are becoming more popular now. Google has the famed, Associate Product Manager Program. Dropbox now has a new Grad Product Manager Program. A lot of companies are coming up with these new university grad project management roles.

But what is more common is people transitioning into product management roles from another technical or non-technical role in the company.

And you asked me the question on how does one transition from roles as well?

So if you’re an engineer, typically what you really do well is you understand the code side of things, you know what the code base is like, you know what the product value proposition is.

What you know less about is how the product is sold. Once the product is built, that latter half is harder to know as an engineer than the earlier bit. Like what are users telling…what is the use of perception? What do users want?

I’ve seen that senior engineers, as they ramp up on a product, get more information on either side. But the people who want to become product managers, actively seek out to learn that earlier phase and the latter phase and this turns out like learning more about customer experience. “What kind of tickets people are filing?” “How does that devolve into like a persona of the user and the problems?” And the latter phase: “how do products get built and shipped?” and so on.

For the non-technical role, it’s about covering the gaps. They would have to understand “how does the product work?” Get a little more technical understanding. That’s how people transitioning go beyond the boundaries of their current role, and this happens organically with people doing more projects that they’re interested in. Once they start doing it, especially at growing companies, they’re always having product managers, and typically companies look to hire product managers internally. It’s because it’s easier for them to slot them and perform quickly. That’s probably my best advice for people getting into PM.

Max: So for people who are not internal transfers into PM, a lot of people reference job descriptions as their sources of truth about what it is that employers are looking for.

Being on the other side of the table interviewing candidates or even reviewing resumes of candidates: what are the pieces of job descriptions that you’ve seen for product managers that are the most important to look for? What are the most truthful?

Ketan: That is very interesting because it’s hard to pin down exactly what a product manager does at times.

The reason is a product manager, in my opinion, has to do whatever is necessary to ensure a successful product. At times that might be doing anything from moving tables, depending on the size of the company. But there are a few things that I’ve seen come up in product manager roles:

One is being technical or have a very strong demonstrated technical interest especially if you are in school and pursuing a not-technical degree.

Max: Could that mean learning a programming language?

Ketan: It could be learning a programming language, it could be…even if you learn a programming language…if I’m recruiting which I am, for Dropbox, one thing that I may look at is a demonstrated interest that shows more of an application of that knowledge.

What I want to know is not whether you took a Python class, but after having taken that class, what did you build? Did you build an app? You built something that tries to solve a problem?

And how you built that is also very important for me because I want you to know whether you went to the user. Did you talk to them? How did you figure out what exactly to focus on and things like that?

So that is number one: the ability or a demonstrated interest in working on technical problems.

Number two is that I like to see some type of drive and self-motivation or leadership skills. And the reason I say this is that a product manager–the role is very nebulous, it’s not very well defined, and at times you don’t have very distinct leadership or someone saying, “Here is where you should go.”

In fact, the engineers on your team will be looking at you and saying, “What direction should we go,” and you are the one to point that direction.

A lot of that can be learned but I feel that product managers who have taken leadership roles have done things outside of their class work. People who start companies for instance set really good stepping stones for people to learn what it is like to be in the shoes of product manager without having to have that job title.

Finally, a couple of things I really like to look for is: are they data driven? Do they have some sensibility of design? Do they have some sort of product intuition?

And all these can again be built by looking at products, keeping what I call “soft eyes.” You look at products and say okay how can I make that better? How can I solve certain problems better? Building that sort of personality or world view will help people.

Max: On the topic of being data driven and being quality look foreign candidates, we recently interviewed Craig Kerstiens of Citus Data—they’re a database hosting provider where he’s a product manager. He was discussing the topic with us about the value of knowing SQL [as a PM].

Are you using SQL on a day-to-day basis? Is it something that is required criteria of PM candidates or is it something that is a less frequently used skill on your team at Dropbox.?

Ketan: Yes. I use SQL a lot and partly because I work with data a lot, and I like using data to drive decisions.

A lot of that means that I dig deeper into data on how people are using my product. What kind of trends exist? If you’re working with data or any aspect related to data, SQL is a must-have skill these days.

And for those who are viewing this, I would say that if you don’t know SQL but are looking to become an engineer or a product manager or getting into any sort of technical aspect of a business, even non-technical roles such as marketing. They definitely need SQL, it’s a super easy language to learn, tons of value.

If I look at a resume which says SQL on it, it just makes me that much more comfortable to know that, “Okay this person can slot into the role better.”

But that means that the product manager role is interesting because some people in PM tend to be very very high-level and business-oriented and at that point the role is purely strategy driven. So they may not necessarily work with SQL as much as I do.

Typically what I see in a PM is that people fall in a spectrum. I have a PM who reads through the code base. I’m not one of them, but there are people who are ex-engineers who read the code base. Then there are PM’s who are very business-focused who might not write SQL, but I think like the vast majority, a majority of this spectrum that I spoke of definitely knows SQL.

Max: In your time at APT, and then MasterCard after the acquisition, and now at Dropbox: how much of your PM roles have required interfacing with sales and marketing?

Ketan: That’s a really good question. The role that I played at APT and MasterCard was an enterprise product manager.

I was building products for other enterprises, and that’s a role where there is a lot of interface with sales and marketing because when you work in a B2B company the way you sell products is via direct sales. The companies are trying out products on their own, but typically you have a sales force that goes out and reaches out to a company and then that’s how they build the product. Sales and marketing function is very crucial in enterprise businesses.

So at APT I worked a lot with sales and marketing and the way I interfaced with them was either through sales calls, sitting in and being the product expert: explaining the features or the nature of the project and marketing was primarily to build white papers and case studies on how the product can solve certain business problems that enterprises were looking to solve. At Dropbox, I do a little bit less of that partly because I work on internal products now and there is no sales and marketing because I’m selling to other Dropboxes and helping them use the tools that I built.

Max: In contrast to working with engineers, I can imagine how different it is to work with sales and marketing. I know how sales is a quota-driven, performance-driven, compensation field.

What kinds of different behavior do you see as a PM working and collaborating with sales marketing versus collaborating with engineering?

Ketan: That’s a really good question. And I think it’s all about perspective, because you can look at a product from multiple lenses, you can look at a product from a technical lens. And when I’m talking with my engineers it’s talking about the data model, it’s talking about making technical trade-offs to meet certain deadlines and use cases and so on.

I personally look at it as taking a technical lens on the product. But when I go to sales and marketing, it’s about value proposition demonstrations. It’s about taking a product and saying, “How can I demonstrate this value to someone who might be interested in purchasing this product aka the prospect?”

A lot of that then focuses on putting a business or value lens, and thinking, “okay, we’ve built X, Y, and Z. Can I…” which may be really technical or very in-depth features but how can I put this or present this in a way such that someone who’s a decision maker on the other side perceives this as valuable?

There is a lot of translation of a highly technical product into something that is more possible and consumable by someone who’s a decision maker who might not know everything about the product that you’re looking to sell.

Max: So it’s sales and marketing where you’re acting as a translator of technical concepts or…?

Ketan: Translator is a reasonable way to phrase it, but it’s not a direct translation. It’s about phrasing it differently. It’s about looking at it from a different angle. Case in point is let’s say built feature X that has a very flexible data model that does X, Y and Z where one or two things coming out of that flexibility on the engineering side that might be super interesting for the business user and maybe they can now view data in like different dimensions. Do some certain types of analysis that would help them make well, right, and so it’s about stating the value of what you’ve decided on the engineering side and how that impacts end users.

Max: One of the topics that we talked about before recording was about the lifestyle change–maybe not lifestyle–but role change you encountered in working at APT through the acquisition of ATP by MasterCard.

For our audience that’s curious about what life is like through working at a tech company as it gets acquired and what ultimately led to your decision to join Dropbox—do you mind sharing that background?

Ketan: Yes sure. I was working at APT, Applied Predictive Technologies after graduating school, and this was about maybe 1.5-2 years in when ATP was acquired by MasterCard. I didn’t really know what to expect from the acquisition, and I’ve heard different stories of people’s perceptions of what happens after an acquisition may be very different, but this is my story.

Interestingly there are a few things that change and a few things that didn’t change. One of the things that didn’t change which I really thought was great was the culture of the company and how the company operated well and I really liked that. APT and especially senior management at ATP went the distance to make sure that even though there was an acquisition the company operated–from a cultural perspective–relatively independent and it still felt as if we were working in the similar organization and there wasn’t a huge influx of changes that came right away from a culture standpoint.

That was really nice to have because from an employee standpoint—from my perspective–it meant that I was so comfortable working with my teams, there was no massive disruption.

From the product side where I worked, there were a few interesting things because of MasterCard’s capabilities and what APT did. APT built analytic software, so there were interesting product opportunities that we could pursue as a result of the acquisition.

Max: I realize that we can’t get specific about these things. Do you mind sharing what ultimately led you to decide to move out to the San Francisco and Dropbox?

Ketan: Yes so I think my decision to move out was less related to the acquisition and more related to how much time I had spent in the company and how much I was learning and doing things.

I’d spent three years at the company, and I say this jokingly: at times your learning curve starts tapering at the two and a half, three-year mark. A lot of my job became very predictable in the sense that I’d be’ working on a project, it was interesting, there was nothing wrong about it. But I knew exactly what steps I would take, who I would talk to, how I would execute on it, and what all I could get out of it.

All of that process had become so predictable because I had done so much of it over and over again that it felt like I am just executing at this point and not really learning as a part of executing.

So for me, the personal decision was, “Hey, I should move somewhere else to learn something interesting.” I learned a lot. Three years of a product manager or any technical role you end up learning a lot.

I learned a lot but learning new and interesting things in the new environment, moving to the Bay Area, building a network here are things that I considered or weighed more heavily.

Max: What are the big contrasts? You mentioned wanting to reset your learning curve so you can learn more faster.

What are the contrasts from your experience now at Dropbox versus at MasterCard?

Ketan: Yes, I bucket these into three buckets. There’s a company aspect, and within the company aspect, I say there’s a macro and a micro, and there’s a non-company aspect. It’s how PMs talk, we are very structured.

From the non-company aspect, it’s all about what you do outside of work. So the Bay Area has a huge network, everyone’s in tech, you always meet with interesting people doing interesting things in tech. If you want to learn more about tech, just go to a meetup or Facebook events, you will start diving deeper.

Contrary to that, in DC, where the tech community is much narrower, it’s very hard to find opportunities to grow your network in tech. However, because there are very few companies, the network is smaller, you grow tighter or closer to the people.

Here, you meet a lot of people but the bonds are more fleeting and the interactions are more fleeting. In DC, I felt that the bonds were tighter, but it was a smaller, closer community.

Coming to the company aspect, if you talk about the micro, it’s how companies operate–what tools you use are different, what cadence you do things, how you plan, how you strategize–all of that was different.

From a macro perspective, the biggest change for me was the size of the company. APT had a team of 100 engineers, and we were 8 product managers. Dropbox has 70 product managers and multiple hundreds of engineers, probably closer to a thousand.

That transition was huge for me because operating in a larger company is way different than operating in a small company—internal communication, just making things work. Aligning with stakeholders, a lot of that dynamically is very different.

Max: It’s interesting that between both companies there’s about a 1:10 ratio of PMs to engineers. Any theories on why that is? Do MasterCard and Dropbox have similar processes?

Ketan: Not really, I think it varies a lot. Typically it also depends on how big the size of infrastructure teams are. Typically infrastructure teams don’t need product managers, or they need few product managers, so the ratio tends to be few product managers to a large number of engineers.

If you’re working on front-end facing products, then that means that you have more products managers and designers relative to number of engineers. Their ratio varies a lot from 1:5 to 1:10 as you’ve been talking about. I think it’s pure coincidence.

Max: Got it. For people who are job seeking, one of the thing s I’d love to have you do is plug any roles that your team’s hiring for?

Ketan: Yes. This would be a great opportunity. I’m actually the staff member on the Dropbox’s new Grad Product Manager Program which means that I manage the recruiting process, the on boarding process and the project matching process for the new grad project manager program.

Max: Awesome, so people who are finishing their bachelor’s or BS?

Ketan: Yes, so anyone who is finishing their bachelor’s or master’s or even anyone who may be working but has less than a year of work experience. When you start as a new grad product manager, we want you to have less than a year work experience. You’d be eligible for this program. We are actually actively recruiting right now and as I said earlier if you are looking to get into product management, one of these programs is really great to get into and I’m not just saying that because you get in a Dropbox and Dropbox has a really great product team but right from the outside you’re put into this world where there is a very solid system of mentors, managers, coaches, peers that really help you gain or fill the gaps in areas where you might not have the skills.

So it’s a very structured way of learning product management, I was a new grad product manager, I’ve been through one of these programs at ATP. I felt that it helped me a lot personally. So anyone who’s looking to get into PM, look out for a Dropbox’s new grad product manager role and we’re looking to actively hire. It would be great to have you apply.

Max: Will absolutely drop the link in the show notes, take a look at those. Ketan this has been freaking awesome. Thanks for joining us!

Ketan: Thank you so much, Max.