Olivia Chen (ex Head of Supply, Product at Faire)

Hey everyone, this is Erik Torenberg and you're listening to Execs by On Deck. Execs is a show for founders, operators, and leaders who want to understand the playbooks, frameworks, and tactics that leading tech companies today have used to scale. Our guests are tech execs in key roles at top tech companies who share their hard-won, earned secrets on how to scale faster. Today's guest is Olivia Chen. Olivia was most recently the head of products for Fair. She joined Fair as their first ops and business hire. By the time she left 4 years later, Fair had grown to over 750 employees and Olivia was managing a cross-functional team of more than 60 people. In this episode, we discussed how to build successful referral programs, how to grow a product team, how to navigate hypergrowth as an early-stage employee, and much more. Andrew Yu, Ondex Director of our Product Management Fellowship, joined me in this episode as a guest co-host. We hope you enjoy. So Olivia, when you look back on the arc of your career, how do you sort of tie the threads together in terms of what has connected your interests and where your superpowers are?

Oh, wow. Okay. Starting with a hard question. So I would actually start out by saying that I absolutely was not and am not a person that has always had this idea of, you know, what is my 5-year, 10-year plan? It's actually one of my least favorite interview questions. I have to Make something up for those questions. I'm much more of the camp of, you need to try a lot of things to understand what you do and you don't like, and you just keep moving towards the direction of things that you do like and away from the direction of the things that you don't like. And in that process, you'll get the widest amount of experience. You will be likely much more accurate in what you end up doing in terms of it being the optimal state. It's really just like testing. It's like a product. You have to test a lot of things to know that you're hitting the optimal state. And that's also the point of view that I have towards career building. And it's definitely a younger generation thing. It's something my parents certainly wouldn't necessarily agree with, right? They're of the generation where you stay in the same job for your entire career, right? But we have the privilege in tech to not have to do that. And I think many people don't take the opportunity. I mean, FAIR was amazing for me, and FAIR is where I found my passion, which is product. But I didn't start in product at FAIR, right? I was doing whatever needed to be done. I was doing operations. operations, sales, customer support. And then when I got the opportunity to do product, I said, sure. And I ended up just loving it, just everything about it. I think it's a really, really great mix of analytical, but also kind of artsy with the design. I've always gravitated more towards the design side, as well as talking to customers, working internally. And I don't think it was predictable. What I thought product was before I did product, they're not the same thing. It's pretty hard to know what it is before you do it. And so I have to say, I don't think there's an arc to it. It's almost like you try different things that fall in your path, and then you just double down on the things that you find that you're good at and you enjoy.

There's this trope that startups hire generalists to begin with, like the story you just said, where really smart people who can tackle various different fires and then hire more specialists as they scale and grow and need experts. What was that experience like at Fair as a company? in terms of building out these different functions? Were there a lot of people like you in the beginning running around doing lots of different things and then specializing and you growing into a specialist, or how did that evolve?

Yeah, I would say that Fair generally followed that trope. And so Max, he's our CEO, himself was an ex-consultant. I was a consultant. It just also happened to build a pipeline of ex-consultants. So a lot of our early employees were ex-consultants. Many of us later ended up specializing either within biz ops, data analytics, or product. But I think that's true because in early days, there's a lot that needs to get done. you don't necessarily even know what it is that needs to get done. You just, and on top of that, you don't have to be performing at 100%. You need to get someone who can get to 70%, 80%. People early days used to ask me if I was stressed out working at FAIR, and I thought it was kind of funny. Actually, I was way more stressed at Bain because I told them, you know, as long as I'm doing a better job than someone not doing it, I'm doing a good job. You know, like I'm unlikely to be fired. That was almost like my bar. And so in that way, I actually oddly didn't find it particularly stressful. So yeah, I definitely think it's true. You start out with generalists and then once you scale, you need to have a higher quality of work across everything that you're doing. You're focusing more deeply and then it actually does start to make sense to start hiring people that have preexisting experience in a given field who can come bring structure and kind of this correct best practices to your org as you grow.

Were you the first product manager or what was that evolution like?

So for me personally, like I said, I started more kind of an ops business generalist. My first quote unquote specialization was in general growth. So they needed someone to do paid marketing. So I ended up doing paid marketing. I actually really disliked paid marketing. And I think almost 'cause I disliked it so much, I just really wanted to find any way to grow that wasn't paid marketing. And then I ended up stumbling upon referrals as a growth strategy for Fare. And once they started working, I got to stop doing paid marketing and then work in product, which was great for me and the company at the time. So yeah, I transitioned to becoming our first product manager. I will say transparently, it was a very difficult transition. I think product is a hard job. There was a lot I didn't know. I remember this time when, oh my God, Max, our CEO again, he asked me, did you hand off the designs to the engineers? And I looked at him, I was like, what is a handoff? I thought that the files somehow magically uploaded onto their computers and that they would know what to do once I'd finished working on the design with the designer. There are all these small things that I didn't understand, but you pick it up pretty quickly. And I was lucky to have in the CEO an amazing product mentor. So I started as a PM mostly in growth, ended up really gravitating towards one of the sides of our business, which is the supply side. I just resonated with the customer much more deeply. And then we hired another PM who resonated with the other side more deeply. So it just happened we split the marketplace into 2 sides. And for the majority of my time at Fair, I've worked on supply product and then as it scaled, You hire one person, you have a team of one, 2 people, and by the time I left, my team was probably 6 or 7 PMs, close to 100 engineers, designers, et cetera. But that was my evolution. Yeah, fair.

