June 22, 2022

Succeeding as the First Product Hire With Francisco Alberini of Monte Carlo

Spotify podcast player badge
Google Podcasts podcast player badge
Apple Podcasts podcast player badge

This episode of Product Chats explores how you can succeed as a company’s first product hire. We chat with Francisco Alberini of Monte Carlo who shares his experience taking over product from his company’s founders. It’s a great discussion with actionable insights, so be sure to check it out.



Time Stamped Show Notes

Engineering bootcamps + getting into product [01:34]

Being a company’s first product hire [02:40]

Understanding customer problems vs feature building [04:55]

Balancing customer problems by impact [06:31]

Getting to “why” [09:00]

Aligning with the C-suite [10:56]

Building a culture of customer obsessions[14:15]

Leveraging data to drive your product strategy [17:52]

Understanding when data can’t answer your question [21:13]



Product Chats is brought to you by Canny. Over 1,000 teams trust Canny to help them build better products. Capture, organize, and analyze product feedback in one place to inform your product decisions.

Get your free Canny account today.


Stay Connected!





Kayla: Thanks for tuning into Product Chats. On today's episode, I talk with Francisco Alberini who is the product manager at Monte Carlo Data. And we talk about being the first product hire, getting alignment and using data in building out your product. So hope you enjoy the show and don't forget to leave us a review.

Kayla: Hey Francisco, thanks so much for coming on today.

Francisco: How's it going, Kayla, thanks so much for having me. Really looking forward to this conversation.

Kayla: Yeah. Going great. So I wanna know more about you. So in a minute or less, can you tell us about yourself?

Francisco: Sure. Yeah. So my name is Francisco. I am currently a PM at a company called Monte Carlo and we're focused on creating what's called a data observability platform.

Francisco: So we work with data engineering teams, mostly to help them improve the quality of data and do something we called reducing data downtime. Prior to joining Monte Carlo, I was at Segment for about five and a half years. Started in success. I built a or started managing the success team, then built the solution architecture team and then moved over to the product org.

Francisco: And I spent two and a half years working on a product called protocols, which is all about helping customers improve the quality of their data within segments. So there's a bit of a theme. I am generally obsessed with how people use data and how companies can improve the quality of that data. And do so at scale.

Francisco: Before that I did a coding bootcamp, you know, just like kind of a winding career through social media marketing and a bunch of other things. But today I'm a, I'm a tech person. Loving it.

Kayla: So I kind of wanna go back. You mentioned you went to a bootcamp, so would you recommend that for somebody who wants to get in product or like, is there a specific type of person that you would recommend going to a bootcamp? Or what does that look like?

Francisco: Yeah, no, I mean, I think the bootcamp for me, it was like the pivotal moment. I would say in my career that opened up a lot of doors for me. I remember going to the bootcamp and I was like, I wanna be a PM. And my thought was like, I guess I could figure out how to be a PM or I can just get really technical.

Francisco: And then maybe someone will think, okay, this person's technical enough. We will let him do some PM work. I obviously, my path did not go from bootcamp to PM, but I would highly recommend it. I think it really was this eye opening experience of being able to understand how technology works. Like, how do engineers think about solving problems? And then just that alone opened up, I felt a lot of doors and how my brain worked and like in just like thinking about problems in different ways. So, yeah, it's almost like a no brainer. A lot of people that I talk to, I recommend doing a bootcamp and go more technical than you probably need. Never know when that skillset will pop up and be really helpful down the road. So I would say highly recommended it.

Kayla: Awesome. And then with that, right, you mentioned like understanding like the engineering perspective, let's actually kind of talk about being the first product hire and what that looks like.

Francisco: Yeah, it's a great experience, to be honest. So I joined Monte Carlo last year and team was around 20 or so people at the time maybe had six or seven engineers up until that point. You know, obviously there wasn't a product dedicated product function, a lot of different folks in the organization from our founders, Barr and Lior and then some people on success. Everyone was just kind of pitching in on the product work itself, which at the time meant, you know, customer expressed a problem. Let's try and spec out a solution to that problem. Some customer wants us to filter, you know, notifications going into Slack.

