The Product-Led Growth Playbook for the Enterprise with Annie Pearl, CPO, Calendly

There's actually three flavors, function channel and then user acquisition. And I think the best product led companies have a combination of all three. They have a very product led culture. They oftentimes have a channel where someone can come and try the product for free before they decide to buy or upgrade. And then also the natural usage of the product promotes more users to come into the product. And it's this self enforcing flywheel which ultimately means a very very economically great business in terms of unit economics and a low acquisition cost. You you don't necessarily have to spend as much on your sales team. A very good business to be in.

I need some traction. You need some traction. Let's get some traction.

Hey what's up innovators, entrepreneurs, visionaries and disruptors. This is your Traction Podcast host Lloyd Lobo. We're a community of over 100,000 people just like yourself, on a mission to help you get the methods, the money and the madness to explode your business growth. Featuring stories and tactical advice straight from those who've done it before, like Shopify, Twilio, Asana, and many more, this episode is brought to you by Boast AI. Each year the US And Canadian governments give out billions of dollars in R and D tax credits and innovation incentives to fund businesses like yours. But the application process is cumbersome, prone to frustrating audits, and receiving the money can take up to 16 months. Boast AI gets you access to research and development tax credits and innovation funding opportunities without the headache and red tape. Join thousands of North American companies leveraging Boast AI software to maximize cashback. Check out B Oast AI. This episode is also brought to you by Launch Academy, an international tech hub that provides mentorship, resources, network and the environment for entrepreneurs to launch, fund and grow their startups. Since 2012, Launch Academy has incubated over 6,000 entrepreneurs, of which 300 have grown their startups past Seed and Series A and have collectively raised over $1.2 billion in funding. To learn more about Launch Academy's programs, check out LaunchAcademy CA. Special thanks to our Podcast partner Content Allies From Podcast Production and promotion, content allies helps B2B companies build revenue generating podcast. We recommend them to any B2B company that's looking to launch or streamline their podcast production. Learn more@contentallies.com Today, more and more enterprises.

And companies are putting their employees in the driver's seat to pick the right tools for their companies. Product leaders now need to balance like do I design for the end user or do I build an enterprise grade solution to convince the purchaser. And today's wonderful speaker here, Annie Pearl, Calendly's Chief Product Officer is going to share insights on how to build and drive product led growth for the enterprise by obsessing over end user value and solving your customers problems. I think the whole plg, I don't know who came up with the whole PNG terminology. I would like to give some credit to openview who's also Calendly's investor. They did a lot of branding around this but back in the day I think it was called consumerization of it and more and more people were buying it. But PLG sounds just way better. Adi, you've had a super successful career. You've been the Chief Product Officer at Glassdoor as well as Director of Product Management through the IPO of Box. Walk us through your career and what made you take this job at Calendly.

Yeah, first of all, thank you so much for having me here today. Really excited to be here and I love seeing folks coming in from all over the world. This is the beauty of us being able to do these things remotely these days. Yeah, thank you for having me. My career actually started off I was intending to be a lawyer. So I went to law school right after college and while I was in law school I actually worked for a management consulting firm and we specialized in working with startups and typically startups going through times of rapid growth. So I was in law school but I found myself spending more of my time with startups getting much more interested in, you know, technology and the power of technology. And so after law school I joined the founding team of a startup. This was back in 2009. We were trying to create a stock market for private companies. So trying to create an actual liquid exchange of pre IPO shares. Today obviously there's a lot of ways you can get secondary liquidity and ways for companies to raise capital online. Back then there really wasn't and so a really hard problem space, very highly regulated and yeah, we, we hired, we raised venture capital, we hired a bunch of engineers and I took the role leading product and design at Expert Financial. So spent four years there. That's really where I started my career in product management and very much focused on zero to one how do you get a product off the ground? How do you try and find product market fit? How do you get to that first set of customers that are using your product? And really that's how I kind of got into product as a field after expert. I went to Box as you mentioned and I joined Box at a different phase of a company's growth. So we had product market fit and it was much more about scale and how do we really go up into the enterprise. And Aaron had identified at the time that the strategy for Box was going to be to go capture as much of the enterprise as possible. And so I spent time on the enterprise product management team, both helping to build features and functionality that would unlock our ability to sell to larger and larger customers. But through that process also had the opportunity to talk to a lot of customers and identify that Box put ourselves into this category of enterprise file sync and share. But really we were competing against on premise legacy enterprise content management systems and that was a massive $50 billion TAM. And so I pitched to Aaron, let's actually go after this larger TAM and let's start to build new and adjacent products to the core Box product to allow us to go upmarket and actually you know, have customers rip and replace their on premise ECM systems with Box and was fortunate enough to build our first kind of add on SKU which was a governance product, then built another product which was a workflow product that became its own business unit. So really two things at Box for me were both moving up the enterprise and how do you preserve the end user, the end user sanctity of what makes your product great while you're scaling and supporting the needs of larger customers and then also an experience of more multi product portfolios and what does it take to go from one to many? Spent four years there. You mentioned we went through an ipo, got to a place where I felt like I learned an incredible amount and I really wanted to go back to a bit of an earlier stage company and kind of do it all over again. So I went to Glassdoor back in 2016, originally was brought on as our VP of B2B product. So spent some time leading the B2B portfolio there as part of that actually had the opportunity to go down market. So we were very much more of an enterprise company and we sold directly into employers with our sales team and we wanted to build more of a self service business. So learned a lot around how to go from enterprise down to self service through. Through that experience we got acquired by about one and a half for about one and a half billion dollars by recruit holdings back in 2018 I believe. And I got the opportunity to take over and lead all product and design. So yeah, spent the last couple of years as a CPO at Go Glassdoor and then made the jump to Calendly about a year Ago February of last year. And for me there are a couple reasons. One, the product right at the end of the day I'm a product leader and calendly as a product I was a huge fan. As a consumer we'll talk about virality today. But the magical moment when you open up your first calendly link and realize that scheduling back and forth 17 times via email to find a time to meet is not efficient. That magic really stuck with me as a consumer. So I loved the product. I loved where we were in our growth curve, late stage growth company. What got you here won't get you there and all the product problems and organizational challenges and opportunities that come with that. And then lastly the people tope as our CEO founder, incredibly inspirational and someone I knew I could partner well with in my role. So yeah, that's a little bit of my journey and what brought me to calendly.

