Behind the scenes of Calendly’s rapid growth | Annie Pearl (CPO)
26 Feb 2023 · 62 min
Annie Pearl, CPO at Calendly, talks about how the company shifted from pure product-led growth to adding sales-led strategies as it scaled. She covers prioritization frameworks, team structure, and the organizational changes that came with rapid growth.
Strategy is really just an integrated set of choices that outline how you're gonna win in whatever marketplace you choose, right? And so a good product strategy is gonna answer questions like, what's your sort of winning aspiration? But maybe more importantly, where are you gonna play? You know, what are the markets you're gonna go after? What are the segments of those markets? What are the personas in the segments of those markets? And then how are you gonna win with that target audience?
Welcome to Lenny's podcast, where I interview world-class product leaders and growth experts to learn from their hard-won experiences building and growing today's most successful products. Today, my guest is Annie Pearl. Annie is currently Chief Product Officer at Calendly. Before that, she was Chief Product Officer at Glassdoor. And before that, she was Director of Product Management at Box. She's also a member of SCIP, a community for Chief Product Officers, and she's on the board of two different companies. In our conversation, we cover a lot of ground, including how Calendly builds product, how Calendly has grown, including the wild story of how they got their first thousand users, and also how they built a sales team on top of what historically has been a very product-led growth company. Annie also shares a ton of great advice on how to get into product management. I learned a ton from Annie, and I know you will too. Annie also shares a few killer tips for using Calendly, which I loved. And so with all that, I bring you Annie Pearl for a short word from our wonderful sponsors. Today's episode is brought to you by Miro, an online collaborative whiteboard that's designed specifically for teams like yours. I have a quick request. Head on over to my Miro board at miro.com/lenny and let me know which guests you'd want me to have on this year. I've already gotten a bunch of great suggestions which you'll see when you go there, so just keep it coming. And while you're on the Miro board, I encourage you to play around with the tool. It's a great shared space to capture ideas, get feedback, and collaborate with your colleagues on anything that you're working on. For example, with Miro, you can plan out Next Quarter's entire product strategy. You can start by brainstorming using sticky notes, live reactions, a voting tool, even an estimation app to scope out your team's sprints. Then your whole distributed team can come together around wireframes, draw ideas with the pen tool, and then put full mocks right into the Miro board. And with one of Miro's ready-made templates, you can go from discovery and research to product roadmaps, to customer journey flows, to final mocks, all in Miro. Head on over to miro.com/leni to leave your suggestions. That's M-I-R-O.com/leni. This episode is brought to you by Coda. You've heard me talk about how Coda is the doc that brings it all together and how it can help your team run smoother and be more efficient. I know this firsthand because Coda does that for me. I use Coda every day to wrangle my newsletter content calendar, my interview notes for podcasts, and to coordinate my sponsors. More recently, I actually wrote a whole post on how Coda's product team operates, and within that post they shared a dozen templates that they use internally to run their product team, including managing the roadmap, their OKR process, getting internal feedback, and essentially their whole product development process is done within Coda. If your team's work is spread out across different documents and spreadsheets and a stack of workflow tools, that's why you need Coda. Coda puts data in one centralized location, regardless of format, eliminating roadblocks that can slow your team down. Coda allows your team to operate on the same information and collaborate in one place. Take advantage of this special limited time offer just for startups. Sign up today at coda.io/lenny and get a $1,000 startup credit on your first payment. That's coda.io/lenny to sign up and get a startup credit of $1,000. Coda.io/lenny. Annie, welcome to the podcast.
Thanks for having me, Lenny. Super excited to be here.
I've been a big fan of yours from afar. We've crossed paths a little bit on Reforge, on Twitter, probably been at events that maybe we didn't know each other at yet. So I'm really excited to finally be chatting sort of real life in real time at least. Me as well. I've got a Calendly question to kick things off. It feels like with Calendly, one of the most awkward elements of it is I have to like put the burden on someone else to book a Calendly. So I'm sending a link in an I haven't figured out a good way to send it to someone without it coming across like a power move. So my question to you is, how do I send a Calendly to someone without it feeling bad?
All right. Well, I love this question to kind of kick us off. We actually have a whole blog post about this if you're curious to learn more, but I think at a high level, I think I recommend first really just kind of opening the door for the person you're trying to schedule time with to share their availability first, right? So instead of just sending the link, I usually start the email with something like, you know, looking forward to connecting, feel free to share. Sometimes you're available, or easier, you can choose, you know, to find time on my calendar using the calendar link here. So opening the door to let them choose before you offer up your calendar link, I think is, you know, a little bit of a subtle way to let them take the lead if they want. The second piece I would recommend too is once you kind of open that door, you can kind of further reduce the effort on the recipient by adding times you're available directly in the email. So When you go to share a Calendly link, there's an option to add times to email and you can then just paste those directly into the email you're creating. So that reduces yet another sort of point of friction to ask the user to click the link and, you know, get taken to Calendly. So opening the door and then, you know, adding times to email are two things that I do to really make.
Sure that it's not awkward and it doesn't put the burden on the other person. That is awesome advice. That first one is kind of what I ended up doing actually. That's really interesting where you don't send the link immediately. You first just ask, hey, send me your calendar, and I actually always say, send me your calendar. I don't even, I assume that's what they're using. It's kind of funny. I'm not even, like, I don't know anyone else is out there. That's good. That's what we like to hear. Yeah, absolutely. It's like its own word now. Okay, that was awesome. Oh, look at this already actionable advice for anyone listening. Sweet. Transitioning a little bit to product, the main focus of our chat. You transitioned into product from being a lawyer. You told me at one point that a lot of people ask you for advice about how to transition into product from other functions, especially non-technical functions, someone without a technical background. So what advice do you give people for when they ask you how to transition into a product role?
I got, you know, what I'll call lucky, which is I kind of stumbled into product management after law school, joined the founding team of a startup, and, you know, ended up doing product management there. But when I think about folks who are looking to get into product management, I think there's really two paths. I think one is kind of more formal in nature, right? There's associate product manager programs out there and many, you know, scaled companies, Google, Meta all have APM programs that you can formally apply to. And actually when we were at Box, much earlier stage company than either of those companies I just mentioned, we actually created an APM program to help grow our bench of more junior PMs. So I think you can actually find APM programs even at smaller, earlier stage companies than even kind of big tech. So that's one, it's just formal APM programs. I think another kind of more quote unquote formal way to get into PM is really by just, you know, directly applying to a junior PM role where there's no expectation of any sort of experience. I've usually seen this work best when you're kind of already working somewhere in some sort of product adjacency, you know, maybe you're in customer support, implementation, or maybe you're a sales engineer, but you can kind of look at the internal, you know, job board and find junior PM roles that are posted. And that's one way to make the move. So that's kind of on the formal side, like APM programs and just applying. via internal job boards. I think on the informal side, really two suggestions here. The first one is to kind of seek out opportunities to kind of shadow or partner closely with a product manager and maybe even offer to take on some work. So some of the kind of best PMs that I've brought over to product from kind of other functions, they really start by expressing interest in product and then like start partnering closely with the product manager and maybe even doing a little bit of product work before they make that transition. And one kind of tactical suggestion is there's oftentimes companies will have subject matter expert programs where they want to pair someone from a go-to-market function with a certain product squad or a certain product area. And so that's, you know, becoming a SME allows you to really get more involved and embedded into the product team. So that's one suggestion. And then maybe last one is just, you know, going the path I did, which is joining an early stage startup. There's really usually an expectation that everyone's going to get their hands dirty doing a lot of different things. And so I think that's one way where you might have an opportunity to, you know, try product management if you end up kind of joining an early stage company.
So the four, maybe it was four, maybe it was more paths that you described. Join APM program. What was the second one again?
Internal job board apply to it when you're in the company.
As just like a junior PM. Two is find someone that kind of like mentors you and helps you start doing the role. And is that internal kind of, is that the internal transfer out?
Yeah, exactly. And then another sort of flavor of that is, you know, sometimes companies will have these sort of SME programs.
What is a SME program?
A subject matter expert. So, you know, you'll say, Hey, I want to make sure we have subject matter expert in our CS team on this area of the product, and they'll partner really closely with, you know, the.
Product manager and designer within that area. Got it. And then the fourth bucket is join a startup, start doing PM work, and then you end up being a PM. You got it. Which of those four do you find most common?
And would you push people in one direction or another? Yeah, you know, I, I've brought a lot of folks over internally through the, through the path of someone's really interested in product. They express they're interested, they want to help, they want to learn. they're eager, they're curious, and so they make that really well known. And they're even willing to, you know, do some work on the side to help out and really show and demonstrate the skills before they have the job. So I've seen that one to actually probably bring, bring the most folks over in my role in terms of being on the product leadership side.
On the APM program route, are there any APM programs you recommend? Because, you know, I'm sure people hear this and they're like, yeah, but I don't know where to apply. I don't know which ones are good.
I don't know if you have a list, but just like, what comes to mind is, like, APM programs to go pursue, you know, the, the sort of the folks who started it all was, was Google, right? With the Google APM program and, you know, Meta obviously has a pretty strong, robust APM program. But as I mentioned around Box, I think, you know, those are obviously very, very competitive and most people want to get into them. You know, it may be better to try and find a company like a Box or a company that's a bit earlier stage, not as scaled to think about looking at those APM programs. And I'm sure if you want to go to glassdoor.com, where I used to work at Glassdoor, so I had to, you know, throw that in there, you.
Could search for associate product manager and I think you'll find a whole host of open roles that you might be able to apply to. That is a cool tip. I haven't heard of that. Go to Glassdoor and search for APM. So you search for companies that have.
An APM, like title. Yep. You could just associate product manager and.
You'Ll see all the open jobs out there and then go apply to them. That's cool. Okay, good tip. What I find, and I, you mentioned this, like the best, if you have the option is internal transfer. You're right.
If you're just like another function, you find someone that can help you move into the role. Yep. You have the relationships. You, you know, you can show, you can show your work really well. The other thing I would say is When I think about folks who have successfully transferred over, I think they tend to have a couple characteristics, right? They're usually very curious. They tend to be really passionate about the product and kind of solving customer problems. And sometimes they've even like tinkered with a side project as a way to kind of hone their CAM skills. So I think as you're thinking about making that transition, those types of characteristics really showing eagerness and interest in the product itself and solving customer problems are also great ways to get noticed and increase your chances.
Why do you think it is that not more companies have an APM program? Feels like such a win for so many people. Why is it just so rare?
Yeah, I think when we built this hitbox, so kind of drawing on that experience, it was a lot of work, right? You want to, if you're going to do it, you want to do it really well. And you want to create an environment where you can help the associate product managers be successful. You know, the goal is to ultimately graduate everyone from the APM program into being a product manager. And so I think it takes a lot of intentionality. And for us, it took a lot of, you know, a lot of work, right? We had to make sure we had clarity around the interview process. We had to make sure we had clarity around expectations in the role. We wanted to have a training element. We wanted to make sure that, again, we're setting people up for success. So I think companies have to be at a stage of scale where they can really invest and they have the excess capacity to build the program in a way. I think that's going to help make sure everyone who comes through it has a chance at really learning, growing, and ultimately being successful.
That's the same thing we found at Airbnb. There's a PM that was so excited to like make the APM program and just, just never really happens. Just takes so much work. And to your point, you have to set up for success. You want to make sure there's clear paths. And what do you, when do you upgrade to a regular PM and how.
Do you interview and, you know, and are we doing, you know, is this really an APM program for internal folks? Is this external? You know, are we going to be really trying to promote this? So I think there's a lot of ancillary activities around the actual program itself that have to be taken into consideration to make sure that it is Yeah.
Maybe a last point we should probably imagine you agree with is generally just hard to get into product management. That's like the default. There's just like not that many roles at companies versus say engineers or some other functions. So I think that's just like, there are not that many roles. It's like a difficult role to break into. But these are the ways you can do it if you actually want to.
That's right. Yep.
Okay. So I want to transition a little bit to talking about Calendly. There's kind of two areas I want to go. One is just, how do you build product at Calendly? What have you learned about product development and team building. And then two, talk about how Calendly grows and what you've learned about growing a product like Calendly. It's such an interesting product, especially from a growth perspective. So to start on just how product is built at Calendly, just a little context, like how many product managers are there? And yeah, how many PMs are there? How many people total, roughly, just to give us a little bit of context?
Let's see. When I joined about two years ago, I think the company was about 150 people and I think we're about 600 now. And then the product team were about, there were about 15 product managers and designers when I joined again about two years ago. And I think we're around 60 this year.
Wow. So 60 product managers.
Product managers, designers, and a research team. Yeah.
Got it. What about just like PMs?
PMs probably my guess is 20.
Cool.
20-Ish. Yeah.
Cool. And then can you talk about how the product team is structured roughly? Like if you think about a tree. or chart tree?
So we have, as I mentioned, we've got product managers, we have designers, we have a research team, and then product operations. And then on my product leadership team, we have a head of design, head of research, head of product operations, and then within the product management team, I have leaders across core, across enterprise, and platform.
Got it. So you manage the design team and engineering team, you said?
Not engineering, design, product, and research.
Yeah. Got it. Something that I find is one of the big differences between product orgs is design reporting up to a product leader versus not. What's the rationale there? And then has Calendly tried a different approach?
Yeah. So when I was at Glassdoor in the CPO role, I had the opportunity to lead design for the first time. So coming into Calendly, I had led both product and design as well as research. And so I think, you know, it kind of made sense given I'd already done it once to sort of keep that structure coming into Calendly. I think at the end of the day, the real benefit of the structure is really to say at the end of the day, We want to be thinking about everything we're doing through the lens of the end-to-end user experience. And so if we have product managers who are really prioritizing the problems we're going to go after, and we've got designers who are really trying to think about how do we bring solutions to life to solve those problems, having both of those functions roll into one person just really allows us to think more holistically around the end-to-end user experience. So certainly can work where you have product and design reporting into different leaders that ultimately report into the CEO. But when you get to this level of scale from just a pure people management, but also just the scale of the business. You often see this consolidation where product and design start to roll into one leader. And at least in my experience, I think it can help ensure that all the different pieces of work are integrated well together and ultimately deliver a better experience for customers.
So it sounds like before you joined, it wasn't like that. And if that's true, was there something that improved with that shift?
So the structure was there that way. At the time, we didn't have a head of design. So we had a lot of really great individual contributors and who had been, many of whom had been with the company for quite some time and really contributed to the great user experience that existed in the product, but we didn't have a design leader. So one of the first leadership hires I made was to bring in a head of design to really build out that function. And then that head of design is sort of up here partnering with the different heads of products across the product management organization as well.
What about in terms of the structure, whatever you can share, like one level below, like how do you structure teams? Is it around outcomes? Is it around features of the product? Is it around type of persona? How do you think about that?
Yeah, so we have a core team who's really responsible for the core end-to-end user experience. And in many ways, they're both building, doing feature development, and then they're also doing growth work, right? So they're thinking about how do we build new features and functionalities to help our core personas, which is typically folks who are in sales, recruiting and customer success. So anyone in an externally facing role, we're really trying to help them do their jobs better. So the core team's thinking about features and functionalities to really help our core end user persona and then, you know, growth work to think about the PLG funnel, right? Everything from acquisition, activation, conversion and retention. So that's one group. And then second group is our kind of quote unquote enterprise group. And they're really thinking about two different personas. One is the sort of IT admin, right? The sort of person who needs to make sure that Calendly is secure and that they have all the reporting mechanisms to be able to manage their account and all the tools to, you know, manage users and groups at scale. And the second piece of that is also kind of departmental leaders, right? So as Calendly selling into or being used by a sales organization, the head of sales is not the IT admin, but they are a kind of, you know, a teams admin who needs to manage their organization within Calendly. So the enterprise group really thinks both about the admin, but also sort of the departments and how do we better serve departments. And then lastly, we have a platform team who's really thinking about, you know, how do we embed Calendly into the business processes of the organizations that we support and that we, you know, provide our product into. And so that's everything from, you know, partnerships and integrations to our APIs.
Interesting. So it's kind of like problem focused slash persona focused, like who are you trying to solve for?
That's right. That's right. Yeah, trying to sell to and then sort of the persona of who's going to be using the functionality and then, you know, really having those teams hone and own those personas as they're, you know, developing functionality within the product.
What's your take on OKRs? Do you all use OKRs in some form?
Yes, we do. We use OKRs both at the company level. So we have three main OKRs that we're focused on for this year, for example, across the whole company. And then we have department level OKRs, many of which are in support of the company level of OKRs, but then, you know, there's some additional things that we'll be doing at the department level, for example, that aren't going to show up at the company level. So, yeah, we use them both at.
The company as well as on the product side. Is there anything you've learned about making OKRs work? There's a very, people love 'em, people hate 'em. Is there something you do to make OKRs work?
Some of you've changed, some of you've learned over time in how to work with OKRs. Yeah, you know, when I first joined, I'd say we, you know, we didn't have this muscle well built out, right? We didn't really have a clear product strategy at the time or clear OKRs guiding the work. And so, So there was a lot of great work happening, but it really, it was unclear how it all kind of fit together or how we were going to measure success in that work. So that was kind of the first phase. I think the second phase for us was we developed a product strategy. We then had product team OKRs that corresponded to that product strategy, but they were really contained to the product team. And each department across the organization had their own kind of siloed OKRs. And then phase three, where really I'd say we headed into this year, we have a really clear set, as I mentioned, of company OKRs and then these really tightly integrated plans across the company around how we're gonna support the key results and ultimately, you know, deliver on the objectives. And this has been a really incredible transformation of dependency mapping, you know, being able to make sure that we're pulling all the levers across the organization to drive our most important objective. So I think it's just the kind of maturing of the business from almost, you know, no OKRs to product team OKRs to now company OKRs and a really tight planning process to make sure there's a lot of integration across the company to support what we need to do as a, as a business.
So what I'm hearing is one of the biggest changes in learnings was to connect OKRs across from the top to the bottom, right?
Absolutely, absolutely.
Is there anything else that has made a big impact on your ability to build and ship and execute as a company in terms of like changes you've made in terms of how the company and how the teams build?
I think one of the biggest changes that, you know, we've made, when I first joined again, we, we had a product served a lot of horizontal users, right? We help solo users who are freelancers, consultants, we help, you know, sales teams, we help recruiting teams, we help customer success, we help folks in education. So it's a very broad user base. And what that means is that product managers in particular, I think, had a really hard time prioritizing, right? At any point in time, it was really difficult to say, should I do, you know, work on feature A or feature B? feature would be without that clarity. And so I think one of the most impactful things we did pretty early on in my tenure here was to hone in on our overall product strategy, but a poor piece of that being what's the actual market we're going after? What are the segments of that market? Who are the personas within the segments of that market? And so we've made a pretty clear distinction now that while a lot of the feature work that we'll do to support our target personas of sales teams, customer success teams, and recruiting teams will impact folks who are not in those personas. Those are the core ICPs that we're going after. And so, you know, historically, that would have been always a sort of a trade off decision and a question. And now I think we have a lot of rigor around who the target, you know, who our target market and then persona we're going after. And so teams can use that to prioritize and also just deliver better value for those users.
So it sounds like the biggest unlock and one of the biggest unlocks for making the team more efficient, move faster, make decisions quicker is narrowing in on exactly who you're gonna be selling to.
I think it's one of the harder things for companies to do. So it sounds relatively easy and I think most companies believe that they have clarity around this, but then when you go down into the weeds of asking someone who's product manager or a designer, I don't know that it's always as clear because there's always a bit of a hesitation to say no. Right? And the idea of saying no is scary when in reality the ability to say no is going to allow you to make sure you're building something that's going to be amazing for the people that matter most and not something that's going to be, you know, average or okay for a lot of different people.
Was there anything that was really hard about actually executing that? Like convincing people we're going to narrow and not worry about these people and any lessons from going through that process? Cause I imagine a lot of founders listening are like, oh, that sounds we should be doing this. Oh man, we're leaving all this money on the table. People are gonna be pissed.
Yeah, I think it's a pretty big cultural shift. So some of this intersects with the shift from product-led growth to adding in kind of a sales motion. So, you know, when I joined Calendly, all of our ARR came from our PLG channel. We didn't have a sales team. We just hired a CRO who was gonna build out a sales team. And so, you know, in that world, the way you think about product, the way you think about processes, even the people you have on the team are tailored to that business model. And then as we sort of moved up market and have now, you know, explicitly started to want, you know, go after teams of users and departments of users and, and, and organizations of larger scale, everything about people, process and product all changes, right? I touched on culture because I think that's pervasive across the entire organization. The way that things get done, you know, has to be highly integrated versus can be a bit more siloed when you're just, you know, sort of the self-service PLG business that in many ways runs itself through the product being well optimized. So, you know, there's a lot of process change that needs to happen. The type of people that you need to bring into the organization, that changes as you layer in, you know, the new selling motion, and then the product itself, of course, has to change. So I guess that's just to say the example of PLG and SLG or the direct selling motion is, you know, tying to your question around what are the things that need to change in order to get clear on, on your sort of your target user? I think Highly cultural in nature across people, across process and even, and then obviously across the actual product itself.
I have a whole bunch of questions about how Calendly grows and maybe we just get into some of the stuff because I imagine a lot of people are interested. First, let me ask this. Imagine Calendly mostly grows through, I sign up for Calendly, I send it to everyone when I would book a meeting. They're like, oh, what is this? And they're like, oh, cool, I'm gonna use this. And then they start using it and spreads. And then sales eventually finds people at.
A company that are using it a lot and tries to get the whole company on it.
Is that roughly right?
Yeah, 70% of our signups come through that viral loop that you referred to. And then of those signups, then they're usually solo users and then they start to invite team members in. And then the team starts using Calendly and then usually the head of that team either inbounds to us or we have some sort of PQL data to know we should go after that team lead to try and have a conversation around expanding Calendly across their entire PQL product qualified lead. You got it. Yep.
Wow, what a loop, what a magical way to grow that everybody wishes they could.
It's pretty incredible, I will say.
Oh man. Okay, so going back to the question, when did Calley hire their first salesperson? Like any learnings about just how to start down that road once you start product qualified?
Yeah, you know, as I mentioned, when I joined two years ago, we just hired our first CRO and the PLG business really represented 99% of our ARR. And then over the last two years, we've scaled the sales team and our SLG motion or sales-led growth motion now represents about 20% of our ARR, and it's actually the fastest growing segment of the business. I think there's probably two things I would touch on in terms of early sales hires. I think the first is when you're making that transition from PLG to adding in the sales-led motion, because you're starting from PLG, it tends to be much more inbound in nature, right? You've got these sales reps who are working leads who have usually proactively reached out interested, or as we mentioned, PQLs, you know, they have data to tell them that this is a, you know, someone who has usage within their team and therefore we should reach out. And so that's a very different profile of a sales team member than you might need after you know, you need to pursue more of a heavy outbound motion, more of like a hunter profile than a grower profile. So I think that's the first piece is just make sure you're, you know, you sort of, you think about the motion when you're moving towards a sales-led model in those early days, it's more inbound in nature. And so the type of sales reps you might need are not necessarily going.
To be, you know, outbound heavy kind of hunting sales reps. Just one quick question on that actually, because that's, that's really interesting. I don't know how involved you are in hiring these folks, but is it like look at their background and they've worked at a company like that, or is it personality type? Like, is there anything to look for specifically there?
Yeah, I think it's mostly background and the type of selling that they've done previously, more so than personality type. But in the second, I think the second piece that's important too, and I'll answer your question on that one too, which is the target buyer. So when you transition from kind of PLG to sales-led, or adding this direct sales motion, the buyer is usually just the department head, right? It's the head of sales, it's the head of RevOps, it's the head of recruiting, and it's not a senior person in IT or the CIO. And so selling into this audience is different than selling into IT. And so I think you have to be sure again that you have the right fit of sales folks with the target buyer in those early days. And so to your question around what's that mean, you wouldn't necessarily want to bring on a bunch of sales folks who are at Oracle, who are heavy in selling into CIOs in the early days, because that's just not who your buyer is going to be. I mean, think we'll graduate there eventually, but it's probably going to start from team lead to someone in IT to eventually a CIO-led purchase, but that's certainly several years away. And so making sure that the profile of the folks you're bringing on early match that target buyer in addition to match the motion around how you're going to be acquiring customers and to see.
That, is it similar? You look at the companies they've worked at, like, it's like PLG-ish companies.
Definitely. Yeah, exactly. Yep. Yep.
Okay. So along the same lines, as a product leader working with a strong and large sales team, anything you've learned about just how to build that relationship and build a product org that works really closely and well with a sales org?
The first piece it really starts with is customer, you know, empathy. and at the end of the day, seeing the sales team and the go-to-market team as this really great asset that can help you as a product manager get closer to the customer. So I've certainly seen organizations or been in organizations where, you know, the product team, you know, doesn't necessarily want to be bothered by sales, but I sort of flip that on the head and say sales and sort of the go-to-market teams in general can be your biggest asset to helping you get your job done well. When I was at Box, I was a product manager on the enterprise team and I spent a ton of time in the field. and, you know, I don't know how I would possibly know how to have, what to have built or how to build it to solve the needs of our customers. If I didn't have that close relationship with the sales team and be able to like, you know, lean on them because they're talking to 10x the number of customers that I was able to ever talk to within any given week, really lean on them to be the voice of the customer to help, you know, me make the best product decisions that I could.
This episode is brought to you by Vanta. helping you streamline your security compliance to accelerate growth. If your business stores any data in the cloud, then you've likely been asked or you're going to be asked about your SOC 2 compliance. SOC 2 is a way to prove your company is taking proper security measures to protect customer data and builds trust with customers and partners, especially those with serious security requirements. Also, if you want to sell to the enterprise, proving security is essential. SOC 2 can either open the door for bigger and better deals or it can put your business on hold. If you don't have a SOC 2, there's a good chance you won't even get a seat at the table. But getting a SOC 2 report can be a huge burden, especially for startups. It's time-consuming, tedious, and expensive. Enter Vanta. Over 3,000 fast-growing companies use Vanta to automate up to 90% of the work involved with SOC 2. Vanta can get you ready for security audits in weeks instead of months, less than a third of the time that it usually takes. For a limited time, Lenny's podcast listeners get $1,000 off Vanta. Just go to vanta.com/lenny. That's V-A-N-T-A dot com slash Lenny to learn more and to claim your discount. Get started today. I'm curious how you prioritize work that you could be doing as a product team. There are sales people coming at you, there's issues you're probably having, there's the founders wanting to ask you for new stuff. Just like, you know, classic product management question, but curious if you found any frameworks or approaches for just deciding what.
To actually build of all the things you're hearing.
The core challenge of being a product manager, right? Just to add that, like I feel like the core job of PM is.
Just tell people what's next. What's the next thing? That's right. And hopefully you have a good reasoning as to why that thing, you know, next is going to have the biggest impact, which is really where I start. You know, I think it really starts with a clear product strategy that will dictate a few things. And I like this framework that's taken from a book called Playing to Win. It talks about how strategy is really just an integrated set of choices that outline how you're going to win in whatever marketplace you choose, right? And so a good product strategy is going to answer questions like, what's your sort of winning aspiration? But maybe more importantly, where are you going to play? You know, what are the markets you're going to go after? What are the segments of those markets? What are the personas in the Segments of those markets and then how are you going to win with that target audience? And so what I think this framework does kind of dovetails back to what I was saying before around prioritization is it forces you to create clarity around where you're going to play and where you're not going to play, right? And so this really helps the product team kind of hone in on delivering value for a very clear set of people versus trying to build something for everyone. And so once you've established kind of what that strategy is or what the, you know, playing field you're going to go after, then I think you can divide up your product work and service of that strategy. So I'll give you an example. At CalaLy, we have the sort of vision, our winning aspiration, to become the best place to schedule, prepare for, and follow up on your external meetings. And then we've articulated kind of three horizons around how we're going to get there. Now, the year one that I was here, the percentage of resources we spent on sort of that first horizon and the second horizon was about a 70-30 split, and we put 0% of our resources on Horizon 3. That was too far out in the future, and we weren't, you We didn't want to make any investments there quite yet, but we knew where we were going. In year two, it shifted. We went to like a 50 50 split between Horizon one and Horizon two, but still no explicit investments in Horizon three. And then, you know, as we're entering into year three, now we've significantly scaled back the investment in Horizon one. That's about 30%. And then we've got 60% in Horizon two and, you know, call it 10 in Horizon three. So I think just to close on the question of prioritization, I think it starts with a really clear product strategy, which defines where you're going to play and how you're going to win. and then the work and the percentage of allocation just should feed right into that product strategy and how you're doing against where you need to be in order to achieve ultimately your winning aspiration. I don't know how much you could.
Share here, but is there a feature that is like people keep asking for it and it hasn't been built because of the strategy, the long-term vision, something that's like, nope, doesn't fit. We're not going to do this.
Yeah, I think the best example I can give is, you know, there's lots of small businesses and solopreneurs who would love us to have a Venmo integration. We have a PayPal integration, but our target market that we're really trying to go after as our primary persona are, as I've mentioned, these sort of core ICPs within organizations. So sales teams, recruiting teams, customer success teams. And so it doesn't make sense within those personas to pursue something like a Venmo integration. Now, there's a lot of things we'll build for those personas that are going to help the small business, the solopreneur, the freelancer, but that's a specific specific feature is something that would be clearly deprioritized given the current strategy.
That's an awesome example. I want to get back to the growth stuff, but before I do that, we're kind of on this topic of planning and of cares and prioritization. I'd love to know just how you do planning at Calqate, like how far out do you plan in detail? How far do you have roadmaps? How often do you plan?
Anything you can share there? This starts again. I saw it sound like a broken record, but with this like really clear strategy around where we're going over the next couple of years. And then we take that and we break that down into what are the most important things we need to do as a company this year in order to be able to make the right progress against that strategy. So we have the company level OKRs, and I mentioned we have about three of those this year. And then those KRs within the company OKRs are measured annually, but we have milestones across a quarterly basis so we can measure progress more frequently than obviously on the annual or semiannual basis. So I think that's kind of at the high level. And then, you know, obviously our product roadmaps are going to be in support of those key results that we needed to deliver to the business over the course of the year, but then kind of broken down on a quarterly basis. I think one thing I'll just touch on real fast on, on kind of estimations and dates. Something we've done over the last year is, is really kind of moved to a model of talking about dates and promising and committing to dates that are within our control. And so if you think about kind of the product development lifecycle, you know, we can commit to a discovery effort of, you know, doing research around a certain problem space and we can have a general sense of when we know that effort is going to conclude. We don't know if we're going to actually end up going and based on the results, whether we're actually moving forward with investing in that area. But that's a body of work we can commit to. From there, we then move into, okay, if this is something, a problem space we want to go after, we're going to go, you know, work on a couple different solutions and we're going to go do some user testing and we're going to land on a solution, and that's another sort of phase we can commit to. Then once we actually have that completed and we actually know not just the problem, but the solution, we can do estimation planning and actually have a date for delivery from an engineering perspective. And so we've gotten a lot better at making the commitments around the work that's right in front of us versus making a commitment around a project six months out when we haven't even done enough discovery, enough design and ideation to to have a real clear understanding of estimation. That is really cool.
Do you have terms for these phases, kind of like these phases you have to get through these kind of gates?
Yeah.
How do you describe that?
Yeah. So the first phase, you know, we sort of just call generally discovery. The second phase we call kind of solutioning. The third phase builds, and then the fourth phase is sort of launch, measure, and iterate. And then we've kind of designed the product development lifecycle around that framework.
So discovery, for example, is that like a roadmap item for a quarter? And that's like what you've committed and if that goes well, the next quarter has the next step.
Yeah, exactly. You got it.
Sweet. Okay. In terms of the strategy artifacts, how does that look? Or do you have like a Google Doc with a template that you all use? What does that look like? Because what's interesting about people not working at a company or working at just one company is they only have access, like strategy documents are really hard to see and see examples of, so I'm always curious. what these look like. So whatever you can share about what they look like and where you put them and how long they are and that kind of thing.
We have a couple different sort of layers of this. I think the first is this high level three year strategy, and this is actually called at the company level. So it's a doc. It also has slides that have presented, been presented many times to the company. And we're in the process of sort of making sure that that is part of new hire orientation so that, you know, everyone should understand where we go on over the next three years. And, you know, then therefore, how this year's objectives fit into that. So I think that's at that level. And then, you know, from there we've got our product team OKRs. These generally start by docs and we write them in docs. So they usually get translated into slides at some point for presentation purposes to the company. And those are, you know, sort of stored centrally in a location. And then, you know, you kind of get down to the feature level or the project level. And we have, you know, different kind of templates for the teams to use, you know, based on the type of work that they're going to be doing and we're we're a pretty heavy confluence culture. So we tend to use confluence as one of the tools for sort of housing and storing information around the work that's being done.
Cool. So maybe on that topic, what else is in the stack of Calendly product team tools?
We talked about roadmap planning. Some combination of starts with docs, there's mural boards involved. Usually it ends in slides. Then kind of actually roadmap tracking, we use Aha and we use Airtable, collaboration slash communication, we use Slack, we use Loom, bug management, we use Jira. Trying to think of Confluence.
Confluence, yeah.
Confluence is one we use quite a bit. Pendo, we use quite a bit of Pendo to help educate users within the product when we're launching new features. I think that's the main stack.
And Docs is Google Docs and Slides is Google Slides.
You got it.
Yep. Sweet. That's right. Okay, I'm gonna bounce around and go back to growth questions, and then I have a couple more product team questions. How did Calendly get their first thousand users?
A great question. I had to fact check it with my CEO earlier this morning, but there's actually a few really interesting things about this story and a few things that TOPE did in the early days to get 2,000 users. So for those who aren't familiar, TOPE, our CEO and founder, started his career in sales and he spent lots of years in sales. And so he was very used to the challenges of trying to organize external meetings with prospective customers. So he knew the problem space really, really well. And he had evaluated kind of all the scheduling solutions that were on the market. and kind of come to the conclusion that there really weren't any great products out there. And especially there weren't any great products for the recipient of the actual booking service. And so I think he saw this as an opportunity for disruption. So he rated his 401k, he took out all his savings, he didn't raise any money.
It's a lot of penalties taking out.
Money in a short period of time. That's a very good point. I've never asked him about that. And hired an outside development firm actually out of the Ukraine. to build the first version of Calendly. So that's the background on Calendly. Why it's important is that the first 10 users were actually customer success agents at a company in the education space that contracted with the same firm that Top was using to build Calendly. So he really found his first set of users through the firm that he was using to build the product. And then those CSMs or customer success managers were actually using Calendly to schedule calls with parents in K through 12 and, you know, K through 12 education. And so then those parents started using Calendly for their own parent-teacher conference scheduling. And then from there, you know, school started using it, and then all the parents within the school started using it for lots of other use cases, and it kind of grew organically from there. So that was one piece. I think the other piece that's really important is that he started off by, you know, just give having a free tier. The entire product was free. some of this came from honestly not being able to actually build the billing infrastructure that would be required to actually charge. So it came a little bit out of necessity, but it was also free. So not only was it a, you know, a better product than the Alternatives out there, but it was also free. So the combination of the viral Loop and kind of coming in through getting those first 10, 10 users as part of the, the firm he was using and then sort of the free aspect or, I think, what, what led to the first 2000 and and 10,000 and millions of users from there.
That is crazy. I have never heard a story like that where the team that is building your product ends up being the source of initial growth. I know. Pretty crazy. Oh my God. So many nice things happening in the history of Calendly.
I know.
And wow in Ukraine. So I'm actually from Ukraine.
Oh nice.
That's awesome.
That's pretty cool.
Yeah.
They're great.
Railsware. Yeah. And it's also interesting that it's rare that you hear a successful business starts with contractor engineers. It's often like I think YC is like, do not do that. So that's a cool counter example of it can actually work out, especially if they're your first users and spread it.
To all your friends. You know, we also, we still work with them and they're fantastic and they have incredible engineers.
So they're still part of our culture, which is great. So Calendly got big in Ukraine, sounds like an issue. There you go. There you go. What's something that would surprise people in terms of how Calendly grows today or.
Grew through its history? Most people probably think about Calendly as the scheduling link and really for individual users. to reduce the back and forth of email and scheduling, right? So they think of that one on one use case. And I think people would be surprised to learn that our teams business, so multiple users in an organization who want to collaboratively schedule together is growing much faster than our solo user business. And that's really where the future of where we think growth will come from is, you know, supporting these teams of users who are in externally facing roles and selling into departments and supporting multi-departmental deployments. of Calendly across an entire organization. So I think it's still really well known as this sort of solo user tool to eliminate the back and forth of email. But the growth of what we're seeing, where we think it's going to go, is actually more teams of users and departments of users and then multiple departments in an organization.
It's interesting when you hear the story of Calendly that just has so many good things happening. Basically for free, it just grows so well. I think people don't realize you eventually will... that'll slow down. taper off. Eventually you'll need to drive growth very actively in these new ways that you're describing. And I think people don't often realize that they just want to find something that was viral and then, you know, things are going to go great, but tapers off.
Yeah, I mean, you get to a, there's only so many people who, you know, solo users who are going to pull out a credit card. And I think once you also get to, you know, hundreds of millions of dollars of revenue scale, just the law of large numbers means that growth will slow. And so you kind of have to figure out where's that next growth curve going to come from? I think the beauty of Calendly is that while we certainly have built features and functionality to support teams and departments, we got pulled there, right? It wasn't one of those things where we sort of said, we need to find our next growth lever. Let's go, you know, build X. Our customers really pulled us there by the way that they were using the product. And so again, a very fortunate position to be in, but when you can kind of see in the data and see how customers are using it that they want to be working on scheduling with their teams. That was how we sort of saw early sign that that's kind of where the business was going to go in the future.
I don't think I mentioned this. I'm a paying user of Calendly. It's what I use for booking these podcast episodes. All right. You got me. I think I started when it was totally free and I was like, how do these, how will they ever make money? This is too much power.
And then now you learned that it was free almost by accident.
Yep. I was like, yeah, please take my money. This makes my life easier. What are some fun or unique traditions and cultural kind of components of the Calanely product team?
A couple of fun ones I thought we could talk about. One, we have a meeting called OPA, which stands for opportunity problem, opportunity slash problem assessment. And so what this is, is a meeting where basically PMs, I don't even go to it, it's a meeting for PMs to really debate and discuss with each other and kind of spar around, you know, either areas and problems that they want to to go investigate or after they've gotten data back or research back from evaluating an opportunity, deciding whether we actually want to move forward and go try to develop a solution. So it's really early in the product development life cycle of letting product managers really get into a room with each other on a frequent basis and just think through things, debate, discuss. And I know that they all get a lot of value out of that.
Reminds me of something just like a bad version of that. I had a friend who was a PM at Zynga. and he said there's a meeting where PMs present their plans to all the other PMs. And he's like, it was like, like you're like in a shark tank where everyone's coming to destroy you. They just point out all the problems. That's all it ever is.
And this, I would say on this one, it's kind of the opposite where I feel like everyone really needs the meeting. You know, they're like, oh, I really need to take this to OPA because I need to, I'm working through these problems and I really want to bounce it off of other people. So I think I could imagine a world where it would be like that. Actually, part of the reason I don't go to the meeting is I really want everyone to be able to be open and transparent and provide feedback and not feel like there's any sort of judgment from me or any sort of needing to act a certain way because I'm in the room. So that's sort of why I intentionally don't go. Another fun one we do is something we call competitive war gaming. So, you know, on a, some sort of time intervals, at times it's been quarterly, we'll have assigned people into groups for the quarter to own a competitor. And their job is to essentially, you know, spend a lot of time immersing themselves in to the product of the competitor, really trying to think through the lens of do a SWOT analysis, really try to think through the lens of where's this competitor going and, you know, how should we count only think about that as it relates to our strategy. And so we spent a quarter doing that, and then we have sort of the competitive war gaming day where every team comes and presents and there's prizes and it's a lot of fun, but it's a really great way to stay on top of what's happening across the market without, you know, sort of requiring every product manager designer to be in the weeds on a lot of different competitors. We can kind of bring all of that knowledge together through what we call competitive war gaming.
That is cool. It's really impressive how you do these exercises and they seem really positive and friendly and constructive. It sounds like it's kind of a, there's a pretty unique culture at Calley. I'm curious if there's anything else that's kind of core to the values or the way that you think about the.
Principles of building product at Calley. What I touched on earlier is really core to how we build product, which is honing in on this target. user and honing in on our target market. I do think it's quite rare. I think at most organizations that I've seen, I think there's a desire to do that. But I think again, when it pushed comes to shove, it's really hard for executives to make decisions that say no to things. One of Calley's actually core principles is focus wisely. It's pretty deeply embedded into our culture. And so I think it, you know, one of the reasons that I've been successful in being able to create the clarity around who the target personas are is because I think it's embedded into the culture of Calley to focus wisely. So I don't know that it would work in every organization. I think many organizations really struggle to say no, and they're kind of, you know, always adding more onto the plate versus taking off. But I do think if you, you know, from an ethos perspective, there is something around focusing and the ability to focus to therefore deliver the highest quality of product that you can to your target customers. that is unique. And I think it starts with, you know, some of the broader cultural paradigms that exist at the company. And then we've now embedded that into.
The way we think about how we build product. Is there anything else you do to instill that? Sounds like it's a core value. Do you put posters around the office?
How else do you keep people focused? We're a fully remote company. So now you've got my brain going on, are there, you know, some sort of virtual sticky notes that you could get people to put onto their laptops to remind them?
Just show us.
Yeah, exactly. Yeah. It's embedded into a lot of the documentation, right? So it's embedded into the templates that I talked about in terms of when, you know, everything from sort of the way we structure that OPA document that folks are going to be, you know, working on and debating too when they go to create the actual sort of PRD, you know, when teams come in to present as part of, you know, sort of our product reviews, you know, we sort of, we have a template that sort sort of keeps reinforcing who's the target customer, who's the target user within that customer base, what are their needs, and how are we going to solve their needs better than any alternative that there is on the market. So I think there's lots of different kind of reinforcing mechanisms to that focus.
I feel like sometimes things like that come from a big problem the company had, and then you index way the other side, like focus, here's the four people we will build for becomes instilled in the culture.
And I think you're right, right? I mean, because Calendly started as such a horizontal product, which Amazing because that's how it grew so virally, right? And so it had the entry, the wedge into scheduling and how we sort of our first horizon and becoming the best horizontal scheduling automation platform was because we had that horizontal focus. And so it was, it was a blessing. But as we think about sort of transitioning to horizon two, which is really about deepening our support for these, you know, teams and departmental users as well as verticals, that's, I think, the inflection point where we said, in order to shift us from horizon one to horizon two, we need to be making some real trade-off decisions and we need to create this focus so that we can actually allow teams to go do that. So I think it's actually, it's a really good point. We sort of had to create clarity around focus because we were trying to make a shift from broad horizontal platform serving lots of users to a deeper investment into specific users and specific teams of users within departments.
Before Calley, you were at Box, before that you were at Glassdoor. I'm going to ask two different questions. You can pick which direction you want to go. What would you say are kind of the biggest differences culturally between these three? Like if you had to bucket, here's how I describe Glassdoor, Box, Calley. Or what did you take from those two places that kind of that you bring with you to Calley and future opportunities?
I love this question. So they're all different, which is why I just feel so fortunate to have had experiences that were all quite different. So starting with Box, maybe I'll take your second question. Bokx when I joined, we were in the process of moving up market and trying to capture as much enterprise market share as possible. And I was on the enterprise product management team. So I spent a lot of time, as I mentioned earlier, talking to customers. And in my first year in particular, trying to ramp on the business. And I'd say my biggest learning during that time was around how to ask the right questions to really understand the why behind what a customer was asking for. And then figuring out how to build a solution to their problem that would also meet the needs of a broader swath of customers. It became very clear early to me if I would just go build what customer A wanted and what customer B wanted and customer C wanted, not only would that be wasted effort to do it three times, but more importantly, what they wanted me to go build was going to have a negative impact on the end user experience. And preserving that end user experience was so critical. So, you know, learning how to ask the right questions to understand the actual problem and then build the solution that's going to be most scalable to to that problem set across lots of customers was probably my biggest learning from Box. Moving to Glassdoor, totally different business model, right? Glassdoor is actually really more of a consumer business and 60 million unique users go to Glassdoor every month and it's a marketplace between job seekers and employers and it's highly, highly dependent on the consumer engagement, right? Growing traffic, getting that traffic to come and engage and apply to jobs. And so during my time as CPO there, I was responsible now for both sides of that the marketplace, right? The consumer business and the B2B. And so I learned all about, you know, sort of how do you build consumer products? How do you think about optimization of a funnel? How do you think about building up a growth team and growth as a discipline? How do you use data and AB testing to make decisions? So I think that kind of consumer mentality and how you approach product, I then have brought with me to Calendly, which is really a blend of both, right? Calendly is First, as we've talked about, a PLG business and it looks a lot more like a consumer business, like Glassdoor. And then it's got this direct selling business that looks a lot more like Box's enterprise business. So I think I've been able to take kind of lessons learned from both.
Box and Glassdoor and kind of apply them together to Calendly. What a cool set of experiences. I'm trying to imagine you using all three in the same day, sending a Calendly, storing your files in a box, and looking at reviews.
And recruiting.
And recruiting. Yeah, yeah. Not looking for anything new. Okay, final question. You're part of something called the skip community, which I believe Nikhil and a few people run. And so I'd love to just hear a little bit about that and maybe how folks can join if they might be a fit.
Yeah, as you mentioned, about, about two years ago, Nikhil, who is the former CPO at Credit Karma and is now a VP of product at Meta, got a small group of CPOs together who were all kind of going through. similar phases of companies' growth, right? Late stage growth companies. And, you know, we all were facing the same challenges in our roles and he kind of formalized this community as a way to help us kind of gather advice from one another, you know, talk through how to manage challenges we're facing and just make us more successful in the roles. And we always joke, you know, we're like the support group. We meet on Sundays and it has been incredibly valuable as I've sort of, you know, gone through the last couple of years in my role at Calamity Since then, we've grown the group to about 23 heads of products and CPOs and expanded the charter a bit, which I think is interesting to kind of help product leaders not just be successful in their current role, but also how to think about setting them up for success in the role after this. Right? And so we're experimenting with a couple different interesting ways to help product leaders grow. One of them is, you know, we're actually partnering with some companies right now to experiment with how can we help them as they're looking to make their first head of product hire or their first CPO hire, really hone in on what they're looking for and partnering with some talent partners we know to really try to increase the success that they find the right candidates. That's something interesting we're doing. We also recently launched a podcast covering some topics like, you know, how do you manage the next job search? How do you avoid burnout? Breaking down things like equity and other kind of, you know, timely topics. And then also we just have an active a Discord server where we've got all sorts of channels from topics like how to, you know, manage the CEO/ CPO partnership, compensation, you know, even sharing planning, even sharing some advising opportunities or other CPO roles that, you know, kind of come across our radar. So it's been a really, really cool kind of experiment to see how the power of the community, I know Lenny, you do a ton of stuff around community, you know, how that has helped all of us, I think you Effective in our roles and, and feel like we have a group of people who are behind us supporting us during, you know, what is a very hard role.
I love this. I imagine when people look at a CPO, they imagine they just like know everything already. They have a bunch of friends in the same role, but I think in reality it's like kind of a lonely role a lot of times. And so I could see the power of something like this just to help people understand who, who would be a good fit for this. How do they go find it? and yeah, what's like the site?
And the best thing to do is just follow the skip community on LinkedIn. And then, you know, we're, you know, sort of targeting sort of head of products at, you know, call it series B, C and beyond up to, you know, late stage growth companies and up to CPOs. So I'd say start by kind of following the skip community. And if you see folks in there who are in the group, you know, reach out to them to get a sense of what it's like and what it would be like to join And.
Then it sounds like if you're a company hiring a CPO, maybe reach out.
To or... Yeah, that'd be great.
That'd be great. Yeah. Okay. And they do that by going to LinkedIn also and looking for the skip community? Yeah, that'd be great. Okay, cool. We'll put all the links in the show notes as well. Well, with that, we've reached our very exciting lightning round. I've got six questions for you. Are you ready? Let's do it.
What are two or three books that you recommend most to other people? Playing to win.
So I referenced that one earlier. Good to great.
And hooked. Awesome.
What's a favorite other podcast that you enjoy other than maybe this podcast?
I think I got introduced to you by Harry from the 20 VC, I think. But if not, either way, I'll cross promote his podcast, which is a great one.
Yeah, Harry is responsible for this podcast. I was on his podcast and he's.
Like, Lenny, you should be doing it. I love it.
He's the godfather of this podcast. He is. That's great. What's a favorite recent movie or TV show and you cannot say Wait, Lotus?
I have two young kids, so whether I like it or not, Sing 2. It's a great movie, especially if you have young children. Sing 2.
So it's like the second of Sing? It is. It is.
Distinct from Sing 1. Sing 2 is better. It's better.
Okay, cool. I haven't seen it.
I would hope you haven't.
Okay, cool. Favorite interview question that you like to.
Ask people you interview? Talk me through your biggest product flop. What happened and what did you do about it?
What do you look for in an answer? What's like a sign of something good in their answer?
People being brutally honest around how bad it was and why it failed. You know, the rest of the interview, they're trying to tell you all the wonderful things they did and all the accomplishments they had. And so I think the rawer the answer in terms of how bad it was and why, the better.
Awesome. Next question I think you might have answered, but what are top five SaaS products to use day to day either at work Chrome, whatever.
Slack, Miro, Loom, Pendo, and Confluence.
Awesome. These are actually unlike other people's answers, so that's really interesting. Kind of a unique stack you got there.
Love it.
Final question, what's your best Calendly probe tip?
Yeah, so we just launched a new feature that I'm loving personally called Customize Once and Share. So this really allows you to make changes on the fly to an like an event type and tweak things like title or duration or, you know, override a date based on the person you're actually sending it to without having to go create a brand new event type just to make one small change based on the recipient. So it's kind of that, you know, one-off use case where you need to make a little bit of a change on the fly depending on who you're sending it to, but you don't want to go through the effort of creating a brand new event type.
So I'm loving it. You should check it out. That is awesome. I need that. Find that I need to block dates out and change times and I just like go do that on my calendar versus accounting.
There you go.
All right. Annie, this is amazing. We learned a ton about Calendly growth, product building, two final questions. Where can people find you online if they want to learn more and reach out, maybe ask some questions? And two, how can listeners be useful to you?
Finding me best place online is LinkedIn. And then in terms of being helpful to me, one, We're hiring at Calendly, so explore open roles on the product team at Calendly if you're interested. Share any feedback for me on this episode at a.perl@calendly.com, and then as we talked about, would love to have you.
Follow the Skip community on LinkedIn as well. Awesome. We'll have all those links in the show notes. Annie, thank you again for being here.
Thank you so much, Lenny.
Bye, everyone. Thank you so much for listening. If you found this valuable, You can subscribe to the show on Apple Podcasts, Spotify, or your favorite podcast app. Also, please consider giving us a rating or leaving a review, as that really helps other listeners find the podcast. You can find all past episodes or learn more about the show at lenniespodcast.com See you in the next episode.
More from Lenny


How Meta designed Muse: an AI agent people actually want to talk to | Alex Cornell (Design Director)


Why every company now needs to think and operate like a lab team | Josh Woodward (Google Labs, Gemini, AI Studio)


Jev: 8 real use cases for the fastest, cheapest model I’ve ever used | John Lindquist


The grief, loneliness, and burnout sweeping through the tech industry right now | Molly Graham