Francisco: I'm gonna go out and, you know, and define that as the success person or as one of our founders. And I think when I joined, I was really excited, both because I just, the space to me is just like ripe for this type of innovation. I was honestly, contemplating, like either I start something or I find a company that is solving this problem.

Francisco: I much preferred the latter. I really just wanted to join a company. I didn't necessarily wanna start anything, maybe unlike most people, but whatever, I'll be weird. So, yeah, I think like when I got here to me, the real thing that I wanted to focus on in terms of creating value was like, how do I get all of us aligned, especially given that we're about to go through this massive growth of adding more and more engineers. Previously again, anyone could take ownership of a particular product or feature four or five engineers. You can all talk about that in Slack and figure out how do you, you know, build and ship that feature and then iterate on it based on the customer need.

Francisco: But when you get to 10 engineers, 20 engineers, like I saw my role as, as creating alignment between those divisions and there's a lot of different ways to do that. I mean, from documenting to, you know, defining the vision to repeating the vision over and over in different ways and then creating more documents and then getting other people to create those documents and engage.

Francisco: Like, that's what I really saw my role as the first product hire and there's a lot more, but that, that to me is like the nugget of what I found to be most impactful.

Kayla: So I wanna, we're gonna hop into that alignment in a little bit, but what I kind of something that you brought up a great point is a lot of times when you get like sales and success, they're not having that bigger picture, no offense to sales or success, I'm in sales, but we like to feature build.

Kayla: We like to say, okay, this deal will close because of A right or this deal's only gonna close because of B and something that I think is so important, probably a role you kind of stepped into was, Hey, let's actually take a step back, and let's understand the customer problem versus feature building.

Francisco: Yeah, no, I think that's a, it's a great call. I'm heavily biased towards the solving discrete pinpoint problems that a customer has told me about today. And that is the most important problem that we should solve. So I hear you on that, but yeah, I think the first step for me was just to build the relationships with our success. And to me, the reason that those relations are important so that I could come back to them and say, listen, I know that this deal to close it, you need X feature, but they're the only prospect that is asking for this feature. So it's hard for us to say, let's go take a bet on building feature A knowing that maybe the deal doesn't close, even if we, we ship feature A and then we've spent time building feature A it becomes useless.

Francisco: So I think the way that I think about it is like build the relationships with these different stakeholders and then really communicate how we make decisions on what we do build and then open it up for people to say, you know, I want this feature and I can very honestly, tell them like, that's the first time I've ever heard of that. And I've talked to hundreds of customers over the last year. Not that it's a bad idea, but it's something that right now we're probably not gonna prioritize.

Francisco: And then sometimes I get to say like, yeah, you're right. I've heard that now four times in the last month, we're gonna prioritize that, cause that clearly is something that's coming up more and more. That I think you nailed it in terms of as a PM. It's like, you're kind of playing the filter. You're trying to understand what are the bigger themes of how people or the problems that customers are trying to solve. Trying to deeply understand the problem and then presenting solutions and working with engineering to actually ship something that solves the problem.

Kayla: I think you kind of touched on a point, which we'll go into a little bit later around data and using data to actually back up decisions. But I think something you also kind of touched on, didn't like call it out, but the ability to say no, right. And to say, you know what, like this is a great idea, but this doesn't necessarily align with like what impacts the most customers and what impacts the most revenue. And I, think there's this balance, right? Especially when you're working with enterprise customers, it's like, well, this person is contributing to a ton of revenue. Are we hearing this from a ton of smaller customers that actually equal that same amount of revenue? So how do you like balance that?

Francisco: Yeah. Always listen to the loud voice. I don't know. I'm kidding. We have to, yeah, we spend a lot of time thinking about how do we, how do we balance, you know, we don't want just the loudest person in the room saying that we need to build feature A. But yeah it is a really good question. I found that the easiest thing for me to do is to kind of like deflect to what does the customer want. And a lot of times people have a lot of opinions of like, I want this feature. I think we should build this, you know, because I opened up the app and this particular engagement is hard.