What a fantastic journey and also contrast working SMB to enterprise. And then would you say Glassdoor is both consumer and business facing, Right. So going up market down market, a lot of experiences here. What were some key learnings from your previous roles or through your journey that helped you find success today? A lot of people want to go into product and it's fascinating to me that you started in law, right and then transitioned to product. What are some key learnings you would say for others wanting to go into product that help you find success today?

Each of the tours of duty I've done I think have taught me different things. I think at the startup, at Expert zero to one world I think we the highs and lows of any startup. But my learnings there were very much around the power of focus and the power of focus when you're in those early pre market, pre product market fit days of finding that product that's going to actually solve a real true need for users and doing things that don't scale. So I think for us we tried to do far too much, we tried to build far too many products before even just the first product really truly had achieved product market fit. So a lot of learnings around entrepreneurial endeavors to think through. How do I focus? How do you make sure you're really narrowly solving one problem, doing that incredibly well before you start to think about going and building new products. So that was expert moving to box that the move up in the enterprise. To me biggest learning there was how do you make sure that you're able to build the features and functionalities that will allow you to unlock larger and larger customers but never at the expense of the user experience. And so it's an art to be able to try and understand what the needs are of the buyer and then not do exactly necessarily what they think they want, solve their problem, but do it in a way that's not going to negatively impact the end user experience. And I think in the early days it was easy to say okay, they want X, Y or Z, I'm going to go build X, Y or Z. So learning the craft of how do I ask so many questions of why to get to what's the actual problem you're trying to solve so we can go solve it in a way that's not going to negatively impact the end user experience. So that was a big learning for me at Vox Glassdoor moving down market and you mentioned consumer. Yeah, Glassdoor is about 60, 70 million unique users use the platform every month. It's really a marketplace business. But on the B2B side we went from selling mostly through a direct sales channel and built up a self service business. And I think the big learning there for me was around rules of engagement. Right. As you if you have a sales led model and an enterprise sales team and then all of a sudden you introduce a self service channel, often there's conflicts between how do you think about those leads that are coming in through the self service channel? Is there cannibalization of your business smaller down in the SMB VSB space And Calendly we're actually going through the other journ which was we started with this PLG self service business and we're adding on more of an enterprise sales motion. And so thinking early on, how do we think about things like rules of engagement and what's the pass off between the self service business into your direct sales channel and how do you create a really great customer experience through that transition? Yeah, at each stop different learnings that I think have added up to at least how I'm approaching my role today.

And that advice is going to be invaluable to the audience here today. So effectively Calendly, I would say is the poster child for plg. Right. And if you look at it, I was looking at the Bessemer Cloud index. The most valuable companies of the last decade from Box to Dropbox to Calendly, et cetera, have been product led companies. What are the key traits for success in product led growth?

The term PLG or product led growth, I think it actually is, there's three flavors of it. I think one is really focused around the function of product. Right. Is this A company where you think about something like Google, very engineering led, right. You think about companies like Oracle very sales led. There's a function of product leading and I think in that world there's really a tight collaboration between the R and D Org and the go to market teams and product is really dictating the roadmap, the product vision, the product strategy. And there's tight collaboration between the product team or the r&d org and all the go to market teams. I think that's distinct from a sales led organization where product is often the afterthought. Maybe there's little collaboration between R and D and the rest of the company. Oftentimes you're closing deals because you're promising a feature to a large customer. And so you're always, you're reactive versus being proactive. So I think one model as we talk about product led companies is to think about the actual function of product. A second model I think is much more around kind of channel, right? And that's do you have a channel where someone can come and sign up for your product, experience the product and get value out of it without ever necessarily talking to a sales rep? And that dictates that's different than necessarily just product led in terms of the function. And then lastly I think is more of the user acquisition which is another flavor where the product itself, when people are using the product, they actually naturally are adding more users to the product by just using the product itself. And calendly is a great example of that. Anyone who shares a calendly link, they get exposed to calendly. They oftentimes sign up and then they become a user of calendly because they've experienced the value out of it through the virality of the product. There's actually three kind of flavors, function kind of channel and then user acquisition. And I think the best kind of product led companies have a combination really of all three, right. They have a very product led culture. They oftentimes have a channel where someone can come and try the product for free before they decide to buy or upgrade. And then also the natural usage of the product promotes more users to come into the product. And it's sort of this force and this self enforcing flywheel which ultimately means very economically great business in terms of unit economics. And you have a low acquisition cost, you don't necessarily have to spend as much on your sales team. And so it's a very good business to be.

Now I want to get into how do you engineer virality if your product is not inherently Viral, Right. Calendly is inherently viral because you share it with two people, you interface with it and then you sign up was, I think box in many ways is also inherently viral. Right.

The sharing mechanism. Right. If I'm going to share a document with you, whether you're in my organization, whether you're outside of my organization, and then you interact with the product, you get value out of it, and then you go and sign up. So it has that, like the sharing mechanism is a natural virus virality component to Box or Dropbox.

Have you come across companies or in your experience seen where products that are not inherently viral in terms of their sharing mechanism have engineered virality and how should people think about it?