And is there a framework in terms of hiring 7 PMs versus 3 versus 15? What is the framework or criteria? How do you think about that?

I would say that you shouldn't hire someone unless you have a surface area or thing that they can work on that is obviously distinct from what other people are working on that you know has a large enough impact to merit an entire team of people. A team is very expensive. It's a PM, a designer, 4 to 10 engineers depending. And so you should have that mandate pretty clear in your head before you start hiring. If you're sure, then you should hire, right? But if you are unsure, then it's the job of someone existing on the team to do as much validation as needed. So again, it's not a rule of thumb. If you had 10 jobs that you had security would actually lead to the kinds of plus 10% GMV growth or something, then you should be hiring 10 people. If you only have security in 2 of those roles, then you should only be hiring 2.

Do you hire PMs ahead of engineers or do you always wait until you have—

Yeah, it's a great question. So we used to try to play this game at Fair where we would try to balance hiring. We'll try to keep this ratio of design, engineers, PMs. We're lucky at Fair, we've just always been growing very quickly. But we found when we tried to hold ratios, one team would always end up behind. At one point we stopped hiring for engineers because it was easier than hiring designers or PMs, and then suddenly 2 designers and 2 PMs signed and we were suddenly behind in engineering hiring. So we've just decided full cylinders ahead on all of the functions. Let's not try to keep a ratio. If you have an extra PM, designer, extra set of engineers, you can always find work for people. That is not a problem in a company like Fair. So don't hold back.

Full hearts, closed eyes.

Yeah, just straightforward.

I want to get to the products, the supply product, but first you mentioned referrals.

Yeah.

What's the secret to getting referrals right for founders who want to implement or product managers who want to implement programs? Talk a little bit about that.

Yeah. The key to getting referrals right. It's a great question. One I hear a lot from growth PMs. Of course, the first question is whether or not your business is one for which referrals are likely to work. The conditions aren't crazy. The conditions are that your customers are talking to each other. So if you work in an area where you're— but there are some places where your customers don't, right? I'm trying to think of some products, but products where there's a lot of privacy, maybe this information that you don't want to share with other people, you actually have customers that don't talk to each other, right? So referrals aren't going to work if you don't want other people knowing that. A lending product might be a good example. You might not necessarily want other people to know that you're borrowing money, so you're not going to refer friends to your lending product. So that's the first thing you need to know. are your customers talking to each other? The second question is, in what way are they talking to each other and how scalable are those patterns? If your customers are only talking to each other in in-person events, this is actually harder to productize. This becomes more of an ambassadorship program at this point. It's less of a productized referral program. At Fair, I actually launched all 4 referral programs at Fair. We have 4 possible because we're a 2-sided marketplace. We Brand to brand, brand to retailer, retailer to retailer, and retailer to brand. So I launched all 4 to varying degrees of success. Altogether, they make up over half of our growth as a company. But the reason why success varied was due to different factors in the way people shared, as well as how competitive they felt with each other. So one example, a retailer to retailer, store to store, much less likely to refer because they actually feel competitive, particularly if they are in any kind of geographical vicinity next to each other. That one actually flopped. We ended up deprecating it altogether. Our cross-side referral program is much more successful. There's zero competition. In fact, there's an intrinsic benefit in referring each other to the platform because then you can shop from each other on the platform and transact. So those were much more successful. So you need to understand the patterns of interaction and understand, based on this, what form should the product take? Where is the contact information stored? What is the pattern of interaction? Is it in person, over an app, over email, in a CSV? Is it written down down on a business card? All of these things determine how you should build your product. The other thing that I might add is I think that people have a very narrow definition when I've talked to them about what a referral program even is. So maybe I might even start with what is a referral program? And maybe I should have started with that, but I consider a referral program any kind of growth channel where a user is bringing on another user. And this is much broader than your classic traditional get 10, give 10 that everyone thinks a referral program is. So when I've talked to early-stage founders that are like, hey Olivia, my referral program didn't work. And I said, what is it? It's like literally 99% of the time it's that they launched a get 10, give 10 and it didn't work. And then they decided referrals don't work for me. Many of our referral programs are not actually communicated in this give 10, get 10 whatsoever. And you have to change the product marketing of the mechanism to fit the way that your customer's frame of mind is when they're inviting users. And I actually think a brilliant example is LinkedIn. So LinkedIn has an onboarding flow where within onboarding they ask you, hey Olivia, sync your email and invite all of your contacts to join LinkedIn. The value I get as a user is suddenly all of my network is on LinkedIn. It's not a monetary value, it's a user value. The obviously benefit LinkedIn gets is all the contact information of the people in my email, right? I consider this a referral program. It isn't at all marketed like one, it doesn't look like one, but I think it is one. And so when founders say a referral program isn't working for them, I think it is usually in the way that they conceive of a referral program and less that a referral program actually wouldn't work.