Francisco: Like, I can't figure out how to click this button. And I'm like, has a customer ever mentioned that that is hard? And usually, followed by no, never heard anyone, so I'm like okay, when a customer tells you that is a pain point or that you have like, even an inkling, that this is creating a particular issue and their ability, the customer's ability to solve the problem, that's what I want to hear. So there's been a lot of training around that of almost like just this like immediate deflection to like great, like tell me about a customer that's having that particular problem. And I wanna talk to them or like, tell me what you heard from them that makes you think that this is a problem for them versus what do you think is a problem?

Francisco: And that, to me, I found to be just a super effective tool. And now when new people join that's usually the first thing I say in our initial conversation. New salesperson joins, and they're asking, what can I do to be helpful? And I'm like, just, just tell me what customers are asking you for. And like try and, and reserve your personal thoughts. They're important. And I don't want to downplay them, but like, you know, bias towards what the customer's asking for. It's helpful for me too. Like that's how I'm also getting prioritization or prioritizing features internally. And going up to our leadership saying like, here are the five features we think we wanna invest in and these are the customers that are asking about it. I can't just say here are five features that I think are cool and I hope that they work, but I have no idea cause no one's asked me for them. That's the thing to avoid, I guess.

Kayla: Yeah. And I would say off of that, right. It's working like again, that alignment, right? Making sure that you just have that relationship. And I think you mentioned something that's really important, right? When new sales people join in the team. Meet them and talk to them and say, Hey, here's like how we work. Hear your ideas. And I think the second piece of that also is getting like something that I hear consistently in product is the why. Right. Cool, they want this feature, but why? Right. And so maybe like as someone in product it allows you to see the bigger picture of maybe this customer's dealing with this one issue, but maybe there's three other customers that have similar issues, but it's getting to the same, like base of what their frustration is.

Francisco: Yeah a great example of that, and I've personally been working through recently is we basically catch anomalies within a data warehouse when something looks wrong and then we notify the customer and, you know, we have pretty broad coverage. So in theory, we could be generating a lot of these notices or incidents is what we call them to customers. And I've been hearing now, like on different kind of interpretations of like, I'm getting fatigued by this type of notification or like you're sending too many of this or like these things are not relevant to me. And all of them are like different in variations of what this umbrella topic of notification fatigue is.

Francisco: And I think that's been a really interesting experience for me as a PM to just like, deeply understand, like what, what does notification fatigue mean to you? And like, what are the things that I could do to help the fatigue that you're feeling? And I think strategically it kind of aligns to the higher level of goal of if a notification goes to a channel that no one's ever you know no one's there, then like the notification didn't happen in that case. Same like, you know, if a tree falls in the forest, it's like, if a notification goes to nothing, not important. So yeah, that idea of kind of like understanding the why, like, what is the pain? What, why is this important to you? Or why is it that like these notifications are creating fatigue and to do as a customer, that inquisitiveness I think is, is really critical as PMs. And I see it too, like when I explain that to people as well, even to our sales folks, I think they almost shift their mentality a bit. And like they'll start to also ask questions in that way. And there are a lot of great AEs that I work with and, you know, CSMs that have that, that intuitive, like, I just wanna deeply understand why, like, why is that gets me really excited. I love working with folks like that.

Kayla: So I wanna get back to the alignment piece again. So you talked about like sales and success, but how does that differ when you're trying to align with like your C-suite and what does that like difference look like? Or is it just the same? And you're just having those conversations, like, what does that look like?

Francisco: Yeah. You know, this is interesting. I think maybe it might deviate the conversation, but I do want to answer this question of like working with a C-suite and I think it's relevant as the first product hire. This is where we get like a little spicy in terms that I've heard, but there's this like, kind of saying that's like never be the first product person at a small startup. And I'll explain why. And like I said, it gets a little spicy, but the reason I think that this is important is like as the first product person, you're oftentimes coming to a company where a founder has like basically built the product, found PMF, and this is their baby.