Yeah, I think it's zooming out a little bit. Thinking about virality. I think there's probably two kind of types, right? I think one is this exposure virality that we're talking about. Calendly is a good example. Loom's a good example. Dropbox, right? Where as someone is using your product, they're exposing the product to someone else who finds it valuable and then signs up. I think there's another type which is invites and referrals. And this is where customers, you're often rewarding customers for bringing other users into the product. And so when you think about virality, I actually think it's most important to go back to the drawing board of what are you really trying to solve for. And usually virality is you're trying to solve for an acquisition problem, right? You want to lower your cost of acquisition or try and eliminate the cost of acquisition. So I think going back to once you understand what I'm trying to solve for, then you can figure out is virality. What I'm trying to. Is virality one way to solve that problem? And then I think you have to get really honest with yourself of is this a product that inherently has the ability to even be viral? Right. You think about like a marketing analytics product, for example. Like, I can work on it by myself, use the product by myself. There's no need to have other users in there with me. There's no reason for me to invite others into the app or even really share it. And so I think you have to get honest with yourself of around, is this a product that actually could become viral? And then if you think that you could, then you go through the exercise of, okay, can I add in things messaging into this sharing mechanism so that the person who receives the invite or the document or the loom video knows that it's powered by that company and then they're exposed to the product. Or if you're thinking about invites and referrals, how can you create incentives for users within the product to refer friends or refer colleagues into the product to make their experience better? So I think you have to get really honest with yourself around the type of product it is and that not every product has the ability to become viral. And then. But if to have virality in it. But if it does, then I think you can do a breakdown of Is this more of invites and referral flavor? Is this more around exposure virality and then invest in the product features and functionality to do that.

You said something very important. Virality doesn't necessarily mean activating your customers to refer. Right? That is, it could be the same and blow up. But companies that are not inherently viral or have the ability to go viral can also still ask their customers or users to share with others when they experience certain moments of wow in the product. But the worst thing is having a product that sucks and then you have some viral mechanism. So I ran a company called Speakeasy. It was a calling app for salespeople and you got tens of thousands of people, but those people kept churning out more people would eventually end up selling the company. If you don't think about good onboarding and good ways for people to have engagement and stay and retention, I think the virality is going to flop no matter how viral it is. But I want to come back to the PLG thing, right? When we think about plg, everyone thinks about SMB self service premium. But if a company has a predominantly enterprise sales motion, how do they adapt? You talked a little bit about this at Glassdoor because there's a bunch of cultural things you gotta overcome, but then you have a bunch of product things to overcome as well. How do you adapt?

Probably go back to what type of product LED change are we talking about? Right. Again, there's this cultural function bucket, then there's the channel channel bucket and then kind of acquisition. So I think I'd start with really understanding again as you as a company saying we got predominantly enterprise sales, how do we want to go and adapt? I think you have to go to what are we trying to accomplish? And so is there a need for a cultural change? Because product decisions are being made by just a few large customers and therefore your product, it's degrading the user experience because that's a different problem than the cost of sale is really high. And so we'd really benefit from allowing users to sign up for the product on their own before they buy? Or is this really a market marketing cost challenge? Right. Where the cost of acquisition is high and so we're trying to create a flywheel where we can bring users into the product when people are using the product and bring down our customer acquisition costs. So I think I'd again go back to that framework and say what is the actual problem we're trying to solve when we say we want to go from enterprise sales to a PLG motion and then I think depending on that, then you can adapt and figure out what the plan is for how you'll do it. So if it's a cultural change, I think that really starts at the top with the executive team and getting alignment that there's going to have to be a transformation. No longer will we do one off customer request to close deals that are then thrown over the fence to the, you know, R and D Org to go implement or whatever it may be. It's a cultural shift and it's a process shift. So that's one flavor, Right. I think the second is in the channel example. If you're saying we want to actually go invest and drive down our sales costs by investing in a self service channel, this is going to require you have to go build that channel. You have to make sure that the product, product itself is one that has really quick time to value. It's super simple and easy to use because you don't have a sales rep to help you with that sale. And it may require changes to your pricing and your packaging. As you think about how do you stratify what's a feature stratification model. So I think there's a lot of you have to go build the channel as well as think about things like pricing and packaging. If it's more on the channel expansion. And then lastly if this is in the acquisition bucket, this is what we just talked about. You have to go and figure out what type of virality or flywheel can we build into this product so we can acquire users for free or at a very little cost through the users that we have today. I think the tactics really come from first, starting with what are the problems we're really trying to solve for the business and then digging deeper into that to figure out what are all the things we need to go do in order to be able to build a.

Product led growth business transitioning from sales led to plg. How do you manage the sales team and expectations in implementing the strategy? And you may have found this at Vastor, right?

Yeah, I Think this was a little bit of what I was touching on at Glassdoor. We, there were times where it was really challenging because we had, we didn't create enough clarity at the highest level around the importance of a self serve business. This has been really in the early days and so this channel conflict of I used to be able to go sell into very small businesses and now the self service channel is acquiring those users. My book of business has now shrunk and what does that mean for me as a sales rep? So I think it starts a lot with the executive leadership level saying this is a really important initiative and here are the reasons why and making sure that's really known widely across the company. And then I think more tactical it's getting really crisp and clear between the sales leader and the product leader, building the self service product or whoever the players are, what that rules of engagement methodology is going to be. Where's the line between one where one stops and the other begins. And I think to wrap all of that together most importantly is what's the customer experience? And you have to get that right. And the worst customer experience is I come through the self service channel. There's no communication between them that to a sales rep who now thinks I'm a prospect and is emailing me and calling me. And so finding how do you really from the moment someone you know signs up for the product completely self service through they pass it off to some sales model. How do you make sure that customer experience is really pristine and the best that can possibly be?

Now you mentioned Flywheel a few times. Maybe for our audience benefit you could define what Flywheel means and how can you leverage that in a PLG environment?

Yeah, Glassdoor is actually a really good, great example of that. The idea of the Flywheel is when users do the main action within your product that acquires new users who then come in and do the main action of your product which then acquires more users. So for us at Glassdoor, when a user writes a review on a company, we then obviously index that and it shows up in Google search results. And so someone goes and searches for what's it like to work at Calendly and they find the most recent review, they click on the review, they go on the product and then we have a give to get model to get you to contribute content because that will then go get more, more users to come, you know, find us find the review through Google to get you into the product. So it's finding what are the ways to get users to contribute to the product in a way that's going to go acquire new users. And so for Calendly, that flywheel is the sharing of a calendly link. And so the more we get people to schedule meetings, the more they're exposing the product to other people who are then going to sign up for the product, come in, have more meetings, expose the product to more people. So that's a flywheel that reinforces itself. And those are just two examples of of it.

