Machine Learning Zoomcamp: Free ML Engineering course. Register here!

DataTalks.Club

Articles Slack Events Podcast Books Courses

Becoming a Data Product Manager

Season 6, episode 4 of the DataTalks.Club podcast with Sara Menefee

Links:

Did you like this episode? Check other episodes of the podcast, and register for new events.

Transcript

The transcripts are edited for clarity, sometimes with AI. If you notice any incorrect information, let us know.

Alexey: This week, we will talk about a data product manager. We have a special guest today, Sara. Sara is a product manager at Meroxa, which is a company that builds data platforms that help software teams orchestrate and integrate data into their data-driven applications. Previously, Sara worked as a product designer for companies including Sora, Checkr, Change.org and Zendesk. Welcome, Sara. (55.0)

Sara: Thank you. (1:25)

Sara’s background

Alexey: Before we go into our main topic of “Becoming a Data Product Manager”, let's start with your background. Can you tell us about your career journey so far? (1:27)

Sara: Yeah. Where do I even begin? I guess I can start with – I made a lot of transitions in my career, but one thing I've always known is that I wanted to work in technology. For me, the entry point was actually a technical support role at a large shared hosting company. After a handful of years in that role, I felt pretty stuck. That company was based in Utah, and while there is quite a bit of opportunity there in technology, there wasn't as much as I had hoped for. There wasn't a variety of companies where I could say, “Hey, I can work for this company and learn something new.” A good friend that I was working with at the company actually convinced me to move to San Francisco and said, “Hey! If you want opportunity, San Francisco is the place to be. I'm moving out there.” He had just received an offer to work at a cloud computing company and he was like, “Come out with me and we'll figure it out together.” So I did the unthinkable and it was literally a decision that I made within two weeks. I packed up all my stuff and we literally drove out in the middle of a winter storm and moved to San Francisco. (1:37)

Sara: When I arrived in San Francisco, I didn't have anything lined up. But I was comfortable with that. Through the generosity of friends and connections, I was able to pick up a few technical gigs here and there. I'm going to fast forward a bit to when I eventually landed a product support role at a company called Zendesk. That's where my career actually made the biggest shift. At the time, I had already been working with a lot of companies that use Zendesk for their helpdesk and helping them curate their helpdesk experiences, so they can help their customers. So it was working a lot around helping them design experiences that could then ultimately result in “Oh! Customers know where to go in order to get this information or this information.” We helped them brand that experience and make it a bit more familiar. (1:37)

Sara: I ended up reaching out to the chief creative officer at the time. I was actually trying to refer a friend for a design position. But I had mentioned to him that I had a passion for design and technology. I showed him just a few of the projects that I had worked on. Fast forward and I was suddenly in a room interviewing for a product design role. And I got it. This was a huge opportunity and I just feel so lucky. From there, my career grew. I went on to work for a B2C company called Change.org – who are one of the world's largest online petitioning platforms. Then I went to work for a company called Checkr, which is a background check API company. Then I worked for a couple early stage companies. So Sora, which is an HR data platform and then I arrived here, at Meroxa. (1:37)

Product designer’s responsibilities

Alexey: That's quite a journey. So, as a designer, what kind of things did you do? When I hear “designer” I imagine somebody who designs furniture or tells you what your apartment should look like. I imagine that you were a different kind of designer, right? What kind of things did you need to take care of? How are the elements arranged on the website and things like that? (4:58)

Sara: Yeah. I love interior design and all of that, but the type of design I was doing was product design. A lot of that was taking product requirements and building user experiences through interface design. That involves quite a bit of user research, user testing, figuring out how customers expected to interact with our technology, the outcomes they were expecting, iterating a billion times, and trying to figure out what it was that helped their customers along. (5:23)

Alexey: So do you have to be good at design? Do you have to have a good taste to be a product designer? (6:05)