Yeah, Olivia, thanks so much for sharing. So I'm actually a former growth PM myself. So a lot of this was just music to my ears. And when you hear something like 50% of growth driven by referrals, absolutely, that's nuts. That's fantastic. So we'd love to just hear a little bit about how you iterated, how you and your team just iterated your way into that. You've listed here, you have B2R, brand to retailer, brand to brand. There's so many types. How did you even get to this point? Like, what kind of processes, experimentation frameworks got you to a place where you could land on that 50% growth?

Yeah, so I'll start with the brand to retailer referral program because that was our first one and also probably our most successful and the one I worked on most contiguously over my time. The idea actually came to me. I was writing support tickets and a brand wrote a support ticket to me and she said, hey, Olivia, can you add these products to my page? Oh, and by the way, here are 10 stores in, I don't know what city, but in Nebraska that I've really wanted to carry my candles for forever. Can you just give them a call and see if they're willing to carry my candles? It was truly beautiful. She sent them to me in an Excel spreadsheet with the name of the retailer, their first name, their email address, their phone number. And I just had this moment of like, oh my God, I'm spending so much money on Facebook and Google. They're not even giving this information back to us to try to get retailers to order. And then this brand just sent me an email with a CSV of everything we've been looking for. And it wasn't even a very well-known or big brand. And she had tens And that was my moment of, there's something here. And so the first version of the referral program was completely manual. So zero engineers were involved. It was me calling and emailing brands, asking them, hey, do you have a list of retailers you've always wanted to be in? And if you send them to us, I'll have someone on my sales team call them and we won't charge commission on that transaction. We are just asking for their contact information. And I got early positive signal. It wasn't anything though to write home to mom about, right? But I got 10 brands willing to try different sizes. And then one pretty large one sent me a list of 20,000 retailers, obviously not all good data, but I was like, oh my God, this means that there's scale if I can get 10 brands like this. And so again, it was just me and a salesperson sending emails to all of these retailers asking them to order from these brands. And we got, I don't know, something like 17 orders from this channel in the first month. But 17% at that time was probably like, I don't know, it's like 3-ish percent of our total acquisition, something around there, but it was non-zero. And talked with the founders and we agreed it was good enough signal to start to try to build product around it. So we built our initial product and again, pretty simple. You just upload a CSV and then we created a custom link now. So instead of the attribution being done manually by me, the attribution was done by this link. If they order through this link, we know to attribute it to this brand and then this is It starts to feel like a classic referral program. You have your own personalized link that's tracking who you're referring and they're ordering, et cetera. And then there's the idea of, oh, well, maybe 0% commission isn't the best incentive or the only incentive we should use. Maybe we should be giving some money because let's be real, money works. People like money. So, okay, on top of 0% commission, we give $100 off to the retailer, which actually it was a really nice feature. It flows right back to the brand. So you can use the same pile of money to both incentivize the retailer and the brand. So, okay, now it's actually $50 to start, but give $50 and then et cetera. And so at that point, it was already hitting close to 30% of acquisition with even that single iteration of productizing it, starting to get actually a team of dedicated salespeople to go sell it to our brands along with a way to automate the creation of your link. And then to get to the rest of it, I would just say there's a very, very long funnel when it comes to referrals. It's why it's actually quite annoying and difficult to work on. You have number of brands who are aware of the referral, number of brands converting onto the referral, the number of people they are referring. Then for the people who are getting referred, you have their entire funnel too. You have the percent of them that are clicking on the link, the percent of them that are signing up after they click, the percent of them that are ordering after they click, the percent of them that are going on to make a subsequent order after they click. So the good and bad, you know, the bad news is that it's a very painfully long funnel. Tricky to diagnose any given week why we were growing or not growing. The plus side is that when you have an 8 to 10 step funnel, there is unlimited opportunity, right? There's always something that you can be doing to be driving up that funnel. And so there's just like a lot of experiments that we ran on, you know, anywhere from the onboarding flow, where's the brand getting introduced to the referral, how are we pitching it at any given time, at what point do we bring on salespeople, for which accounts does it even make sense to bring on a salesperson, all these questions. Then you have a ton of iteration on the retailer side as well. What does the landing page look like? The signup form, all these things. And then the incentive. The incentive is a huge one I shouldn't overlook.