And I think canonly, you guys is probably one key metric in the early days and even now is number of meetings scheduled or is there something else?

Yeah, that's our North Star. It's both because it shows us user value. Right. If people are getting value out of the product, they're booking more and more of their meetings. And then also it is a huge piece of how we continue to grow the business, which is through the reinforcing nature of what that does to user acquisition.

For PLG companies, what is a good Aha moment activation ready successful companies having with free product?

Yeah, I don't know if there's necessarily a perfect like number or benchmark. I think really what I would suggest is getting down to what is the actual core value proposition your product delivers and how quickly can you deliver that value to a user? Like how early up in the funnel can you help them get and identify what that value is. So ideally, and Calumet is a good example, Loom's a good example. The aha moment actually comes before they've even signed up for your product. Right. The Aha moment comes when they interact with the product and they get incredible value out of it. So the first time you see a Loom video and you say, oh wow, I got to understand this person's PowerPoint presentation without actually having to meet with them. This is an asynchronous way I can have live video interaction. I'm going to sign up for this product or calendly. I didn't have to go back and forth through emails. Best case scenario, activation is happening not a even in your product, but before you even get to the product and people are finding the value. And then obviously for people who are coming in and signing up outside of that viral channel, there's direct people, right? People who come directly to calendly.com and sign up not necessarily through that loop. Then you want to figure out how do I quickly how do I ask for the least amount of information that's going to get them to time to value as quick as possible? And it's a very hard problem to solve. I think activation is one of the hardest problems to solve in the whole growth funnel. And again, so the higher up that you can get it done, the higher likelihood you're going to get more people through the funnel and then obviously get them to retain for longer and longer time periods.

A lot of questions here in the Q and A around is PLG only suitable for small customers? And this is a topic for today. How do you do PLG in the enterprise? Let's say a company has a predominantly enterprise sales motion, right? How should we think about features to carve out from the core product to facilitate PLG when you're an enterprise sales led product? Because enterprise products you're thinking top down selling to multiple buyers, complex, complex product, it's hard to turn that whole product into a product led bottoms up motion.

Yeah, it's a great point. I think there's a couple things to think, couple of things to think about. I think the first is where are you going to have product market fit with a self service audience? And so in the example of Glassdoor, we had a product portfolio we sold to companies, we sold job advertising, display advertising and employer branding products with three products. And we really looked and said okay, we would benefit from a self service service motion for lots of different reasons and it would benefit our customers for lots of different reasons. But things to think about are where is their real ease of use and ease of setup as well as quick time to value. So I think those were the operating principles. It's like how do you where is there which of our products have the easiest time for people to set it up and comprehend it as well as get to value quick as possible because you don't have a sales rep who's holding your hand through that process. And so for us that was job advertising, right? You can go online, you can post a job and immediately very simple and easy to post a job. It's very comprehendable and it's not hard to do. And then very quickly you can start to get applicants coming in, right? So quick time to value and ease of setup versus our employer branding product where it was a, it's more nuanced, a little bit more complex and the ROI and time to value had a lot longer of a time horizon. And so it made more sense for us not to try and you know, build some big self service business around the employer branding product that was much more of a product that made sense for sales, for more of a sales led conversation. But job advertising made a lot of Sense through our self service channel. So I think you have to really be honest with yourself and pick apart like ease of use, ease of comprehension in terms of someone signing up and then how long does it take for them to get value out of the product to figure out what is the right product within my portfolio to even think about self service motion around and then I think you as you're then you have that product and if it's a freemium type offering you have to start to think about how do I start to stratify the features and functionality. So we're giving some away for free. Some are one paid tier, others are for another paid tier. And then I start to think about things like how broad or how narrow is the audience for a specific feature. How much would you consider a feature? Table stakes versus value add. And also what role does a feature play in kind of the overall ecosystem. I'll give an example of this one. We recently launched a new product back in the end of last year called Polls which allows you to poll large groups of people to find time to meet and value added feature more complex in the use case you're trying to deal with a lot of people's different calendars. So so our hunch, original hunch was okay, we're going to put this into a higher tier but really when you think take a step back and look at the ecosystem. We just talked about this. Getting meetings booked is our North Star metric. It shows that like users are getting value out of the product and also it helps us acquire new users. And so thinking about that polling feature as something we give away for free in the free tier because of the value it has to driving virality into the ecosystem ultimately was part of the thinking around where we put it. So I think you have to again think not just about a specific feature and what plan you'll put it on, but does it impact the overall ecosystem of like how your product grows.

Then when you're thinking enterprise, right, and sometimes your product can just be sticky as a sheer function of being a must have but poor UX meaning I got all my data in there, I'm never going to migrate it and it's a pain kind of thing. But when you're thinking about how do I drive mass adoption from the bottom up in the enterprise you UX is a big factor. You can't just pull a feature and then just dump it out there in the ether. How should we think about user experience? What are some UX and design best practices to drive adoption usage and growth?

I Think one of the most important pieces, especially as a company grows, is to have this North Star maniacal focus on the end to end user experience and not let your org structure show up in the process product. So what I mean by that is oftentimes what happens is products start to scale. You create lots of different product teams and they live in lots of different parts of the product and they're focused on their little surface area and you start to move away from thinking about the end to end user experience and then that starts to show up in the product. Right. You can feel that this product manager over here in this part of the product didn't talk to the designer over here in this part of the product. So I think end to end user experience being at the forefront of how you think about product management and overall R and D development, really important. I think a second piece is sort of this notion of ongoing discovery being user centric. And user centricity is all about really deeply understanding the problems our users are facing and then really thinking about how can I build a solution to solve that problem. And so a culture around continuous discovery, creating enough time in product roadmaps and an expectation that there'll be proper discovery done and therefore you might ship fewer features, but the features you ship are going to really hit the mark and we're going to have incredible product market fit. I think that's the second piece and I think the last piece is again going back to product culture being very metrics oriented in terms of what are the goals that you're looking to accomplish with the specific feature and then actually measuring those after you've launched it, and measuring the adoption rate, measuring engagement with that feature, measuring how that feature correlates or drives retention over time. So I think from a culture perspective, creating one where we're holding sort of the teams accountable to those adoption, engagement and retention metrics as it relates to the products they're releasing versus just rewarding constant shipping of features. We want to make sure that the features we're shipping are actually providing user value, which you often can measure through things like adoption, engagement and retention.