Sara: I think you have to have a foundational understanding of technology – you need to really care about customers (the people that you're serving.) I feel like the more visual aspects that come in – that play a part in product design – all of that can be learned. Depending on the size of the company, you can usually get away with using an existing design system or component library. You don't have to worry too much about things like, “Oh, well, what color should this button be? What kind of display should I use for this?” So, I would say, yes – you should have an eye for design. But it really comes down to this: the best designers I've always known are the ones whose interests are deeply rooted in solving problems for their customers. (6:14)

Data product manager’s responsibilities

Alexey: What do you do now, as a data product manager? (7:04)

Sara: That's a great question. I actually work pretty similarly to how a regular product manager would work. I guess the only difference here is that I'm working on data products and not just feature products – or what people traditionally think of as feature products. I do a lot of similar work around spending time on understanding customers. For me, as a PM working on data products, that means talking with and interacting with data professionals any chance I get. The goal behind that is to understand things like “What are the core responsibilities? What are the problems that you're aiming to solve? What challenges do you run up against? How do you get around them?” (7:09)

Sara: For a lot of my conversations, they often go towards more tactical aspects of how they take requirements from all over the business and turn it into actionable data. When I say actionable data, I mean data that's driving their applications or infrastructure, or in some cases used in data analysis. From there, I take a lot of my learnings from those conversations, or any other information I might have, and start developing an understanding of the problem that we're trying to solve and how we might do that, and help them accomplish that. The thing I found specifically with data teams, is that not everything I learn necessarily points to an obvious answer. I find that, depending on the type of company, the type of requirements that they lay in front of their data team – that really determines how that team operates and what the organizational motions are for that team. Are they just building pipelines for data analysis? Or are they powering their applications with real-time data? And why is that? (7:09)

Sara: From there, I basically take all that information and occasionally reach for some of the tools that they're using in order to figure out “Okay, what's not working here? What are some of the pitfalls of the technologies and tooling that they're using?” Then I take all those findings, present it to the internal stakeholders and partners that I have within our company, and we align on whether or not this is the right problem to be solving, or if there's something more that we discovered. Basically, it's just understanding data teams and how they operate, and then formulating a hypothesis on the problems that they're experiencing. Then further ideating on a couple of solutions and how we think we can help them or formulate new approaches. (7:09)

Alexey: Yeah, that's quite interesting. I know nothing about product designers. But you described your responsibilities as a product designer previously, where you would also do a lot of user research. That would involve talking to users and understanding their problems, and then thinking about how you can actually solve these problems. Right? Or maybe I misunderstood you. But it seems like there are some similarities between what you're doing now and what you were doing previously as a product designer. Is that right? (9:58)

Sara: Yeah, absolutely. Oftentimes product designers and product managers work in close collaboration during this phase – I guess you can call it a ‘product discovery phase’ – where we're really getting in the weeds with some of our customers, or potentially prospective customers, to understand what it is that they're trying to do. “What is the problem?” Then we just validate some of our assumptions around the solution that we will eventually embark on. (10:29)

Alexey: So, ‘product discovery phase’. What other phases are there? (11:00)

Sara: Following product discovery, it's not just about the customer development piece – there's also market research, researching the tooling, as I had said before. Sometimes it's a little bit of data analysis, if we have data at our disposal to kind of formulate an understanding of the problem. When you say “What's the rest of the process?” Do you mean as the product designer, as a product manager? (11:07)

Planning with the team

Alexey: Well, I guess, when you said ‘product discovery phase’ I thought, “Okay, that's just maybe phase number one and there could be other phases.” I assume there is some sort of process. So first, you do product discovery, and then you do probably some other things. That’s what I was thinking. (11:38)

Sara: Yeah. So let me go into the process of planning with the team. A lot of that I kind of covered – where we present our findings to stakeholders and partners and we align on whether or not the problem we're trying to solve is the right problem. From there, if the team is aligned and everything's a ‘go’, we go into the process of working cross-functionally with engineering teams, as well as designers, if the product solution happens to have an interface. We really just go through a process of ideation. That involves a lot of rough prototypes, like, “Here's this specific goal that we're looking to meet. How can we accomplish XYZ? How can we accomplish a specific experience that we're targeting?” (11:51)

Sara: From there, we go through a couple reps of, “Okay. How confident are we in the solution?” Before that point, we try to figure out, “Okay. Well, how are we going to measure the success of this?” We generally have success metrics in place to kind of articulate, “What is it that we're trying to accomplish here? How do we measure that against something?” Sometimes it's an actual metric like, “We want to see XYZ happen.” Or sometimes it's “The customer should be able to do this and they should be able to do it effectively.” (11:51)

Sara: From there, we go through the process of engineering, “OK. We're going to build this thing.” We go through a few reps of demoing along the way. Depending on the dependencies that are needed for the specific feature, development can take anywhere from a few weeks to a month. (11:51)

Sara: Then I go through the process of product management, where if we run into any potential like ‘gotchas’ and have to reevaluate how we're implementing the solution, I coordinate with the team to make sure we can get through those phases. Then it's the product launch process, where we work cross-functionally with the ‘go to market’ teams of smart product marketing, potentially other product stakeholders, design, etc. We kind of generate all the things that we need to do in order to get the product to market. Then we go through the release process. That’s kind of the short description. (11:51)

Alexey: Yeah, interesting. So it’s the product discovery phase, then the planning phase, then ideating, and then starting to think how you’re going to implement this thing and setting up KPIs. Then you actually deliver the thing with the engineering team and then go through the process of launch after this thing is engineered/created and actually release it. Did I get that right? All the while, you as a product manager need to think about all these phases – all these steps – of the process, right? As a designer, previously, you were mostly involved in the product discovery phase? Or were you involved in other phases as well? (14:22)

Sara: Mostly the product discovery, and then the execution phase, where we're iterating and developing solutions. (15:03)

Design thinking and product design

Alexey: I heard about this thing called ‘design thinking’ – is this in the ideation phase? When you think, “Okay, here's the problem.” and then you think about how you can solve it. Do you, as a product manager, also need to know these kinds of things and use them or not? (15:10)

Sara: It really depends on the product manager. Some rely on the partnership with the product designer to guide them through that process. Some actually have a really keen sensibility for it. I think it really depends on the background and expertise of the product manager, but it's generally not the expectation. They should have an understanding of whether or not the experience actually delivers on the goals that they've set, or the requirements that they've set. But it's not always a requirement. (15:26)

Alexey: But from what I understood, having experience in product design is definitely helpful for transitioning into a product management role, right? Because there is some overlap, especially this product discovery phase and other things. How did you become interested in product management? (16:03)

Sara: I've always been super fascinated with how companies work, and more importantly with how they go about building products. I've always preferred to work in super close partnership with product managers, as a designer. I’ve always found that I was never satisfied just fulfilling my own part. In particular, I was super interested in working cross-functionally alongside our engineering teams, understanding the systems driving behind whatever we were designing and building, as well as the process of measuring success of a feature product. It wasn't just enough that we launched something, it also included thinking, “Okay. Well, how successful was this product release? Are customers able to get done what they need to? Are they able to achieve whatever the product is meant for them to do?” Then, if not, “What are some areas of measurement that we can start iterating on? We realized this, but now what?” This is a very simplified example, but if we take a generic funnel – “Oh, people dropped off at this point in the user experience. Okay. Well, why?” You can then generate a series of hypotheses. You can go back to customers and you can talk with them, and then develop an understanding and enhance that feature down the road. (16:26)

Alexey: So you thought that you wanted to have a larger scope and work in cross-functional teams? Was it clear for you that you needed to go down this road of going into the product management role? How did you realize that this was actually what you needed? Because you already had experience working with product managers, right? (17:55)

Sara: Yeah. It's actually interesting. A few companies back, I was really pushing the product team to conduct experiments. I was like, “Experiments are super easy.” I earned that experience when I was at a B2C company and we had a rigorous growth strategy. So that's where I entered into like, “Ooh, what's A/B testing? How can we effectively use data to drive our business decisions?” So, a few companies ago, I was really pressuring the product team, like, “Hey, maybe we can test this hypothesis out as an experiment? What kind of data do we have at our disposal? How can we measure this?” I remember the VP of product at the time approached me and was like, “I've never heard a designer advocating for data, ever.” She's like, “I would be interested in talking more. I think you would be a great PM. We should talk about it.” I didn't make the transition back then. But it ended up working out. I ended up making the transition further down the road. So yeah, that's what kind of led me into it. (18:24)

Data PMs vs regular PMs

Alexey: Why data PM specifically? Or it just happened? (19:38)

Sara: There is a reason. Throughout my career in product, I spent a lot of time talking to various people in different fields, industries, roles – from different backgrounds. And I often ask the question, “How do you go about making decisions?” Every answer is a little bit different, but one thing that they all have in common is data – every single one. The problem I've found is that most people who work outside of data teams generally don't have access to know-how, or have the know-how to leverage that data. Oftentimes, they're struggling to meet their objectives while not having effective ways to measure the success of their projects. That then leads to a multitude of problems down the road. Either they're working on the wrong thing, or maybe they're underdelivering on something that they should be focusing on a little bit more. (19:44)

Sara: I wanted to learn a lot more around how data teams operate and how they can take, oftentimes abstract, requirements from all over the business, synthesize the data and make it actionable. To me, that was super interesting. Especially the last company that I worked for, which was an HR data platform – a lot of HR professionals are working with massive amounts of PII. So understanding the compliance implications around that involves asking “How do you store that data? How do you make sure that it's secure? How do you make sure that the data that you're receiving in your HRS tool is correct?” Because a lot of times, there's a lot of various different sources of data that are coming in and you have to rely on humans as part of that data entry. So how do you make sure that the data that you're receiving – that you're using to interface with your employees – is correct? That’s what kind of led me into my interest in data. (19:44)

Alexey: Maybe it's a gross oversimplification, but from what I understood – a data product manager is a product manager that works with data teams or works inside a data team. This is correct, right? (21:47)

Sara: Yes. (22:01)

Alexey: Are there any other differences between a more traditional Product Manager and a Data Product Manager? Apart from things that you mentioned – that you need to know what PII stands for and that you need to think about data quality and other data things? (22:02)

Sara: I'm relatively early in my career, so I'm still figuring that out. I also feel like there are a couple different interpretations that I've read about as to what a Data PM is. I've heard some people say that it's part data analysis – you are also an analyst as part of your role. I've heard that sometimes you're a data scientist as well. So, to answer that question, I'm not sure how to answer it, honestly. I'm still in the initial phase of learning how to be a decent Data PM. (22:21)

Alexey: You said that you need to be a bit of a data analyst. Do you need to know things like SQL and to be able to go fetch the data you need, and build some dashboards? Or you still rely on somebody else to do that? (23:00)

Sara: I guess it really depends on the makeup of your team. But I would say that it would be a pretty hard requirement. [laughs] You need to know how to get the data and to check the work and make sure that whatever output you're getting is what you expected. I did quite a bit of learning. I learned SQL. I took a few courses in data engineering – I took some data camp courses to kind of understand some of the fundamentals. I think all of that is super important – to develop an understanding and to build some context around the tools that you're building. (23:14)

Alexey: So, SQL and also bit of coding, I guess. You said you were taking some courses about data engineering. For that, you probably also need to know some Python or something else, right? (23:55)

Sara: I have not learned Python yet. (24:10)

Alexey: So you were just watching these courses to understand what problems data engineers have to deal with? Right? (24:12)

Sara: Yep. (24:19)

Alexey: That's interesting. But SQL would be something that you use quite often, right? (24:20)

Sara: Yeah. I use it quite a bit. (24:26)

Skill requirements for Data PMs

Alexey: We have a question from Virginia. “What skills should you have to become a data product manager?” You mentioned one of them is SQL. What are some other skills? I guess maybe the skills of usual PM as well? (24:30)

Sara: Yeah. I would say that you should have an insatiable hunger to understand how data works. You should be interested in solving data problems for your customers. Not just the data engineers themselves that are building the tools, but also those who are most impacted by that data (consumers within the business, internal or external) who might be making decisions. But you should also be addicted to the idea of innovating and taking data further. What I mean by that is, when I entered this role, I had a very rudimentary understanding of data, I would say. But one of the things that the founders of my company said is “That's actually a good thing. We need a fresh perspective. We want you to go through the pain – listening and hearing about stories of what data engineering teams are going through and what data professionals are going through. Come in with a fresh eye. Go through the experience. Use your UX background to pull apart all the things that are working and aren't working.” So I would say, I don't necessarily think you need to have a background in data, you just need to have an interest and a curiosity in it. A technical background does help. A lot of what I do is read documentation, which is sad to say, very painful to read through. Specifically around data tooling – it's really hard. (24:44)

Alexey: You mentioned that you need to have a hunger for understanding how data works. How can someone develop an understanding of that? How can you understand how data works? In what sense “how data works”? How it is produced, processed, and consumed? (26:33)

Sara: I think it starts from just understanding where it comes from, to start. Understanding how a culmination of all the working parts comes together. I feel like the interesting thing about data, is that it's never just one piece of data that informs an answer to a question – it's usually a combination of various points of data that can ultimately answer a question well. I would say that having an interest in understanding what that actually means is where you begin this journey. From there, you can go into the process of understanding how that data is pulled from various different sources, how it's prepared through transformation, and then prepared for either a data warehouse where an analyst can take that and run with it. Or maybe it’s a data lake where you're logging or whatever. Or maybe it's being directly plugged into a data application. So you need to want to go through that journey of understanding how it's used. I feel like everyone just thinks that data is used for data analysis, but there are so many other applications and use cases. Starting to dig in on all the different ways that data can be leveraged as part of a business, but it really is the underlying layer of every company. (26:58)

Going from a product designer to a data product manager

Alexey: Basically, you’re saying that understanding data and being curious about how it's actually used and how it's produced, is quite important for this role, right? I'm quite interested – when did you make the switch? Like a year ago, I guess, you became interested in this topic. Let's go back in time when you became interested and you realized, “This is what I want to do.” What did you do after that? What were the steps that you took to actually end up in this role? (28:30)

Sara: I kind of made my point of entry as a product designer. I wanted to design and develop tooling around data, so that I could better understand it. Part of that journey was really getting into the motion of designing and developing data tools and learning from a lot of the engineering teams that I was collaborating with. It kind of just happened. I feel like this happens a lot in my life, so I don't know if this is directly applicable to other people's experiences. But I happen to be oddly connected with a lot of people in the data space. I don't know if it's because of the types of companies that I worked for, but really just having conversations with them and talking about some of the problems that they had at the time. (29:13)

Sara: HR professionals or companies that were hiring and leveraging background check data – how they were making decisions and like, “How does this work? How do you do your job?” And like, blah, blah. So I just kind of got into some of the more tactical aspects of their work. I think at the time, I had a very granular understanding of it. From there, it really was just about networking with various people. How I got into this specific company where I'm actually designing and developing data tools directly – like Meroxa. Actually, I had worked with the CEO at a prior company. We worked on developer tools at Zendesk. He and I already had a familiarity working with one another, and he was like, “Hey. I'm working on this new application. There's going to be a marketplace and all these things. Let's do this.” It kind of just happened. I didn't really have a process of steps that I took. I mean, I wish I did. But, really, it was just about putting myself out there, having conversations – talking with people and showing that interest, which kind of led to me making the transition. (29:13)

Alexey: So, mostly networking. I'm also curious – did you take any specific courses that helped you? Or were you taking courses after you actually made the transition? Because you mentioned that you took some courses, you trained yourself, you learned SQL, and you also took a data engineering course. Were you doing this before actually becoming a data product manager, or after? (31:40)

Sara: It was actually after. If I could have done one thing differently about this transition, I would have done this much sooner. [laughs] Much, much sooner. (32:05)

Alexey: Basically, you first became a data product manager and then learned those things. You didn't study specifically for this role to become a data product manager? (32:15)

Sara: I did not. (32:27)

Alexey: That's amazing. But let's say if somebody wants to do this right now? Of course, they can… how do you say – “fake it till you make it” right? But let's say if somebody comes to you and says, “Hey, I want to become a data product manager. I am now a product designer. What kind of things would you recommend that I learn to be able to make this transition?” (32:30)

Sara: I think I always start by asking the question like, “Well, why a data product manager?” I want to understand some of the motivations as to why they want to go to that from product design. A lot of that can help inform “Okay, what is their decision making here?” If they're already inclined to data, then just, “Yeah, you should make the jump.” Here are some things that I think you can do. Build case studies around data projects that you've worked on. Go through and outline the process of actually working, designing, developing, solutioning around a data product – that would be immensely helpful. From there, whether or not you were working with a product manager, or maybe you were flying solo, who knows? Depends on the makeup of your team. If you can build case studies around the products that you've built, I think that could go a long way in demonstrating your ability. (33:00)

Sara: That's something that they can take with them when they either make a transition in their career within a company, or even if they decide “I'm going to go for it. I'm going to start applying for potential positions in product management.” I would say that a lot of my friends in general product management have said I'm crazy for jumping straight into not only data, but also transitioned in product management at the same time. Like, it's hard. It's challenging. I feel like I'm learning a lot of things all at once. I've fortunately had the privilege to have a lot of great people in my network that have helped me develop an understanding and get there. (33:00)

Sara: Really leveraging the people in your network that are already in the space to understand “Okay, I'm curious what you think about my case study. Can we talk about this? Tell me more about, maybe the things that I'm not understanding about what I've worked on.” Learning some of the fundamental skills around SQL – if you want to learn Python, you can build data apps, if you want to. I feel like there's pretty simple ways of showing that ability through something like using public datasets that are broadly available out there. You can build case studies off of those. You don't have to necessarily use your existing work. So if you want to build an application that services COVID-19 data – you can build something around that. I think that could go a long way in helping you move into the direction of data product management. (33:00)

Case studies

Alexey: What's a case study? You said, “You should have case studies around data projects.” What does a case study look like? (35:51)

Sara: A case study really goes into the problem that you're trying to solve. Usually, there's a central problem – something like, “We're trying to make COVID-19 data more accessible to people in this demographic.” Then you can go through the process of all the research that you went through and the data that you have. It's very similar to what a product manager does when they build a one-pager to explain the ‘why’ behind what they're doing. You can then go into the process of “Here are some opportunities identified. Here are some prototypes.” (36:00)

Sara: It’s basically going into full end-to-end process of developing a data product. So it’s not only saying “Here was a solution.” You can also go back and say, “I went back to customers and asked ‘What could have been better? Did you use the tool?” So, asking questions, understanding the utility of it, and whether or not it actually achieved the outcomes you were expecting. Usually, there's a conclusion “This was a very successful product.” Or maybe “This wasn't as successful as I thought, and here are ways that I would potentially improve on this feature or this product.” (36:00)

Alexey: Interesting. If I understood you correctly, a case study should contain a problem and describe the research you did – the outcome of this research and identified opportunities. Then you have the solution that you came up with after doing this research. You probably do a few iterations on that. Then there is the final outcome – some conclusion “Was it a successful project or not?” You do this as a document with a couple of pages, right? (37:21)

Sara: There are a couple of different formats you can go with. I've seen some people just put it on their personal websites. That's one of the best ways. Like a blog post. Some people actually use Medium as a way to present case studies. If you're directly applying and sharing with a specific group of people, you can use a PDF. I've seen case studies packaged in a number of different ways. Slidedocs work, too. It really depends on who you audience is. I love it when I go to someone's website and see a list of case studies that they've worked on. I'm like, “Ooh, cool! What have they been working on?” I think that's a great way to get discovered, as opposed to having to go through the process of specifically applying and sending out your case studies to individuals. Just put it somewhere public, where people can find it. That can generate a multitude of opportunities for you. (37:57)

Resources for learning about product management

Alexey: Okay. You mentioned multiple times that networking is a big deal, right? Thanks to your network, you managed to get a lot of opportunities, including the job you have right now. You said it was your former colleague from some previous job. You also said it's important to be ‘discoverable’ – people can discover you through blog posts and other things. This involves preparing case studies and putting them out there and then people can find you through these case studies. We also talked about the different phases of a project or a product. This is something you should also know as a data product manager, right? I guess you would also need some product management skills for this job. Do you know any good resources that can be used to pick up these product management skills? (39:04)

Sara: There's a ton of different courses out there. I can send a list that I've collected over the years and you can include that. I haven't gone through a specific bootcamp. Most of my learning has been on the job. So I can't recommend one through direct experience. Actually, no. That's incorrect. I went through the Reforge Product Management Fundamentals course – which is great. They go through all the various stages of product development for a product manager. You get to talk with and interact with a bunch of product leaders in various different industries to learn more about their experiences. A lot of those are directly applicable to the work that you'll be doing. There's also a range of various exercises that you do. It's quite a commitment, but I think if you want to get your feet wet and dive into all the motions of product management, it’s a good course. (40:08)

Sara: The thing with product management – it's not just one set of linear processes to everything. It really depends on the products that you're working on, the team structure, etc. So understanding, having the foundations, and knowing what you can add to your toolset as a product manager is super powerful. Taking a course like the one at Reforge is really good. You can build that toolset, ask questions, understand the context behind it by talking to industry leaders, and then know when it's directly applicable to the work that you're doing. Then you can make the best decisions for your team. (40:08)

Alexey: Thanks. I was thinking of something like a course plan or study plan for somebody who wants to transition to this role. So first, you should take some sort of general product management course or pick this skill up somewhere, maybe not necessarily through courses. Then you mentioned SQL and other data-related things. You should also prepare your portfolio, take a couple of case studies and put them up on Medium. That should be sufficient. Or is there something else that's missing? Networking – of course. Right? (42:19)

Sara: I would say to really put yourself out there and talk with product managers that work extensively in this space. That's another thing that I also would have also done a bit differently. It's just hard to find data product managers. They're relatively rare. I'm learning from my VP of Product, who has been working in data for a decade. He used to be a data engineer and is now the product leader in data. So a lot of my learning also comes from him as well. He coaches me and guides me through that process. (43:02)

Sara: I think one other thing that would be super useful for individuals who want to become data product managers, or product managers in general, is to find someone who can mentor you or guide you through this learning process. I would say, while it is relatively hard to find data product managers, you can find them if you look at all the data companies out there and see who is working in product at those companies. You can generally find someone. Definitely find a mentor that can help guide you through the process as well. (43:02)

Data PM’s biggest challenge

Alexey: Okay, thanks. We have quite a few questions. I wanted to start with a question from Janine. The question is “What's the most challenging aspect or task that you've encountered in your role as a data product manager?” (44:22)

Sara: For me, it's really been learning how to interact with the tools. I'm not an engineer, I'm a designer. I can do a little bit of coding, but getting through the documentation of some of the data tooling out there – as I think I mentioned earlier – it's really hard. A lot of that comes from, at least in my experience, understanding all the dependencies and other various tooling that comes into play. “Spin up a service with Docker and all these things.” And I'm just like, “Okay, now I need to figure out how to do that.” There's a lead up to getting a specific outcome and it's not always apparent when you're reading up on how to use a specific tool. (44:41)

Alexey: Especially when these docs are written by engineers, right? They kind of assume that people who read these docs have the same background as them and can easily understand what they mean. But if you're a product manager, maybe you don't necessarily have the same background as they do. So that was the most challenging aspect for you? (45:35)

Sara: For me, yes. (45:59)

Multitasking and context switching

Alexey: We have a question from Virginia. “What does your day-to-day look like?” (46:01)

Sara: My day-to-day is kind of all over the place. Obviously, we have the ‘first of the day stand-up’ with the team. That's really just to figure out what engineering is working on, what design is working on, what product is working on. A lot of my time is spent on figuring out the ‘why’ behind some of the things that we're planning. Whether that's a new connector, or maybe a new feature set around transformations. I need to figure out, ”What problem are we trying to solve?” and go through that process that I talked about before. (46:10)

Sara: But there are a lot of other things that happen in between as part of the days. It's not just doing the work of product development – it's also working cross-functionally with other teams. I work pretty heavily with our marketing team. I do a lot of quick and dirty data analysis for them, so that they can get answers to questions about our customers. I'm directly querying our platform API database to understand, “Here's a list of customers that fit these attributes for you.” It's doing a lot of that at the same time. We are also very early stage, I should mention that. We're not a big company. Part of my job is also fulfilling other areas. (46:10)

Sara: I'm also in design reviews – sometimes it's related to projects that I'm on, sometimes it's not. I also offer design critique. There’s also customer development conversations – one part of our job is just getting out there and talking with data professionals even if it's not directly tied to a project. We reach out every day to either people who have signed up on our platform or various data professionals within my internal network, or external one. I get time on the phone to talk with them and learn more about their experiences. (46:10)

Sara: There’s also instrumenting. At least right now, I've been instrumenting product analytics tracking. That involves figuring out “How do we best utilize our analytics tracking tool to measure user behavior in our application?” I do a lot of side projects like that – projects that reinforce the work that we do. There's a lot that goes into the day-to-day and it's not always the same. (46:10)

Alexey: Are you always multitasking or do you try to arrange your day in a way that you don't have to switch contexts? (48:44)

Sara: There's a lot of context switching in product management. That’s kind of the name of the game. You need to prioritize what you do in your day-to-days. Obviously, someone can come at you and say, “Hey, I need an answer to this question.” It's up to you to really decide, “How urgent is this?” And like, “What is this for?” You can determine throughout your day when you actually do that work. There's definitely work that comes up in the middle of the day where I'm like, “Oh, this can be kicked off till next week. Okay. Let's talk next week. I'll have the answers for you then.” It's really just prioritizing your day and understanding, “What are the key things that I need to get done?” Especially at early stage – you have to use your time wisely. (48:52)

Alexey: You mentioned that you spend a lot of time talking to data professionals, getting on the phone with them and asking questions. I'm wondering, what are these conversations like? What do you ask? It's called CusDev, right? (49:37)

Sara: Customer development, yeah. It can range depending on who I'm talking to. I'm not just talking to data engineers. I'm also to talking to data scientists, data analysts, data analyst engineers. A lot of what I talk about is just to understand what their core responsibilities are. Depending on that answer, sometimes we'll go into, “Okay. What specific problems are you trying to solve in this area? What challenges are you running into?” So it’s really about getting into some of the tactical aspects of the tooling that they use, or maybe some of the organizational problems that they have, where it's not just the tooling. (49:58)

Sara: Maybe the company isn't data driven. Maybe they aren't given the resources that they need, so we need to figure out how they can get around that in order to do their job. A lot of the conversations, in general, are more geared towards – it's a flowing thing, there's no rigid structure to it – but I do like to hit the points of “What are your responsibilities? Where are you currently focusing your time?” I dig into some of the challenges specifically so that I can understand, “What could be better in your day-to-day? How do you accomplish that today? Are you accomplishing that? Or are you not?” (49:58)

Alexey: And if somebody wants to talk to you about that, how can they reach out to you? (51:23)

Sara: Ah, you can send me a message in the DataTalks.club Slack [laughs]. Or I can share my email address. I'd be happy to chat with anyone. (51:29)

Alexey: You said that if someone leaves their email on your website, you will find this email and contact them. Right? (51:44)

Sara: Yep. (51:54)

Insights from user interviews

Alexey: Okay. What was the most interesting part – what was the most interesting, let’s say, insight that you got from these conversations? (51:55)

Sara: Through the discussions, it was interesting to see – and maybe I wasn't too terribly surprised, but it was surprising all the same – is that a lot of data teams spend a lot of time educating various cross-functional teams on how to leverage data. In a lot of discussions that I've had, specifically with data engineers, I feel like they operate in isolation at a lot of companies. I'm starting to see that a lot of teams are integrating data into their product teams. But for a really long time, from what I've seen, a lot of data teams are in service of product, in service of marketing, in services of business intelligence. (52:11)

Sara: A lot of what they do involves a lot of context switching between “OK, now I need to help this person understand the data that they're asking for. And I need to make sure that this person has this.” It just sounded like there was a lot of whack-a-mole in their role. I guess it was interesting to me to understand that largely, even though there are a lot of teams that heavily rely on data, how little professionals in various fields truly understand it. Also how much work goes into educating those different business partners on how to use data. I just found that super surprising and unsurprising at the same time. I don't know. (52:11)

Using new, unfamiliar tools

Alexey: Yeah, interesting. We have quite a few questions. One interesting one is “If you need to work with a new tool that you have never used before, how do you learn this tool, while not letting the task to be delayed? Do you learn it yourself or do you ask for help? How do you approach that?” (54:09)

Sara: Generally, I try to take a whack at it first. A lot of that is just documentation diving, stress testing – all the things that I could possibly do or know how to do. If I run into a wall, we have quite a few tenure data engineers on my team. I'll usually reach out to someone and say, “Hey, I'm getting stuck here. Can you help me?” Or “I don't understand why it works this way.” I rely a lot on my engineering team to help me understand. The goal here is that eventually I can help myself. But right now, as I lack understanding in some of these tools, it's really just asking for help from the engineering team. (54:32)

Alexey: How do you usually do this? You mentioned this in the stand up? “Hey, I got stuck here. If somebody has free time – can you help me?” Something like that? (55:15)

Sara: We have a help channel in our Slack. It's just literally a Help channel. You can ask any question. No question is a bad question. Then we just make time to pair up for however long it takes. We get through the process together. It’s really ad hoc. (55:25)

Alexey: Yeah. Okay. Do you work on creating documentation yourself as well? Or are you more of a consumer of documentation? (55:46)

Sara: I help with the framing and the positioning of how we word things. But currently, developer advocacy and engineering work together to develop that documentation. (55:56)

Documentation

Alexey: Another question we have is “Do PMs document the product and features? How do you do this?” Let's say somebody new joins and they want to go through all these product discovery things and so on. How can they learn this? How do you document that? (56:08)

Sara: A lot of our work is documented in product docs – one-pagers, PRDs. We also have a database of customer development notes. We articulate “Who did we talk to? What was our role? What company do they work for?” Then we go into all the points that I had explained before, like their responsibilities, problems that they to solve, etc. Because our product is real-time data, we talk a little bit about CDC and the applications within their current data stack, if applicable. So we'll lean in on that a little bit. But we document everything. Everything is recorded for note-taking purposes. Then we go through the process of cataloging that. We also use it quite frequently. (56:30)

Sara: We have a product weekly update where we communicate what we're working on to the team. We often draw that information into what we talk about on a weekly basis. “This is what we've been hearing from customers. If you want to look more into those conversations, you can find that information here.” So we're actually pushing our team to go into these customer development notes and build empathy. They might already be data engineers or engineers that understand the product, but it really helps to bring them along in that process and building empathy for the tools that they're building. (56:30)

Alexey: You mentioned PRD – this means product requirement document. Right? (58:01)

Sara: Yep. Product Requirement Document. (58:06)

Alexey: Yeah, I was thinking about what it means. I think I heard this abbreviation before. Do you have a couple of more minutes? (58:09)

Sara: Yeah. I do. (58:22)

Idea generation

Alexey: We have some more questions and I think maybe we can cover at least one. A question from Byram is, “What are the steps for working with data teams? Who comes up with new ideas? Who brings up the data requirements?” (58:24)

Sara: What are the steps for working with data engineering teams? (58:45)

Alexey: Where do the ideas come from? Do they come from you? Are they coming from the customers? Are they coming from the engineers? Are they coming from everywhere? (58:51)

Sara: Gotcha. It's a culmination of all those things. Obviously, we have a company and business and product strategies that we're running. A lot of the opportunities that we go after are things that we prioritized, which engineering and product leadership have defined for the team. Then someone like me, who's an individual contributor, we take that and go through the motions of validating whether or not it's the problem to be solved. (59:03)

Sara: We do all the research and then come back to the team and say, “Hey. These are my findings. We still think this is worth going after.” A lot of the idea generation is coming from engineering leadership, at least right now. But that doesn't necessarily mean that a feature idea purely comes from them, because through our research and building an understanding of problem space, that might change how we approach a feature or whatever we end up releasing at the end of the day. (59:03)

Alexey: So if the engineering leadership comes up with an idea, it doesn't mean you immediately run and implement it. It first goes through the validation stage and you actually ask the customers to get some feedback from them. So that's the process. I guess you just have some sort of backlog with ideas and you try to prioritize that backlog. Then you pick the most promising ones and go through this process. (1:00:11)

Sara: Yep. Exactly. (1:00:38)

Do Data PMs need to know ML?

Alexey: Let me try to rephrase it. Are you responsible for the reports, dashboards, and so on? Or machine learning models as well? Do data product managers care about machine learning and data science stuff or mostly about analytics and data engineering stuff? (1:00:40)

Sara: I personally have not entered that stage in my career. But yes, that is the expectation. (1:01:23)

Alexey: Yes – meaning that it also includes data science stuff, not just data analytics, right? (1:01:29)

Sara: Data science, yes. (1:01:34)

Alexey: Yeah, I think that would be it. Do you have any last words before we wrap up? (1:01:37)

Sara: No. I'm just very honored to be here. As someone who has just entered into this role and in this very specific, fascinating industry. I'm just glad I could talk about my experiences with you all. Yeah. Thank you. (1:01:45)

Alexey: That was really great. Thanks a lot. Thanks for finding time to join us. I know for you, it’s a bit early. Thanks for being available and sharing your experience with us. Thanks a lot. Thanks, everyone, for joining us today and asking questions. We've had quite a lot of questions today, so thanks for being active. Yeah, I guess that will be it. Have a great weekend, everyone. Goodbye. (1:02:02)

Subscribe to our weekly newsletter and join our Slack.
We'll keep you informed about our events, articles, courses, and everything else happening in the Club.

DataTalks.Club. Hosted on GitHub Pages. We use cookies.