Yeah, no, I love this. And I love this really early process of focusing on what works. Like you mentioned, this non-zero early positive signals, being super scrappy. Love it. So Olivia, I would love to take a step back and talk a little bit about the broader marketplace within where all of these referrals even take place. Right. Fare is a marketplace. There's supply and demand. I think what's really exciting for product folks or just founders, anyone who's working on marketplaces, is that they're super dynamic and there's a lot of expectation resetting often with supply side. So we'd love to hear about how you and your teams have navigated changing scope, changing team structure, even depending on how the marketplace itself has changed.

Yeah, yeah. So marketplaces are very dynamic. I think the The first question that you should answer for yourself if you're a marketplace is whether you are supply-driven or demand-driven. And this is the foundation of how you choose to resource and split resources in your team. I would actually say in early days of Fair, we leaned more towards focusing on the retailer side, on the buyer demand side, where the only product that existed was on the retailer side. And the majority of the time we were using was on making sure that our value props made sense, et cetera. At a certain point, we actually realized that we were much more supply constrained than we were demand constrained. And this was— it also did go hand in hand with the success of the referrals. But what we found was the number one reason retailers said they weren't ordering was because they couldn't find the supply they wanted. On top of that, you have this feature where the supply is referring retailers. So having more supply means both increased share of wallet and conversion as well as user acquisition. So at this point, we started shifting a lot more of our resources towards supply. towards the supply side. So again, this fundamental question of demand-driven, supply-driven. Lenny Rachinski wrote a really, really good article on this on marketplaces that I would recommend any marketplace founder to read, and I've reread it several times, but most are actually supply-driven. And so that's your starting point. From there onward, of course, there's always changes in a startup. I don't think this is specific to marketplaces. I think all startups need to be very dynamic. with how they allocate resources. And this is just a matter of expectation setting with your employees. I think it's important to have— like, Fair has a value called Embrace the Adventure, and I do actually think values matter in terms of how you set expectations with employees. But for us, there's a way of framing it that's, oh, we're very volatile, and then there's a way of framing it that's, oh, we're actually very scrappy and flexible. And don't you want to work at a place that is always trying to work at the optimal resource allocation versus one that stays in an old org structure just because, you know, people's feelings, right? Like, I think it's important that you're framing and selling these changes. And change management is something that I would say I underestimated early when I was a manager and an employee. And it's something that I've really grown to appreciate just how important it is to execute on change management appropriately. People's emotions really do matter. The difference between a motivated employee and a demotivated employee, it can be massive, right? And so, You need to communicate well, but I tend to find that people respond well, it's just when you're honest and transparent with them. They want to feel bought in and included in decision-making. And as long as you do that, you can make a lot of work changes very quickly. My role changed a million times in my first 2 years at FAIR, but it was just part of it.

Love that FAIR itself has this, I think you mentioned it, embrace the adventure. Is that correct?

Yeah, exactly. It's one of our values.

That's fantastic. I might start using that myself. But yeah, as you started building out the team and you have these processes, You have rituals, meetings, and things like that. Are there specific— actually, the word ritual I'm borrowing from Shreyas Doshi. He uses it a lot for like, hey, what product rituals can you put in place to make sure that your team is running smoothly? Any best practices you've seen during your time at FAIR that other product teams can start implementing?

Well, the word ritual is hard for me because we change so frequently at FAIR. So again, when it comes to expectation settings, people should understand that that a ritual that works when you're 5 employees absolutely does not work at 15, does not work at 50, does not work at 200, does not work at 500. And so, Fair has gone through a pretty constant rate of change, both in terms of the state of our business as well as the processes we use. The universal things that you— there are a set of universal things you need to solve for with your rituals that do stay the same. It's just that the way you go about them changes, right? I would actually start out with number one is team bonding. And it's one that people frequently overlook. Every single one of my recurring meetings, both as a PM talking to my engineers and designers, as well as within other PMs, it starts with an icebreaker. So that's the first thing. The second thing is context sharing. So what has happened in the business or in the industry that changes or could change the way we do things? So you're always giving people a preview. of if things might change, this is why. And the third thing is about accountability. And I think this goes two ways. So accountability, for example, if I take me to my team when I was an ICPM, I would always show metrics because this is essentially my accountability to my team. I'm promising my team, I will lead you to hit these goals. So if I'm behind goal, I will always explain to you why we're behind goal. If we're over goal, I will explain to you why as well, right? And that was my accountability to my team. And then we'd reverse it. What is your accountability to me? Your accountability to me is that you promised to deliver a certain set of tasks by the end of this week or the end of next week, and now you need to tell me whether you are or aren't on track and why. And so these are kind of the global things that are, you know, one, icebreaking or, you know, team bonding, 2, context, 3, accountability, that all of your meetings and processes should be accounting for. Again, just the method will change as you scale and the number of meetings will increase as you scale.

Love that. This is a team I think I would love to work on as well, Olivia. So it seems like Created this great space for vulnerability and openness. Sounds fantastic. Any specific product principles that your teams operate on? And product principles are broad, right? They could be product principles about how you run strategy, or it might even be about process again. But yeah, if there are any that come to top of mind.