You use the word discovery a few times and a lot of founders here, what does discovery mean? Maybe define it for us. And how do you do proper discovery? Because a lot of, lot of what follows stems from that.

It starts, I think even higher level than just discovery is just what's your overall product development process. We actually just went through a revamp of this at Calendly. I did a similar exercise at Glassdoor. I think companies Oftentimes when they hit a certain inflection point in size, what got you here won't get you there in terms of how you think about your development. Muscle and fun part about the exercise for us was we really approached it like we were building a product. We really, really had a cross functional team that was looking at the problem, that interviewed stakeholders across the whole R and D Org as well as across the company to really come up with the approach that was going to solve for the main pain points, which for us were consistency in the overall process as well as clarity around roles and responsibilities. So anyway, fun process, but back to your question. So the product development life cycle that we've came up with is starting really first with problem prioritization. Right. I think think we product managers and product teams often go right to features we're going to go build and skip the step of what are the actual problems we're trying to solve and how do these problems tie to our overall goals as a company? First phase is all about that prioritization of what, what problems are we even going to go after? Then it moves to discovery. Right. Now that I know, I'm going to go try and figure out why adoption is low within this certain part of the product or within a certain feature, then go to explore that problem space. That's a lot of user interviews, that's a lot of quantitative and qualitative research methodologies. Whether that's a big A survey, which is more quantitative in nature or qualitative. By actually going and talking to users, watching them use the product, really deeply understanding what within that problem, what is going on and then that will allow you to then go and ideate against what are different solutions to solve the problem. But I think most failed products actually are less about the solution being a bad solution and it's less and it's more that they haven't really truly understood what the problem was they were going to try to solve. So I think that discovery process is really all about asking why Till you have problem statements that you can then go and design solutions to and confidently know that you're going to create value for your users.

Could you elaborate on tips for measuring outcomes? How do you. What are some ways that you measure that this outcome is actually happening?

Yeah, I think it really depends on starts at the beginning of why are we even building feature X Or why are we doing activity Y? Y being the letter, not W, H, Y and C. So once you have a really clear what is your goal here? If your goal is to drive up you have a feature that's has low adoption, then your success criteria is going to be driving up adoption of that feature. If you have a feature and your hypothesis is that it's going to increase in our world meeting intensity or the number of meetings scheduled per user per month, then you're going to want to measure the number of meetings scheduled per user per month as it relates to that experiment. So I think you have to. It all starts with why am I even investing in this feature or this enhancement or this new product? What is the actual result that I'm trying to deliver? And and then figuring out what the right metric is to measure that. And it's often not just one metric, it's a North Star metric. And then oftentimes either counter metrics or things you're trying to not, you know, hurt in the product or they're secondary metrics as well. So yeah, I think it goes the metric itself is less important than it is going to. That hypothesis of why am I even doing this? What do I think I'm going to be able to accomplish? And then how will we measure that?

You talked about rip and replace of on premise products to cloud. The box examination example, what learnings did you have and how did it drive a PLG strategy?

I'll start with the learnings mentioned this a little bit before, but I think when you're trying to rip and replace a legacy solution, most of the time, I won't say all the time. Most of the time the features and functionalities that exist in that legacy solution are going to be far more than the ones that you're going to have in your product, especially on day one. And so you have to be able to figure out what is that differentiator as to why someone should move to your solution when you most likely have less features, fewer features and functionality, but you're going to win on something else. So in the box example, in the on premise solutions they were much more robust than the kind of basic syncing and sharing we had at Box. But we had ease of use in terms of user experience, the ability you could access it anywhere, anytime. We had mobile capabilities. We, we had a whole huge robust ecosystem. And so I think you have to get really crisp with yourself on customers are going to be giving something us most something up most likely when they move from an on premise solution to the cloud in this example or from a legacy product to your product. And so what are you going to be giving them to make up for that kind of feature functionality gap? I think that's the first piece and then the second would be even with the feature and functionality gap. I think you also have to be honest with yourself that you're never going to get to parity. And the goal shouldn't be necessarily to get to parity. It should be how do I actually solve the problems that the customer was using the old system for in a new way that's better. That may not be all the bells and whistles that used to be in the product, but actually solves the problem, the core problem, even better. So that's probably so tempting. I think when you're a startup and you're competing against legacy software to look at the long list of features they have. And so either that's daunting or I got to go do a checklist and an RFP checklist and build a bunch of features. But if you go back to what are the actual use cases and problems that customers are trying to solve with these, with the technology, how can we solve those same problems in a way that maybe isn't going to be all the bells and whistles, but solves it even better? So that's probably my biggest lesson. I'm not sure. I think the tie to PLG would probably just be just maniacal focus on the user, right? What is the user trying to accomplish? What is their use case? User centricity and really understanding. And again, it's the why allows you to create experiences that are simple and intuitive but yet are powerful because they actually solve the problem or they're in some way helping the user accomplish a task that they set out to accomplish. So I think the tie there is really just around that same exercise of how are we going to solve the problem a little bit differently in the box example with plg, it's how can we deliver delightful, simple, easy to use experiences to users in a way that's going to essentially solve their problems better than any other alternative out there.

Now to be a plg, a product led company company is freemium necessary? How should someone think about the strategy of building a freemium product? Is it necessary when do you need to have it and do you need to have it at all if you're a product led company?