Francisco: So like you, as the product person are like taking the baby, like okay, I'm now responsible for this thing, which is like a lot to shoulder. Right. And I think what, yeah, yeah, exactly. The baby is now I am responsible for your babies. People are like I think founders, a lot of times are like whoa, I don't feel super comfortable about this, but you know, it has to happen.

Francisco: We're growing, you know, the founders are thinking about other problems and like getting pulled into, you know, meeting with every executive buyer. And like, there's just a lot of things that start to creep in on the founder's ability to just focus on shipping this incredible product and experience. So I think what I've seen this is like it creates a lot of tension, right.

Francisco: You're taking over this thing that the founders are like, ah, that I feel really attached to this. Like it's the reason I'm here. It's the reason we raise money, it's like the reason you're working here, like, because of this product in theory. Right. And then all the things that you build on top

Francisco: I am really thoughtful about that. I think for me personally, like I was, it was really important that I felt I was working for founders that like, could feel comfortable giving that away, and it was part of my evaluation process for finding a new role and I feel like luckily that I'm in a situation where our founders Barr and Lior are like, are both really open to giving away ownership. Like they express their opinion, but they're like, Francisco, I trust you. Like you can make this decision.

Francisco: But I know I've heard from other PMs that I work with, that that's not the case. It's actually really challenging. The way I look at it is like, be thoughtful and trying to be aware that there is this tension that exists and then try and be upfront with a founder being like, Hey, listen, like this is gonna be difficult, but like, we can work through it.

Francisco: Let's talk about it. Let's like continue to keep the conversation lines open. I will push back at times. And then I think the second piece to be aware of is like, and to also maybe even put on the table is like as a founder, you're gonna be being pulled in different directions. You're gonna be, you know, how do we hire a head of HR?

Francisco: How do we, you know, handle stock option plans, like all these decisions that are gonna be pulling you as a founder in different directions, which means you have less time with our customers. And like, my role is just to spend a bunch of time with our customers. Like that is what I'm here. I'm gonna be talking to our customers nonstop.

Francisco: So I think I'm gonna have a lot of insight that might be different than your perspective and that's okay. Cause most founders get that. It's just like the need to put it out there.

Kayla: Yeah. So with that, right. You talked about the alignment with executives and kind of nicely taking away their baby or babysitting, talking about.

Francisco: Exactly babysitting. That's a good framing.

Kayla: Babysitting. Then you also talked about sales and success and really alignment with that. Are there any other, like you mentioned a lot of times, basically you'll meet with new AEs. Are there any other like best practices we're gonna hop into data in a second, but are there any other best practices that you like to implement to create this alignment with these teams?

Francisco: Yeah. I mean, I think like the other one is really about just this customer obsession piece. I feel like I've become more and more, almost like just absolutely obsessed with our customers and, and just kind of telling the rest of the organization how important it is that we like focus everything we do and ground all of our truths in like, what is important to the customer.

Francisco: I think it's also a really powerful tool. I was reflecting a bit last night and I remember I listened to this, this man named Bill Scott. And he came and I was at Segment and he came to talk to a PM group there. He unfortunately passed away last year, but just like the he was this incredibly like storied PM product leader.

Francisco: He like worked at Netflix, PayPal, Venmo. He's like a very, very illustrative career. And he kept talking about like, the customer drama will always trump any internal drama. So like, if one thing you do is just like, let's get everyone thinking about the customer. Like all the other problems kind of go away and they just dissipate. I dunno, left a mark on me. I think about that quote probably weekly and just be like, yes, always. It's always about the customer and the customer always has the answer. Like I don't have the answer and I don't need to have the answer cuz the customer has the answer. I just need to like figure out how to find the answer within the customer. And I think just making other people understand how important that is. Very powerful tool for getting everyone aligned and on board. Cool. Yeah. We're all about the customer like you and I, you know, having beef whatever that goes away. It's about the customer. So yeah. Very powerful tool set to, to keep in, keep in mind.

Kayla: Yeah. With that. So you talk about the customer, right? So that, I guess that ties into customer and data. So let's talk a little bit about data, cuz I know Monte Carlo uses data and it's all about data, but let's talk a little bit about that.