So I will say that a question that, or a principle people frequently debate, is this one of speed versus quality. Heard this in several forums for PMs. And it did come up on my team. So there's this question of, okay, where do you land? Do you work faster, lower quality, or do you work slower, higher quality? And this drives a lot of product culture where you decide to land. I actually told my team, I reject this question. I don't like this question. I don't think it's a question of quality versus speed. I started out with the premise that speed matters a lot. Every single day or week that you can shave off of a product launch actually just compounds exponentially in terms of your You're learning. If you can launch a day earlier, that's an extra day for me to cut the data and get back to you on what our next step should be. Try to cut that day. But what I reject is this principle of quality. I think there's actually a pretty sharp difference between product quality and product functionality. So, you can have a product that is high quality, but very, very low functionality. And an example I might give you is a calculator. You can have a calculator that can only do the basics, add, subtract, divide, et cetera.

Yeah.

Or you can have a graphing calculator that can do a whole lot more. But either way, even if you're launching what I call the functionality-light version, it should be high quality. The design should be nice. It should have very intuitive click patterns. It should solve what you decided that it should solve for users in an elegant way. Conversely, and I think that a lot of people, when they're under the gun or they're trying to launch fast, they actually try to go for fuller functionality, but quality light. And I think this is absolutely the wrong strategy. And so if there's a principle I would espouse, it's leave your users wanting more, not less, right? Give them low functionality, high quality, and say, this will only solve use case A for you. And I know you want use case B, but use it for use case A first, tell me how you like it. And then if you like it, I promise you in the next 2 weeks, I'll build you use case B. But do not launch use case A and B together and then have them look at it and be like, I don't like this at all. It didn't meet my expectations of quality. And then suddenly they want less of your product. They just don't want anything to do with it. You've just churned a user. So that's a principle that I hold pretty strongly as a PM.

Love that. Yeah, I mean, sometimes you can end up shooting yourself in the foot by trying to ship something that's not even high value, and it's also not even high quality, by trying to do it too fast with high speed. Love that principle. So yeah, I would love to shift gears a little bit here, Olivia, maybe going a little bit deeper.

Sure.

I know we've been broad on the process front and on the structure front. So knowing a little bit about your work, you've developed a 5-year strategy at Thayer doing this mapping of a value chain as well as mapping out all the different integrations that are necessary with the work that you do there. We'd just love to hear a little bit about the work that you've done there and some of the challenges of why integrations are so hard, and maybe for teams that are just starting How they can get ahead of this challenge of integrations?

Let me start with what a value chain is and why it's important to build one. The way I conceptualize a value chain, I will say it's generally probably more useful for a B2B company than a B2C business. But this concept of a value chain, it actually starts with this framework of jobs to be done. And so, I don't know here who's familiar with this framework of jobs to be done, but the idea is when you're building a product, your customers all have jobs they need to get done, and they're hiring different products for these different jobs. Your goal as a product is to get hired for any given job or set of jobs by your customer, so they will pay you to do that job for them. And so, to me, what a value chain is, is basically just mapping out all the jobs to be done that your customer has to do in order to, you know, have their end product. And so let's take a brand at fair. They have to create products and sell them, right? So the value chain or jobs to be done that they have to go through, it starts actually with product ideation. You know, what should I— what should I create? Then how do I manufacture it? Then how do I store it? How do I market it? How do I sell it? How do I collect money? How do I ship it? How do I account for it in my accounting system? How do I do customer service? It's actually a pretty long value chain of like 9 or 10 jobs. And what was pretty interesting is they're actually hiring different services very frequently for these different parts of the value chain. And the reason why mapping out this value chain is an incredibly important exercise is that it tells you, okay, what is the realm of jobs to be done that I could be solving for my customers? And I took all these jobs and I mapped them out against, okay, Okay, here are all the jobs. Here's how much of a pain point it is for our customers, guesstimating on a scale of 1 to 10 based on customer interviews. Then I would say, here's who they're hiring today for that job. And so, for accounting, a lot of them are using QuickBooks. And then for order intake, a lot of them are actually doing pen and paper. That's the tool that they hired to do that job. And then from there, I wrote down how well-positioned is FAIR there to essentially take over this job to be done and how valuable is it to us? And so once you identify essentially the segment, the job that you want to focus on for a given year or set of years, right? So yeah, I've written 1-year, 5-year strategies, so it just changes the scope of what you're looking at. In a given year, you're probably only tackling 1 or 2 of these jobs to be done. In a 5-year, I was actually looking at the entire chain and trying to prioritize which order we should go after them and why. But here, you're trying to decide, okay, I want to tackle this segment, You actually even have different ways you could tackle it. I would say I can bucket it into 3. You either build, number one, you can build your own product. So, you're directly competing with the other people who are already hired for this job. The second thing that you can do is that you can integrate with an existing player who is already doing that job. And the value you're now bringing to the customer is saving time in the continuation of their processes. But you're not actually getting hired for that. You're just integrating with a person who already was hired for that. The third thing is that you can acquire the people who are already doing this job. So you have 3 choices, build, integrate, or acquire. And to decide which one you're doing is actually a very non-trivial exercise. It's kind of more your classic, I would say, ROI though, of what is the expected value if I build myself versus the cost of building for myself, or similarly integrating or acquiring. Generally speaking, building is more expensive. That's not always true. Actually, some people get a little bit too build-happy when it's easier to integrate, but that's the first thing. The easiest is usually to evaluate cost. Then you have this key question of value. Do you get any value for building it yourself versus just integrating? There are a lot of times where building yourself is more valuable because you get data from customers. that your partner definitely wouldn't share with you. Or maybe if you don't build, you're actually creating a vulnerable flank for a competitor to come in and take share of your other jobs to be done that you already have nailed. And so there's kind of an art and a science to this of trying to determine which one you do. So that's kind of the whole, just a long-winded way to talk about the value chain.