I go back again to those three buckets, right? I think you could be a product led company because product is really driving decision making and is in the driver's seat when it comes to the product roadmap app versus that being more sales led. You could be have a freemium product offering where people are able to sign up online and experience a product for free and upgrade or you can have product led growth company or product that has virality in it. So I think it doesn't have any flavor of those. I don't think freemium is a requirement. I think you have to be again, really honest with yourself around what type of product is this? Not all products are going to benefit from a freemium offering. Really complex, complex products that require long implementation cycle actually could benefit from having sales and customer success involved from the very beginning of the first touch you have with the customer. So I don't think there's. It's not a bad thing to say that there's to evaluate your business and say, but because of the nature of our product, it actually doesn't make sense to try and sell this through an online channel. It doesn't make sense to have a freemium offering. However, that doesn't mean we still can't be product led from a culture perspective in terms of how we approach the way that we build product at this company. So yeah, I don't think freemium's required. And I think it's most important is understanding your business. And is that, is a freemium model actually something that would work or are you trying to put a, trying to force it even though in reality you need a sales rep and you need a customer support rep in order to help make your product successful from try through buy.

Try to buy is a good one. It doesn't necessarily have to be freemium. As long as you can get people to try and get deliver immediate value to them, the time to value has to be quick. Now you said you recently revamped the product development framework at Calendly. What does that look like and how do you prioritize features?

Talked a little bit about the kind of framework. Mostly it's this planning phase focused on problem prioritization, moving to discovery, really taking those problems, breaking those down, moving into design and ideating on what are different solutions to those problems. Problems moving into build, which there's obviously the execution of engineering, actually writing code to build something, but then also more iteratively launching it through a series of alpha beta into ga. Then there's launch, post launch assessment. We created these distinct phases, but really important, they're not distinct, they appear to be distinct, but there's a lot of looping. Right. If you're doing it well, this shouldn't be some long waterfall process. It should be we have a problem, we do something of discovery, we come up with what we think could be a solution, we go back to customers, we learn that solution is not going to work, we go back and try another solution just to learn that we didn't actually fully understand the problem and we're back in discovery. It's very iterative, in loops versus being discrete steps. So that's just the kind of process we went through. I think in terms of prioritization of new features, this tends to be something that is different across the team depending on who your customers are or what part of the product you work from. So on the enterprise side, the teams are often looking at more revenue generated metrics, thinking about how can I drive expansion, how can I drive upsells, how can I help our teams of users better work together? Whereas some of the more core team product managers on the core side are looking at how do I increase meeting scheduled, how do I increase activation of users as they're coming into the product? So we don't have one prioritization framework across the board. However, the thing we really encourage the team to do is always ask the questions of how does this feature support our long term vision and our product strategy? How does this feature support our goals this year? And then how does this feature support my North Star metrics? So you start with long term, where are you going? What do we need to do this year for the company? And then how does this support the North Star metric that, that we own as a product group? So no standard prioritization, but always asking questions that help PM think both long, medium and short term.

I like that. Long, medium and short term. Sometimes what you don't build or say no to is equally important, right? Because you get a lot of distractions, customer feedback. Now you're a product led company, you get tens of thousands of users. How do you pick what to say no to?

I think this comes with a really clear articulation of what your vision is, where are you going, what is the product you're building going to look like in three to five years? And then what is your strategy to get there? And your strategy is really what should help you say no. Right? Your strategy is a series of investments you're going to make. It's going to be markets you're going to go after. It's going to be products you're going to build that are going to ultimately allow you to win and ultimately achieve your vision. So if you have a really clear and articulated product strategy, that actually is what can be used to say no. And so decision making happening day to day from PMs oftentimes is coming from that clearly articulated product strategy which is going to tell them like we are not, we are explicitly not focusing on this type of user, we're explicitly not focusing on this market. And that's, I think that's one of the best ways to drive clarity is through a really clear product strategy.

How did you land on your pricing strategy at Calendly? Because you have a massive, massive freemium product. And does that bother you guys in terms of consuming bandwidth or time from the team or it's natural, it's aura of business? I guess.

Yeah. We actually just went through a rehaul of our kind of packaging and our pricing at the end of last year. And the reasons were really, the business was evolving and expanding and we had now have large enterprise customers who are using calendly. We now have teams of users, sales departments, recruiting teams, support teams who are all using calendly together. We have business professionals and then we have a lot of solopreneurs, consultants, freelancers. So we have a really broad base of users. And so we really tried to create and tailor packaging fit for the needs of those users and the types of products that they would, the types of features and functionality that it would need to accomplish their goals. And so I think understanding and segmenting your users to understand the differences in their use cases and therefore how they might use the product and therefore what tier they need to be on is at least how we started with our pricing and packaging project. Think back to your question around freemium. Again, this is a little bit of the like ecosystem. You have to really think about the whole business model and how your free users are ultimately going to drive adoption of your product, which are ultimately going to lead to expansion, which is ultimately lead to an enterprise buy. And I think in a PLG world where you're starting bottoms up and you have a solar solo sales rep who starts to use calendly because they want to close deals faster and they start seeing success and then they invite team members from their sales team into their account and they start using it and then all of a sudden the recruiting team starts using calendly and all of a sudden then it's an enterprise level buy to buy calendly. We want to help that journey and you can use pricing and packaging as a way to help with that journey and get someone from a free user expanding all the way up to an.

Enterprise buy Calendly ever doing usage based is that valuable? Does it hurt or harm a PLG company if you have like freemium and then you have freemium upgrading to subscriptions is usage based pricing too much of a hassle or friction to introduce in there?

Yeah, I think for, I don't know, there's a one size fits all answer. I think for our business, usage based pricing is, is less beneficial because again the way that a lot of the growth happens is through meeting scheduled. And so if you're capping the number of meeting schedules by tiering, then you are not only creating a really bad user experience where you're not fully allowing someone to actually use the product how they need to to get their job done, but you're ultimately handcapping your own growth. So I think at least for us and for our business model, something like saying you can only have a certain number of meetings, meetings higher up in tiers isn't ultimately going to help the overall ecosystem of how we grow as well as potentially as a poor user experience for those users.