Francisco: Yeah. I mean, I think we're at this really interesting inflection point where it's like the most obvious problem that every business faces today is like how they use data. And I think we see all these incredible examples of companies that have been extraordinarily successful by their ability to use data like starting with Google, like Google is basically, you know, indexing data, which is search data and providing back a bunch of results in a really like efficient, fast way.

Francisco: Tremendous value created.

Francisco: Facebook, I mean, like the list goes on. Netflix. Like everyone, all these companies have built this extraordinary ability to use data and to create an incredible product experience for the customer, which has made them extraordinarily successful. And I think today we're at the point now where like, you know, there's enough tools and enough features out there that almost any business can do some of the, you know, the Netflix style, we were able to make these recommendations based on XYZ model.

Francisco: The ability to do that has basically expanded to almost every company, just given the technology. The problem though, that keeps getting in the way is like the quality of that data. So I can go and build an ML model that tells me that this is the right feature that I should, or right product that I should show to this particular customer.

Francisco: But if I don't know who the customer is, or I have some piece of, you know, the incorrect information about the user, like the recommendation doesn't matter cause I don't even know who this person is because of the bad data. And then on top of that, there's all these like issues that happen as data is being transformed and cleansed and pushed through, you know, various data pipelines that it can lead to a lot of issues downstream.

Francisco: And I think we're right at this phase where companies are like, cool, I see the potential in this. I want to leverage that potential, but I'm stuck. Quality isn't right, and I don't know how to fix that. And I think that's basically what I spend my day thinking, how do I help customers improve the quality of data so that they can be extraordinarily successful, like, like Netflix?

Francisco: So yeah it's a really interesting topic. I really think that we're kind of in like the nascent of how data is used within organizations and yeah. Happy to keep talking about it, but that that's where my head's at and why I'm very bullish on the space.

Kayla: Yeah. So let's talk a little bit more about it and like, I would love to hop into some best practices or things that you use to make sure that you're using the data best and that you're using that to like drive your product strategy.

Francisco: Yeah. Yeah, of course. Yeah. I mean the area that we've really focused on is what we call the data engineering function within a company. In my experience, data engineering teams are usually really small, so it's like two to three data engineers and they spend fortunately, a lot of their time answering questions in Slack, around what data is, what, like, how do I find our accounts data? Like, where do I go for that? And now you have a data engineer who is capable of like building ETL pipelines and engineering, and is answering the question, where is the accounts table? It's like asking a software engineer, who's building your infrastructure to be like, okay, tell, you know, whoever in marketing, like, you know, what URL they should use to like find our app and like, no, I don't want that person doing, answering that question.

Francisco: So it's like kind of this weird problem where like data engineering teams are spending a ton of their time doing something that's like not a good use of their time. So in terms of best practices, I think it's just like one being aware of the role that data engineers play and then how do we help enable them and invest in them and give them all the resources to like, solve this absolutely critical thing, which is improving the quality of our data and making sure that we can make decisions as a business using our data. Like every CEO is like, yeah, I wanna do that. and then it's like, but I'm not gonna invest in data engineering because they got it. They can figure out it's like, no, no, they, they need, they need tools.

Francisco: Like they need processes. They need support from the organization to be able to really focus on making the data work and making like the data high quality. Like they're the kind of the foundation of that. So that's one. And then I think the second is like, there's an organizational kind of people component around, how do you help different teams?

Francisco: And, you know, for example, data consumers, let's say I'm an analyst. How do you help that data analyst also do their job better? So they're not having to go to a Slack channel to be like, what's the accounts table? Like where are all of our accounts? It's like, is it accounts new underscore new or accounts V1 or old underscore accounts?

Francisco: Or like, raw accounts. I don't know. These are all different potential table names for finding account information. And how do we enable that to make a decision faster on what is the right data set to use? What are the caveats of that data set? All of these questions that today are easily answerable and therefore creating a bunch of inefficiency in how teams use data.

Francisco: So that kind of people component helping people communicate, collaborate across data is a tricky one, but I think there's plenty of tools that are being built around that today. And it just like being open to investing in those tools is what I would recommend.