I want to segue back into How you thought about growth as the company has grown. How do you think about the transition between being the first product manager or being an early product manager and then growing as a leader of other product managers?

It was an interesting transition for me. I think it's not specific to being a PM. I think this is true of any IC to management shift. You have to understand that your role is completely different and that adjustment actually takes, I think, most people a minimum of 3 months, if not closer to 6 to 12 months to understand and feel comfortable with. And so, again, generally as an IC, you are doing great if your personal work is great. The actions that you take to ensure your personal work is great usually involves grinding and just working really, really hard at one thing. And the only person whose output you have to worry about is yourself, generally. It's a little bit different with PMs where you have to manage a team, but still, it's a It's a different flavor. As the org scales, then you need to start scaling. And this is something that I actually worked with a really amazing executive coach. Her name is Shefali. She taught me a lot, really influential in my career. So she warned me very early on. She said, you have the characteristics of someone who, to be honest, might not be able to scale. And I just want to tell you pretty early so that you can get ahead of that and understand how you need to change, why the behaviors that made you successful as an IC are not the behaviors that will make you successful as a manager, and let's get ahead of that and plan for that. And so, as a manager, for people who've read High Output Management by Andy Grove, your output as a manager is the output of your organization. It's not at all about you anymore. And so, the difference of ensuring your work is good versus someone else's work is good, and on top of that, that they're motivated and feel like they're receiving credit and due respect for that work, work, it's not even close to the same mechanism. The fact that you are good at your job informs how you can evaluate their work. It doesn't inform how you get them to change their work or improve their work. There are a lot of books you can read about management. I would just advise people who are going through this transition to take it very seriously. It's very easy to trivialize it of, I was a good IC, therefore I'll be a good manager, or I deserve this because I was such a good IC. And to recognize that you're actually just learning a different role altogether and that you're starting from zero again. And so, people should be reading, they should be getting mentors, and they should be understanding that this is just a new skill set and that you will be bad at it, definitely bad at it when you first start.

Olivia, yeah, this is, I think, one of those age-old questions for a lot of employees, But I think a lot for PMs especially, because there aren't that many opportunities often to go from IC to management. And when you do, as you said, you're like, kind of be ready for you to not be good at it, right?

Right.

Any techniques that you can share to manage that expectation that you won't be good? And how did you get past that stage and then get into your first year of thinking, okay, I'm a good manager now and I'm a high-output performance manager?