And I like that focus on user experience. Everything you do, from pricing to packaging, how does it impact the end to end user experience? And everyone needs to think about that very deliberately. Is it going to frustrate people or is it going to delight them?

Exactly, yeah. And it's so easy to be focused on your own internal goals, goals and then that shows up in the product experience for users and they can feel it. Right. And so I think this, I give a ton of credit to Tope, our founder and CEO who from the beginning, you know, had a laser focus on the end user. And we are very deliberate as well around when and how to go up market and into the enterprise and to not do that too early and to really think about first, how do I build a really powerful, simple, simple but powerful horizontal product and then let that horizontal nature of the product pull us into where there might be opportunities up market. And so we didn't set out to necessarily have large enterprise customers using our product, but because we started horizontal we started to see, oh, sales reps get a lot of value out of this. Oh, recruiters get a lot of value, customer success managers get a lot of value. Let's go deeper there and then now that we're deeper and we can solve the needs for the users in those departments really well, let's start to, to think about capabilities that will allow us to sell into enterprises and be more enterprise grade. And so I think there's starting horizontal and then also intentionality about when to go up market. And I think customers or companies who go up market too fast oftentimes then back to the user experience, sacrifice that, sacrifice the user experience to go Land some of those larger deals versus doing it a little bit in a more disciplined manner.

Let's say you had to start a company today, how would you build your product? How would you go about it? How would you structure the team to facilitate PLG superpowers, et cetera, on your team? Like, how would you go about it? Building from scratch?

Yeah, I think the first piece for me would be identifying what is the market I'm going after and making sure that it is a very large, underserved market or one that's maybe a little bit smaller, but growing rapidly. So I think you start, I think most people start with kind of an idea or a product, but I, I think if you actually start with the market and this goes back to like understanding the users, understanding their problems, start with a market, find a large market that's underserved today, then figure out once you've understood, like what are all the needs and the pain points and the jobs to be done by the users in that market and why is there no alternative to doing it better today? Then figure out what's the product I'm going to go build that's going to solve this problem better than anything else on the market. So I think I would start actually first, first with, with the actual market I'm going after, make sure it's really large or at least growing really fast, and then go to what's the product I'm going to sell and what's the product I'm going to build that's going to allow me to tap into that market and serve users in a way that they aren't getting service today. So I think that's the first one in terms of the product team and structure. I actually think the more important part around, around that is around what do you need at different phases of a company's growth when it comes to your product team? And it really changes a lot as you, you grow and scale. And so in the early days, pre product market fit, a lot of the product team's job is to throw things against the wall and see what sticks. Build a lot of things, ship a lot of product. Usually the CEO or the founder is the one determining the roadmap. And you're really doing everything you can to find product market fit before your first next round of funding. And then I think once you've found your product market fit, you have something that's working now, you transition into a little more of traditional product management, which is to say, how do I, I keep the core product that we've Built going, how do I enhance it, how do I make it better, how do I create more predictability, how do I start to communicate more cross functionally and make sure the whole company knows what's going on with the product. And that's a kind of a different skill set and a different org structure than when you're pre product market fit. And then you hit this hyper growth area where all of a sudden the structure of the org and the role changes again to say, okay, we have this core product that's doing really well, well, how do we start to think about adjacencies? How do we think about, you know, expanding geographically, how do we think about new products that we need to build or new sectors or industries we want to go after? And so you have to have a balancing act between run the core while also innovating or building and expanding in new ways. And so I think at each of those phases, the structure of the team as well as the work actually materially changes. And so you have to continue to adapt your product team structure and your processes and the types of people you bring on the team at each of those phases to meet the needs of what the business needs at that time.

In terms of your teams as it stands today. And you scale, right? Let's say you raise a series A, now you need to bring in a product leader. How do you determine do you bring a VP product or a chief product officer? What are the differences?

A good friend of mine, Nikhil, who is the CPO at Credit Karma, has a lot written on this. And I think this is a mistake that founders often make is around that series A Series B, they decide they need to bring in a head officer, a product. And whether they call them a VP of product, whether they call them ahead of a product, whether they call them a cpo, they need to really get honest with themselves around what are they trying to solve for in that moment and then therefore match that to the skill set of who they're trying to bring on. And the biggest mix match, I think that happens at that phase is that the founder CEO doesn't want to actually give up the reins of product. They still want to be deeply involved. However they they want to do want to remove themselves from often like operational pieces of product management, right? And so then they bring on someone who's maybe tends to be more visionary in nature and then there's a clash, right, because the founder thinks they're the ones deciding what the vision is and what the roadmap is. And the head of product thinks they were brought in to really lead and create a vision and own the roadmap. And so I think, I don't know that there's a right answer for what you, what is needed at that moment in time. More importantly, I think is that the CEO or founder is clear on why they're bringing in a head of product and then they bring in the skill sets and the person who actually wants to do that job. And that mismatch, I think is why you see a pretty low rate of folks who are brought in as head of products at that stage who are able to actually scale with a company.

What does the process actually look like from brainstorming through implementation of different product growth features, even tactically speaking, like the cadence of meetings and how to prioritize different ideas, which ones to start with with maybe you use like a Rice scoring framework as a small startup, are certain small number of engineers dedicated to only growth or just pulled into projects as you want to spin them up?