Kayla: And I think with that, right, it's all about the investment in A your customer and B the data, right? So listening to your customers, listening to what they want, and then leveraging that data to make better decisions for your product. Right?

Kayla: So you can have that data on okay, X amount of customers want this, or Y amount of revenue will be driven if we build this out. And so really having that data to make decisions . Because I think there's a lot of product teams that say, yes, we wanna make data driven decisions, but a lot of time it's just the loudest stakeholder says, Hey, I really want this. And versus take a step back and being like, let's actually look at the data, obviously something you mentioned, right?

Kayla: Like using data engineers best. Right. But making sure that that data is being actually used rather than loudest stakeholder or like a gut feeling.

Francisco: No, I absolutely agree with that. I think the second piece that I would add and it's maybe a slight variation of that is also being aware when data, like, can't answer the question that you're trying to answer. So this is maybe more common with B2B type SaaS apps where it's, that you have, you know, 200 customers and that's a good thing. Each of those customers are paying you a hundred thousand dollars a year. Great. Like you have a good business, but you can't really statistically significant like creates statistical significance to determine that like, yeah, version A is better than version B.

Francisco: So you have 14 people clicking on that thing. So it's like, okay. Six people clicked on option A and 14 clicked on option B. Like, I can't say that option B is better. I mean, maybe it is, or it just could be that we had 14 people versus 6. You know, so I often keep that in the back of my head as well, of like, to be respectful of what data can and cannot answer.

Francisco: And also to understand that yeah, sometimes it's gonna, you're gonna have to rely on like an anecdotal 5 customers all told me about this thing. Great, let me try and put something out there and then I'm gonna go talk to those 5 customers and get a sense, like, did this solve the issue? Did it not?

Francisco: We can also look at the data of course, and like, we wanna see trends over time, but I think just like that respect for what, what it can do and what it can't do is an important thing to keep in mind.

Francisco: And I try and also express that too. Sometimes engineers will like, we need to do an AB test on this. I'm like, but we have, you know, maybe 50 people are gonna look at this. So like AB test is not gonna work for us, unfortunately. Sure. In a year when we have, you know, 1 million, on our application, I'm all in, like, let's do some AB tests, but to kind of like understand the phase of where you're at .

Francisco: And then consumer apps, it's a whole different thing. This is more of a B2B type of problem.

Kayla: Yes. Yes. You talked about right, that data can only go so far. And I guess that's kind of a piece of advice of use the data when it's applicable and listening to when it's actually not as applicable. Right. Potentially using those user interviews and listening to what your customers want. So on the piece of advice, what would you get? Like what's one piece of advice you would give to like the first product hire?

Francisco: I think I have to go back to the, the point about the, the customer drama. Yeah. I think it's like, just always focus on the customer. Like if there's one thing, one thing you do, then my advice would be like narrow everyone's focus to what is important to the customer. And I think a lot of things fall into place. Another Bill Scott quote that I'll leave you all with. Basically said like customers are the purifying stream that makes a team healthy. So it's like your team will become healthy as long as you focus on customers. Everything else is less important, which I think is helpful for me, makes me less stressed out about trying to make a team healthy. It's like great customers are there. They, they could do it for us. It's actually pretty easy.

Kayla: So with that, right we've been talking about customers a lot. And so I wanna know at your company, what roles are you hiring for?

Francisco: All of them basically. PM. You know, product designers engineers, front end, back end, sales, HR. I mean, literally any, any role. Get montecarlo.com and you'll be able to find all the roles that we're hiring for.

Kayla: And then last question where can people find you?

Francisco: So I'm on Twitter, not a very active Tweeter, but @FAlberini is my Twitter handle. And then I'm also on LinkedIn as Francisco Alberini. Yeah, welcome any questions. Always love talking about product and data stuff, so yeah, reach out.

Kayla: Awesome. Well, thanks for coming on today.

Francisco: Yeah. Thanks so much for having me, Kayla.

Kayla: Thanks again to Francisco for joining us on today's episode of Product Chats. If you want more product management resources, head to canny.io/blog and we'll see you next time.