Yeah, yeah. There's a kind of a mix of confidence and humility you need to have to strike the balance here. And so when you are a manager, this is universal, one of the key things is establishing trust with the people who work for you and ensuring that— okay, let me peel back a little bit actually. I think the number one most important thing is that you have good people. And that's also your job as a manager is to hire or have the right people in the org move onto So first, you need to have good talent. That's actually number one. When you have good talent, less of your job turns into actually managing the work because they're all smart, they're all great at their jobs, and it actually turns more into ensuring motivation and helping them grow. Usually growth is actually the way you motivate people, especially if they're the right kind of people. So let me start. It starts with having the right people. Your job as a manager as well. Second thing is ensuring that you're motivating these people by helping them grow. grow. A lot of this motivation and growth needs to come from a foundation of trust. And so in order to establish trust, especially the majority of the people that I managed were older than me, and so that was something that was quite difficult when I started managing. And you have to understand that no one's thrilled about the idea of someone younger than them, or even the same age, or even maybe 1 or 2 years older than them managing them. Just no one likes it. Ego is already in the equation and you're already fighting an uphill battle in this kind of scenario. And so to establish trust, there were 3 things, I would say, 3 things that you need to do very quickly. The first is to make it clear why you are their manager. You are a manager, you need to have self-confidence. You are their manager for a reason. That reason, by the way, does not necessarily have to be that you're a good manager. The reason can be that you were a great IC, that you are an organizational wizard who can navigate all kinds of conflict. It can be that you have unparalleled context on the customer, but there is a reason you deserve to be their manager, and you need to establish that reason very quickly. And people respond when you talk or speak with that kind of authority. The second thing you need to do is to show them quickly why it is in their best interest for you to be and to continue to be their manager. So, okay, you bring this value to the table, again, just being good at talking to customers doesn't mean that you're helping your— you're bringing value to your team who reports to you. So, you need to show how you're gonna bring value to them. You need to promote their work. You need to give them opportunities or, like, you know, show them how your input made their work better, all these kinds of things. And I would say one trap I have seen managers fall into is thinking that the way to grow as a manager is by kind of accumulating credit from their team. I actually think it's the opposite. Managers always, by default, get credit for everything that people on their team do. And so you should actually be doing the reverse. You should be fighting that trend. You should be saying, it wasn't me, it was my team. And when you do that, they immediately grow to like and respect you more because they see very visibly what you are doing for them in the org. You're helping promote them, you're helping push them up, give them visibility, and then suddenly you're adding value to their lives in a very direct way, and they want to keep working for you. you. And then the third thing I would say is that when you are working for people who are— sorry, when people are working for you, and they might be looking for your flaws and looking for reasons why not to like you, you should just be really clear about what you're not good at, right? And so, when I first started managing, I was very direct with people. I'm a great IC, I'm not a great manager yet. This is why I need your help. This is where you need to teach me, and I deeply appreciate your feedback. And I would tell them, I'm not the most organized person. When I communicate, it can sometimes come off scattered. If you need me to structure my instructions better, just give me direct feedback. So again, I would try to preempt kind of the search for flaws by telling them what I already knew, inviting them to tell me if there's any new information I need, while also establishing, hey, this is where I'm good at and this is where I will give you leverage, so don't underutilize Yeah, and Olivia, have you noticed with, you know, so much has changed in the past, you know, past year and a half, 2 years.

When you talk about something like advocating on behalf of your team, making sure that their work is visible, how much of that has changed now that, you know, you don't have— there's certain forums that don't exist anymore, right, that used to exist in person, or certain channels that may be fully remote now. Yeah, how have those things changed for you and your team? Any big changes, anything that's remained consistent?

Yeah, it's a good question. I would say that things changed less than I would've expected. One reason was that Faro already was a partially remote company. So our engineering team's in Canada, a lot of our customer support team is in Utah. We've just opened offices globally. So we are already accustomed to working remote. So the shift to full remote wasn't as jarring as it might have been for other companies. I would say that with remote actually comes— there are some severe disadvantages, mostly in how you communicate and bond with people. But there are also some advantages in the equalization, essentially, of credit, where it no longer is all about who's talking the loudest in a room. A lot of your communication becomes written, more formalized. It actually takes more time to manage and do all of these things, but then once you have them, them in this written form, I would actually say that it's easier to attribute and evaluate credit and work more objectively than it can be in a lot of non-virtual environments.

Just to continue on this thread, this idea of being a leader, like you've just walked us through this step by step, not only your journey, but in a more principled approach, you've made it, let's say, right? Let's say you have this fantastic team, new set of challenges, like managing across, managing Being part of the hiring process for even more senior leadership, do you have any best practices to share once you get to that leadership level, how you effectively manage across with other leaders and effectively manage up?

The key is structured communication. People just want to know what is going on and why you are making the decisions that you're making. And you— I do think it's very important. Some people actually recommend that you make In the same way you can make an ecosystem map for a user, that you make an ecosystem map for the org. You kind of draw out, here are all the nodes, here are the people that make decisions, here are the people that have or want input. And in consulting, we would frequently use these decision-making frameworks, like RACI is one of them. But you're saying, who's a decision-maker here? Who's a recommender? Who's an aggreer or someone who can veto? You need to understand all of those dynamics in an org because it tells you the pattern of how and when you should communicate to different people. And so it's really, really important when you're working across and up that you're giving people the right information at the right time at the right level of depth. It is very bespoke per organization. And this is the advantage that personally I had as someone who worked at FAIR for 5 years. I've been there from the beginning. I've seen how these systems have evolved over time, and I do have trust of a lot of people that I've worked with. So if I make a mistake, it's less damaging. But it is also that I paid very close attention. If I see someone's face light If I have somebody up in a meeting and I know that they want to be part of something, I'll make sure to send them a draft before I've submitted it to the CEO. And I think it's really important that people are aware that these things matter and that they're actually really important. I think sometimes when you're younger, I certainly had a moment like this where you think, all of this is just political BS. I don't want to deal with this. It wastes time. You have to change your mindset. You have to understand that every person has important input. To offer to you and that your work will be better and that your goal is to get the best work. On top of that, even if you disagree with their input, if there's someone that are critical to the execution, then it's not your best work if you didn't submit it to them because then your execution won't go as flawlessly as you want. So it's changing your mindset around it and really doing it in a pretty systematic way. A very, very simple hack for this is just writing it down. You'd be surprised. For example, one thing that we started doing is just on a PRD or a product doc or a strategy doc, just writing down who's the author and who are the people who need to see it, who are the approvers, starting your doc by having that written to ensure that you never miss a step. That was pretty big. Another thing that I did that was pretty game-changing for me and my team, and I recommend that everyone on my team did it, for any Anything really major, anything where you have to change someone's mind on something important. So, this would happen with strategy docs. If I'm recommending we just move in a different direction altogether, you have to understand that none of these decisions are made in a 1-hour meeting, none of them. People need time to understand the data, to think through the data on their own, to come back. And so, for these really large decisions, I would actually have people map out what is your 4-week decision-making process. And the 4 weeks starts when your strategy doc was done, you finished writing your strategy doc. Then there's the 4 weeks of how you change people's hearts and minds about the subject. And so then I'd have people actually schedule out all of the meetings that you need to do in that 4 weeks. Who are the participants? What is the agenda per meeting? And what is the feedback you hope to get? And that's a really useful exercise in helping people understand, again, this motion of— of working through an org, because to scale, it's all done via an org. It's never done with one person.