I think for us maybe the best example will be our growth team. So we have a growth team and they're focused on helping to drive acquisition, or sorry, acquisition, as well as activation and then conversion. And then we have kind of core product teams who are really focused on engagement and retention. So we really think about the whole product, a funnel. And then we have teams who are working on different parts of that funnel. Back to something I said earlier, very important that we're always though thinking through the end to end user experience. But we have a growth team higher up in the funnel who's thinking about how do I help acquire users at a higher rate, how do I activate them more quickly and how do I convert them at higher rates. And so then they're very much tasked with, you know, those metrics, right? I need to see an increase, 10% increase in activation over the next quarter. And then that team goes and they do a bunch of qualitative and quantitative research, try and understand the problem with activation. Why aren't users activating at a high, you know, at the rate we want them to? Then they take those problem statements and they go develop hypotheses, right, as to why, how they could actually solve. How might we, how might we solve the problems of users that's preventing them from activating at the rate we want them to? And then they go develop a bunch of experiments that they believe might improve the rate at which people are activating that are in line with those hypotheses. So it starts with what's the high level metric we're Trying to, to move, go understand the state of affairs today as to why it is at the rate it's at and then create a bunch of hypotheses around how you could improve that metric and then go run experiments to see, prove or disprove your hypotheses. So that's a typical growth playbook at least at calendly in terms of the development of how we go from we want to go invest in a certain area to a prioritization of experiments that we're going to go experiment our way the into into ultimately moving a metric for and ultimately providing more value for our customers.

How is the team structured then? Are they like individual teams? Is it like a epod? You got growth folks, you got a product manager, you got developers. What is the number of people there? Or is it all cross functional, working on different product lines features?

Yeah, so we break it up. We have a group focused on quote unquote enterprise and ecosystem. We have a group focused on, focused on the core user experience. And then we have a growth, a group focused on growth. And then within those groups umbrellas we have different squads that play different roles within each of those different groups. And on a squad is typically product manager, a UI UX designer, a content strategist, maybe five to six engineers, and oftentimes a product analyst. And so the group of all of them together are the ones who are collectively going from problem space into ideation of solution, execution, launch and then post launch iteration. So they're all squad together, all in service of the success of the product area that they own.

People build companies, not the other way around. And people need to be pumped up all the time. With a hyper growth company, how do you continue achieving hyper growth without burning people out?

Yep, we're certainly in that hypergrowth mode right now. I think the biggest challenges with hyper growth are one, there's more opportunity to go after than you you will ever have resources to go after all at once. So there's that challenge and then I think there's also you're hiring and onboarding people at an incredibly rapid clip. And so the result of both of those together feel makes everything feel pretty chaotic. Right. You've got more opportunity than what to do with. People are coming on board left and right. You can't keep track of who all the people are. You don't know what anyone does. And so I think mitigating burnout during this time is done through really two things I think. One is creating incredible clarity around priorities. Right. That's at the company level. That's at each org level, that's down to the product squad level. And iterating that over and over, like you can't over communicate the few number of priorities that you have at a company. So I think that's a big piece is like continuing to make sure the whole company understands what are our top priorities. Because otherwise it's going to feel like there's opportunity everywhere and it's going to feel very chaotic. I think the second piece on the hiring side is you just have to be realistic around product people debt, which is you have a roadmap and you base it on capacity today plus the people you're going to hire over the course of the year. But you then have to discount it because you hire people and it takes them three to six months to ramp and be fully functional. And so I think there's also a way to be really realistic around your product development timelines as it relates to how many people you're bringing onto the team and how long it takes them to ramp and actually be productive. So I think those are the two ways that I've found is like incredible clarity around priority priorities and then making sure we're actually being realistic around quote unquote people debt as we're hiring on hundreds and hundreds of people per year.

Any last unconventional advice maybe that people ignore, but shouldn't you've learned in your life.

I have learned over the course of my career that to focus more on my strengths than my weaknesses. So when I look back at my career, early in my career, for example, I don't have a technical background. And, and so as a product manager, there's certainly a little bit of imposter syndrome about that in the beginning and for a long time focused on, okay, I'm going to build up my technical chops. And then what I learned over the course of my career is yes, I could do that and I have made incremental progress along that. But actually the step functions of LIFT in my career have come when I've doubled down on my strengths and realized, oh, I'm actually really good at X, Y and Z and then using those and making those even better, but also so finding ways to actually leverage my strength is where I found the most success in my career. So it's not to say don't focus on your weaknesses or ignore them, but spend more time harnessing your strengths, doubling down on those. And I think at least I've found that to be some of the bigger step function changes I've seen in my.

Career focus on the strengths and you'll inevitably then focus on things you love doing versus procrastinate on the things that don't come naturally to you. Any books you recommend that have shaped your career or learnings over the years?

There's a couple of product led. There's product led growth books that are out there that I think are good. Product led Growth by Wes Bush is a good one. Just overall primer on what is product led growth and what are the different models. There's also a product led onboarding book that I think again good primers just on if you're starting to get new getting into plg. We didn't talk too much about this in the product section, but Marty Kagan has a book called Inspired that I think really talks about creating empowered products teams and I found to be really powerful as I've grown as a product leader for how can I create best in class product teams and make them most productive? So those are just two, two, two that come to mind just in terms of plg, some topics we talked about PLG as well as growing and scaling product teams.

What is the one tip you have to create empowered product teams? Because teams are everything. People are everything. And if people are not empowered, they don't do their best work.

My job is to create clarity around where are we going? That's the vision. What is the strategy of how we're going to get there and then get out of the way and really empower the team to come up with a lot of the hows, right? Like they're going to be the ones responsible. They're closest to the customers, they're closest to the data. They're going to be the ones responsible for figuring out what are the actual features and functionality and user experiences to actually deliver the results that we need to deliver. And the best thing I can do is get out of the way and empower them to to make those decisions. The worst thing I can do is come down and dictate what a roadmap should be or how an experiment should be run and they'll do their best work and they'll ultimately deliver the best results for the business if I can create that clarity around where we're going and how we're going to get there and then really empower them to lead the way.

You're bringing the vision, the values providing the metrics. They're bringing the execution. Hire smart people and get out of their way. Thank you so much, Annie. I need some traction. You need some traction.

Thank you for listening and we hope you enjoyed this week's episode of the Traction Podcast. If you enjoyed the show, please leave us a five star review and you can find more information and all the resources mentioned in today's episode at. Boast AI that's b o a s t a I forward slash blog.