Yeah, I love that, Olivia. It's this whole competency of influence becomes so important as you start doing that. And so, given that you're in this leadership position, and Fair is doing phenomenally well right now, when you think about the future of Fair, y'all are in this very specific position as a marketplace, but wholesale marketplace, and a It's somewhat of a fairly new idea, but in this broader competitive landscape of marketplace product, where do you see Fare going in the next 5 to 10 years? Where would you, as one of the heads of product, like to drive the direction of Fare? What's your grand vision?

So I think to clarify, I actually don't work for Fare anymore.

Oh, okay.

I've since left Fare. Yeah. Thank you. Very dear to my heart, and I have total faith in the people who are still there to drive it forward. When we think about broader company strategy or growth, there are— I categorize everything into 3 primary vectors of growth. And so, FAIR, at least as of a year ago, it's already changing, used to be a US-based wholesale marketplace. And the primary thing that we're doing is just facilitating transactions between brands and retailers. Again, usually mostly in this gift space. It's kind of a broad space of like, but you walk into a gift store, what are all the things you could buy in a gift store? Those are the products we sold. So how do you grow beyond this? And the 3 ways, first is geographical expansion. So we're expanding into Europe with plans to go beyond that, obviously. So that one's pretty straightforward, geographical expansion. Second one is category expansion. The first The first big one that we're going after is apparel. And then there are, again, many, many kind of infinite categories after that that you can go after. The third one I call platformization. So instead of kind of going into new types of goods sold, it's actually new kinds of services that you can offer our brands or our retailers that make them really, really sticky. And these are to drive closer to 100% share of wallet. So an example of platformization could be Do we help our brands create— do we create a marketing tool, a best-in-class CRM for our brands to help them manage their customers? For our retailers, where do we want to play in this point-of-sale space? How do we want to make sure that all of their data entry is seamless, knowing that it's a really big pain point for them? And then how might we help them sell directly to consumers? So these are services that we're adding that make it so that they want to do 100% of all of their jobs to be done on FAIR. And so that's this platformization concept. So those are the 3 vectors of growth. As a brand supply person, obviously the one that I was focused on was platformization for brands. So I feel very passionately about that. I'm kind of like a tool nerd. I'm like a UX. I love B2B tooling and I love elegant tooling. And so I was always really bullish on these ideas of CRM. Under my watch, we launched FAIR's first CRM for brands. It was very successful. First marketing tools for brands. And I'm excited to see the company continue to push forward in that direction.

Gearing towards closing here, one thing that we just launched is a program that helps consultants transition into tech and get their first tech jobs. Or maybe it's VC, maybe it's startups, et cetera, maybe to start their own company. What advice do you have for people who have a similar consulting background and are thinking about or curious about getting into tech?

I think consulting is a great background to come from because it teaches you kind of the basic toolkit of how to do analytics, how you run a survey, all of these things. It also has very large gaps. The primary gap is that you were never accountable for a result as a consultant. So, my first advice to people is to just go work for someone where you are on the hook, where you're operationally responsible for a result because it completely changes your frame of mind when you're approaching a problem when you have to do both the strategy and the execution. I've seen a lot of successful consultant transitions during my time at FAIR. I've also seen some that were less successful because people can't bridge that gap between the strategy and execution.

Totally. That's a helpful construct. Well, I want to be mindful of your time. You've given a lot of helpful advice for product managers and founders out there building. building product organizations. Thanks so much for coming on the podcast, Olivia.

Really appreciate your time too, Erik and Andrew. Awesome.

Thanks for listening to today's episode. Execs is produced by On Deck, where top talent goes to start companies, find their next roles, or invest in their careers. If you're looking to start a company, uplevel your career, or navigate a career transition, I encourage you to visit beyonddeck.com. See you next time.