The Cadence: How to Turn Your SaaS Startup into an Army w/Craft Ventures General Partner David Sacks

doing. But when you start growing above 50 employees and certainly get to 100, things change. You now have teams, which means you have functional leaders. You— rather than the CEO running around telling the engineers exactly what to build, you now have product managers. And so the company starts getting divided up into functional areas or silos— product management, sales, customer support, marketing, and so on. This siloing of the org chart, I think, means that not everyone knows what everyone else is doing, and there's a general feeling of disorganization or chaos in most startups. Really, the better the startup is doing, the more chaos there is because they're growing faster. This isn't a problem that you solve by not growing fast. It's actually caused by growing fast. Probably the topic that I get asked about the most over the past 20 years based on my operating experience is just kind of how do we kind of get more organized? How do we solve this? Wouldn't it be nice if somehow we could turn this shit show into an army where we could get every— instead of having this startup chaos, we get the team working in lockstep rather than having this feeling of disconnected functional areas. Everyone in the company knows what to work on. And rather than having this sort of erratic schedule around hitting sales targets or hitting releases, that there's a feeling that just quarter after quarter, the company keeps shipping and selling. And to me, that's what the cadence is. I learned this operating myself. First, I was the founding era CEO of PayPal during the PayPal Mafia period. I was a self-taught product person, and learned how to do product management operations there. Then my next company, I founded Yammer, I was the CEO, and we adapted this operating philosophy for a SaaS company. We had to learn how to do sales and sales marketing, compete in heads-up battles against other companies selling similar products. We refined the cadence then, and it worked extremely well. I mean, we went from zero to $56 million in sales in under 4 years, and that resulted in a unicorn. We ended up selling the company to Microsoft in 2012 for $1.2 billion. I think to this day, it's actually the fastest unicorn SaaS exit. Now, during that time, we were competing against Salesforce. They had a competing product called Chatter. And so we studied what they were doing very closely. I read, Marc Benioff has a great book called Behind the Cloud, which I recommend to everybody. And so we learned and adapted key elements of their system and incorporated it into this cadence. And Salesforce is the most successful cloud software company. And so it's worth, I think, learning from the things that they've done. So what is the cadence? There are basically— it's based on a few very, very simple insights, but very few startups are actually doing these things. So the first insight is that there's two key systems in a startup. The first system is what I call the sales finance system. And the second system is what I call the product marketing system. Both of these systems, in my view, run better on a quarterly cycle. and they should be planned on a quarterly cycle. And then the final, the third insight is that, well, if you've got these two systems, they're running on a quarterly cycle, if you just snap them together with a slight offset, we'll talk about that, you can then create a single operating cadence for the company. It's very simple. I mean, this is something that every startup can do. And when a startup kind of deteriorates into the thing I call the shit show, it's always because one of these groups or one of these systems is either it's not being run the way it needs to or it's not being snapped into alignment with the other systems. All right, so let's, let's take, talk about each of these systems and functional areas and then I'll explain how they all snap together. So the first system is a sales finance system. And so let's start with sales. So sales, in my view, is best run on a quarterly plan. It's— you can kind of get there by process of elimination. The two other ways to run a sales team is you can run them on sort of annual quotas, or you can run them on monthly quotas. And in my experience, annual quotas are just too slow to judge performance. It doesn't let you make modifications and adjustments mid-course if you have to wait till the whole year is over. By the same token, monthly plans are too volatile. You know, some startups can do monthly quotas if they have an extremely quick sales cycle, but otherwise, for the vast majority of startups, you want to be on a quarterly quota plan. And then the other thing you want to take consideration is that, you know, if you adjust quotas and territories more than once a quarter, you'll really start to affect the morale of the sales team. They'll, they'll start feeling undermined. So the first part of the, the, the sales finance system is to recognize that sales must be on a quarterly plan. And then that allows you to create a series of milestones within each quarter. So, you know, every quarter is going to start off the same. You're going to start off with the sales kickoff. At that kickoff, the, the sales team is going to receive their plans or territories. If there's any company objectives or, or SPIFs, things that the company wants to incentivize, those things will be covered then. And you're going to do some significant retraining. You're going to retrain the the sales team on the product. You're going to train the, the, uh, the sales team on any best practices. If some reps have been particularly effective, you're going to want to share those learnings, that wisdom, across the group. Um, the second month, mid-quarter, you're doing a lot of pipeline inspections. You're, you're the sales leader making sure the team's going to hit their, their goal. They're making adjustments, giving advice in terms of how to, how to, um, uh, in terms of like how to actually close those deals. And then we'll talk about this in a minute, but the marketing and product are generating news in the second month of the quarter, and sales can use that news to warm up prospects, email them news collateral, um, you know, awards recognition that the company is getting, and use that to help put deals over the top. And then the third month, you really want to avoid distractions. The team should just be head down on closing and making their number. So that's the sales calendar. The sales calendar is part of one system with the finance calendar. And I mean, this is pretty, I think, obvious and intuitive as well. But the starting point for the finance calendar is to understand that there is a fiscal year, a sort of financial or accounting-based fiscal year for the company. And the question really is, well, there's only two choices for that. You can have a fiscal year that ends on December 31st or with a calendar year, or you can have one that ends on January 31st. And my recommendation for most SaaS companies is that you want to have a January 31st fiscal year for the simple reason that you don't want to be closing deals during and having the entire year's numbers. A lot of deals will come down to the wire. You don't want to be scrambling during that, you know, Christmas to New Year's week when, you know, everyone's on vacation. It's more humane for for your sales reps to not make them work during that week or to have their quotas depend on that. But also, it's very hard to get a hold of prospects during that time. And so I recommend generally January 31st. You'll also avoid kind of being, you know, smart prospects will know at the end of the year to demand discounts because they know that if the vendor is scrambling to close deals to hit some number, they can get a better discount and you'll be in a better position of leverage if you're not having to give year-end discounts. So I generally recommend January 31st, and then that means that your sales quarters that we talked about will be based on that fiscal year end. So now you can basically say, okay, well, look, if I've got the Q4 is gonna end now on January 31st, so that means that my Q1, my quarter end is gonna be now February, March, April, and then so it's April is the next quarter. And then May, June, July. So July is the next quarter end. And then August, September, October. October is the next quarter end. So we can now essentially snap the sales quarters to the fiscal year. And you want to do this for reporting reasons, right? I mean, so if the finance team will close the books on each fiscal quarter, report that to the board, you don't want to be reporting sort of incomplete sort of mid-quarter sales numbers. You'll have a much better idea of what's happening in the business. If you're reporting, if your sales quarters are snapped to the fiscal year. And then the final thing I like to do as part of the finance calendar is make board meetings, because you want the board to review the information while it's still fresh. And so I like to see board meetings, but typically quarterly board meetings occur 2 to 3 weeks after the close of these quarters that we talked about, when the results are fresh, there's something to talk about, and now the team can get strategic insights from the board right at the beginning of the next quarter, and there's still time to implement them for that quarter. So that's the finance calendar, and the combination of sales and finance working together is what I call the sales finance system. So let's shift gears to the second system. It's the product and marketing system and the product calendar. So, you know, the product calendar, you know, I want to tell you about my philosophy on product management. and this is something I learned at PayPal and then refined at Yammer— is, you know, a lot of people, a lot of founders, I should say, resist the idea of having sort of planned quarters around product management. And I've really learned this is a good thing to do. You know, again, when you're in that seed stage, when the founder can just run around and tell engineers what to build, that's fine. But again, we're talking about the time in a company's life when they're expanding from 50 to 500. And just having the CEO running around every day or every week, telling people what to do just doesn't scale. And so you need product managers, and those product managers I've learned work best on a quarterly calendar. So the analogy you can use is, let's say that you wanna fill a jar with rocks, pebbles, and sand, and kind of this graphic here down on the bottom right. How do you do it? You see the jar on the left here, they weren't able to fit the rocks in the jar because they filled up the sand first, then they put in the pebbles, and then they did the rocks. The right way to do this is to put the big stuff in first, the rocks, then you put in the pebbles, then you put in the sand. Product management is a lot like that, where what you're trying to do is maximize It's about resource planning, right? As you're trying to maximize the amount of stuff that you can get pushed through the system with a fixed amount of resources. Um, it's about maximizing that. And what I found is that companies that don't think in terms of a quarterly product management calendar, one of two things happens. Number one, they just ship sand, right? They don't think in terms of shipping 10-pole features, new products, major releases. Or when they do, they end up going wildly, wildly over schedule. So they'll put together— they'll ship a new product, but because they never really planned it, they didn't scope it correctly. And so you'll be talking about a product that should have taken or was supposed to take one quarter, and you'll still be doing it 2, 3, 4 quarters later. I've seen V2s that were supposed to take a couple of quarters end up being literally years late. And it paralyzed the development roadmap of the company. So product management is useful to make sure that you actually do big stuff. You don't just get the sand done, you actually get some big rocks in there. But it also helps you make sure you're scoping correctly. And the rule we had at Yammer is that every project we would assign somewhere between 2 and 10 engineers for 2 to 10 weeks. And so the absolute biggest project that we could ever do would be 10 engineers for 10 weeks. And, um, and that would be for the absolute most strategic priority. We would just say the max is 10 engineers, 10 weeks. And if we couldn't do that, the prod— the product needs to be rescoped. It needs to be shrunk down into something that we could— that 10 engineers could ship in 10 weeks, that we could put in front of users, get feedback about whether they like the product before we then went on. To the next round. And, um, and so, you know, this is what— this is the system that, that we've used. And again, you know, what having a product management calendar does is allow you to think in terms of what are the rocks, what are the pebbles, what are the sand. Let's fill up that jar with rocks first, then pebbles, then sand. You will actually get more done, like the jar on the right as opposed to the jar on the left. You will actually fit more through your roadmap. Moving on to the marketing calendar, the marketing calendar, I guess a couple of key points here. One is that marketing and product, those calendars are one system for the obvious reason that startups are product-driven and most news that the company puts out will feed off of new products new product releases. And so marketing is really going to piggyback off of the product management calendar. It's going to be, you know, marketing those product features, and those product features should be the centerpiece of marketing events. You know, I also believe that for marketing purposes, having 4 big releases is better than having 52 small ones. It's not to say you can't ship code weekly or even daily, but in terms of for marketing purposes and for planning, for product management purposes, you really want to think in terms of a big seasonal release. And that's what Salesforce has done very effectively for 20 years, is that they have a, you know, winter, spring, summer, fall release. And they— it's just the compounding effect of that has been huge. The other thing you want to think of for marketing purposes is you really want to have an event-based marketing calendar. Together. And I don't know why more startups and more founders don't do this. Some of the most successful founder CEOs that we've ever had in our industry have used this technique of event-based marketing. So Steve Jobs, I mean, the big— the iPhone release that you think about, the big product releases that Apple's done, they were always based around events. Marc Benioff with Dreamforce, now the largest tech conference. And obviously Elon, whenever he puts out a new product, It's based on a live product demo. And so, you know, having an event-based marketing calendar, I think it does a number of really important things. Number one, it combines— there's so much clutter in the world right now that just putting out a press release doesn't get it done. When you can combine the press release, that news, with an event, you bring together customers and fans and influencers, and you combine it with a live demo. You don't just put out a press release, you create what's called a lightning strike. It's much more compelling. The next thing though is that there's an internal benefit, a huge internal benefit to the company in terms of setting dates correct, setting dates, setting deadlines in advance. The deadline, the date for these events gets set well in advance. And so if the folks at Tesla know that Elon's going to be going on stage, to present the Model 3, they've got to hit that deadline. Same thing with, you know, Marc Benioff at Dreamforce. Knowing that you're sending your CEO on stage with that product is tremendously motivating for the team inside the company. They know they have to hit those deadlines. And then finally, it forces the leader of the company, not just the team, but the leader of the company to think about prioritization and what's really important in a different way, because you, the leader, are going to have to go on stage and present and explain this big product announcement, and you're going to have to effectively justify why it matters. And so it forces the leader of the startup to think months in advance about what is going to be important to customers. And what I find is that if you, if you think about the product marketing calendar this way, it makes it a little bit more like the sales finance calendar where, you know, sales is about Sales is about selling to customers. You know, sales doesn't work unless the customer buys what you're selling. And I think that that's a good dynamic. You get market feedback. And I think having to think about the customer and their reaction while you're doing the product and marketing planning is a very good thought exercise for the company. So that's sort of— that's sort of— that's sort of That's sort of, you know, how the product and marketing system works. Now let's talk about how you snap these two systems together. The most important concept here is very simple, is that you want to have an offset, say a half quarter. You don't want the product marketing system for their major event, for their launch event, to be coming due at the exact same time that the sales quarter is sort of coming due. You don't want to light everyone's hair on fire at the same time. Creates too much chaos inside the organization. Also, you know, it's not good change management. You don't want the product and the product demos changing right when, uh, when sales is trying to close deals. You want some stability in the product. Um, and by the same token, when you have these big, uh, lightning strike events in the middle of the quarter, sales can then use— that usually comes with a bunch of positive press coverage, and sales can take those articles, they can email them to prospects, they can use it to warm up prospects who've gone cold, or they can use it to help, you know, further deals, to help put deals over the top. So it's just a much more useful time. And so if you think about these two systems, you just want to offset them by about half a quarter. Okay. So now let's think about, well, how are we snapping this together? Number one, you're going to decide your fiscal year. It's going to be December 31st or January 31st. And then you're going to snap the fiscal quarters to that. That will snap the sales quarters to it. And then you're going to snap your event schedule so that events occur in the middle of the quarter. And then you're going to plan your R&D cycle to hit those event deadlines. It's very, very simple. But this will give you a superstructure for everything happening inside of the company. Now, you know, one objection that I get to this, I know a lot of you think that, you know, when you hear about events that you think no one's going to come to your event. That's what I thought of Yammer is that we decided we're going to do this thing called YamJam, and we made it our annual user conference. We were very worried that no one would care and no one would show up, but you would be surprised even in our second year as a startup that a large number of people showed up. If you have product-market fit sufficient to raise a Series A, Series B, and you're scaling from 50 to 500, employees, you have a fan base out there, you have a community, and you can engage them. And you may start small, it may only be a few dozen people at this event, but it will grow. And, you know, just look at Dreamforce, you know, um, you know, the, the products that, that Elon and Tesla have rolled out and what, what Steve Jobs did at Apple, though obviously those are very sexy products, but you know what, what Marc Benioff has done at, at at Salesforce, you know, that's CRM. It's not inherently the most exciting product, it's business software. And yet they've been able to, you know, starting from very modest beginnings, they've been able to turn that into the largest tech conference. And so you will get people to turn up at your event. And what I recommend here is, you know, one user conference a year, and then 3 smaller webinars or city events. Doesn't have to be a huge event for the other quarters, but again, it just, it forces that discipline. Around making sure that what you're working on matters. So let's translate this. So now you snapped these two systems together. Let's kind of just quickly review what's going to be happening in a quarter. And the amazing thing about the cadence is I can tell you what's going to be happening inside your startup, inside a SaaS startup, without even knowing what software problem your business is addressing. But if you're using the cadence, you will be marching to the speed and you'll be well organized. So every month, month 1, it's going to be dominated by the idea of planning. And so you're going to start off with a sales kickoff. There's going to be, you know, prep for that sales kickoff. And at the sales kickoff, you're going to get new sales plans, territories, and closing to be finalized. Meanwhile, the finance team is closing out the quarter. Um, and by the way, the PMs are presenting at the sales kickoff, they're basically retraining or training up the sales reps on the latest changes in the product and what's coming out next, because selling your product roadmap is a very important part of the sales process as well. So you're going to have this cross-functional opportunity at all these events for, for those kinds of interactions. Next, you're going to have board meeting prep, and you're going to have the board meeting. And then immediately on the heels of that board meeting, you're going to want to feed those strategic insights that you talked about into— back into the company. And typically you're going to do a product roadmap prioritization for the next quarter's launch event, not for the one that's just about to happen, but for the next quarter. Meanwhile, code freeze and QA are beginning for the launch event that you're about to do in month 2. So month 2 is going to be dominated by, you know, say in week 7 you're going to do this event. It's either going to be your user conference, or it's going to be a city event, or In the days of COVID it could just be a webinar. That's fine. But you're going to basically have this, this launch event, and the first couple weeks of month 2 are going to be dominated by people getting ready for that. You know, the marketing collateral is going to get finalized, the event prep, event details are going to get finalized. You might be, you know, you're certainly going to be doing QA and testing on the release. You might be in closed beta with some customers. And then the other thing that's happening though is that the product managers should be racing ahead to be getting ready for what's happening next quarter. And they might start— they'll be working on specs and design reviews for what's happening for the next quarter. At the end of the month, at the end of month 2, you're going to want to debrief. You've just done this big launch event. How did it go? What were the learnings? You may have convened your customer advisory board. What did they say? You're going to want to debrief and internalize those lessons. You're going to want to do recognition inside the company. You're going to want to recognize the people who made it all happen. There should be some celebration. Normally, you know, there are good things to celebrate. You just did a big launch event. And so recognizing and celebrating that accomplishment is a good thing to do. Like I mentioned, sales reps can now use the marketing news that you just generated at this event to warm up leads. And the engineering team is going to be really busy if you've just done a big launch event and you've just done a big launch, there's going to be bug fixes. And so for a week or so after launch, they're going to be busy doing that. Meanwhile, the PMs are finalizing the next quarter's, uh, launch, next quarter's release. And then finally, you've got the third month of the quarter, which is really a heads-down period in inside the company. So what's happening in month 3 is that the sales reps are really focused on just closing deals. You want minimal distractions for the sales reps. And then coding is going to begin, uh, if it hasn't already, for the next quarter's release. Remember that in month 2, the PMs and designers really finalized their part of the release, the planning, and now coding begins in earnest. And so month 3 is really this heads-down period where people are just cranking out code and closing deals. And that's basically the quarter. And then, you know, you start again with, you know, right back at it. And, you know, now you're at the beginning of the next quarter and you're right back at sales kickoff. You've got the quarter-end close, you've got your next board meeting, and so on. So this really creates an operating cadence within the company. And one of the big benefits of the cadence is I think it has important cultural benefits. And so there's this old debate about culture inside of startups, which is, well, should a startup be run like a sprint or a marathon? And you'll hear founders defend both approaches. And my view on this is actually, which one is better? I would say Neither. I think that the best approach is ladders. And so, you know, for people who are into fitness, you know, ladders are when you sprint for a while and you do a sprint and then you rest, you let your heartbeat return to its resting rate, and then you repeat, and then you do it again. If you try to run— the fact of the matter is that startups do take a long time. I mean, they're an infinite game. And if you try to just run it as a sprint without rest, you will burn people out. Conversely, if you have this attitude that it's just a marathon, I do think that is a recipe for going slow. And so to me, ladders are the right balance culturally. Let the team, you know, sprint, hit this big launch, you know, let the sales team, let them sprint to hitting their quarter end. But then you have a recovery period. You know, you have the sales kickoff, you have that week, you have that week after the big launch event where you're letting people celebrate the accomplishments. Reflect on what has happened, and then you do it again. So let me kind of just summarize here, and then I can— happy to take, take questions. So, you know, what is the cadence? I think the cadence is 4 sort of key calendars in the company, which consolidate into 2 synchronized systems, and then 1 operating cadence when you have those 2 systems working in tandem with each other with sort of this half-quarter offset. I think human beings are wired to think in terms of seasons and quarters, and I think this is like a very natural way for all of us to work, is, is in terms of these quarterly planning cycles. The first system, the sales finance system, really orients around the quarterly close as its central event, what it's building up to. And then System 2, the product marketing schedule or system, is oriented around this big launch event. You want to use these two systems in tandem with each other. Whenever you have an event, it's an opportunity to synchronize people inside of the company around cross-functional collaboration. So like I mentioned, you know, the product managers are going to speak at the SKO, and I also believe in the sales reps attending, you know, say virtually, you know, through streaming, uh, any of these product launches. I think it's very important to involve the whole company in these big events And then what you're going to want to do is, you know, if you think about your all-hands meetings, you're going to want to work backwards from these events. And so, you know, knowing that these are the big milestones inside the quarter, you almost know exactly what each all-hands is going to be about. So, you know, after the quarter close, you're going to do an all-hands meeting to review, you know, the results, what just happened. The, you know, the all-hands meeting before the big launch event, you're going to want to preview what's coming out. The all-hands meeting after the launch event, you're going to want to debrief on what you learned. You know, the all-hands meeting after the board meeting, I think it's a good idea to kind of review, you know, what you just talked about with the board. And so you should also be thinking about, you know, what are these key events, because each one creates cross-functional collaboration, but each event, each of these important events also creates the opportunity for an all-hands meeting inside the company so you can keep everybody up to date and synchronized. And then I would just tell you, you know, the compounding effect of shipping just 4 great quarters a year. I know, I know if you're shipping, you know, daily or weekly and you say, well, wait for, you know, and again, I'm not saying you shouldn't just push code live. I think it makes sense just for version control. You want to kind of get, you want to, you want to push code. But again, in terms of the planning cycle, I know it seems like you're getting less done to have 4 lightning strikes or 4 mega launch events compared to 52. But again, think about the rocks versus sand and the compounding effect of implementing the cadence quarter after quarter for years is enormous, because I can tell you most companies in this few hundred employee range or big companies, they're lucky if they have one great launch every year. And so if you can do this quarter after quarter after quarter, the way that Salesforce has, the compounding effect of that will be very big. And then finally, like I mentioned, startups are not a marathon or sprint. Think in terms of ladders. I think you'll be pleasantly surprised culturally what that, what that does for you. Uh, so why don't I pause there and I'm happy to answer any questions. Okay, wait, should be in the right Q&A button. Um, okay, hold on, I gotta find Okay, here we go. All right. Okay, let's see here. Open. All right. Based on your experience, what is the best software to manage the roadmap development Process. That's interesting. Okay, so the crazy thing is that when I was doing PayPal and Yammer, we really just used Excel. We had all the features in a spreadsheet. And the nice thing is you could just very easily copy and paste them, the rows, into different releases. Now there's much better software for that. Disclosure, I'm a small investor in Productboard. So they're, you know, they're some pretty robust software for managing the product development process. So you should, you should check them out. And there's a lot of great product management or project management software out there now. And you should, you know, check, check those out. Let's see here. Okay, a lot of questions. Let me— all right. How do you ensure predictability in the ladder, sprint and rust model? Yeah, so the idea behind the ladder is that— well, so each of the systems involve a sprint, right? So product and engineering are sprinting to meet this launch event. Because again, think of it as like, you know, Elon's going on stage, Marc Benioff's going on stage. You have to get the product done by that deadline. You know, otherwise your leader's gonna be standing up there with nothing to show. So you're sprinting to make that deadline. Then you have the big event and that's the opportunity to take a breather. You know, let the whole team watch the event. They don't need to be coding those days. Let them participate in the event, even if it's virtually. Let them celebrate, you know, whatever it is you're going to do to recognize the accomplishments, celebrate, whatever. That's, that's the downtime. That's the breather. Let the heartbeat return to resting and then you can start again. Sales, same thing. They've got this quarterly close. They've got to hit the finance plan. That's very stressful. Hitting quota definitely will elevate the heartbeat of your salespeople. And, you know, so the quarter close happens and then the next week, the next couple of weeks are this again, it's going to be the sales kickoff. You're going to be doing the, you know, they're— that's going to be more of a resting period. They don't have to be on the phone closing deals. They're going to be participating in these workshops and they're going to be getting training and updates and that kind of thing. So, um, so yeah, that, that's the way to implement the ladders. Um, let's see here. Um, okay, a question here: what was the 3rd to 4th year AR growth compared to sales team growth size? Was it 3x, 3x, 2x, 2x for AR growth of the sales team, 2x or 3x in headcount year 4? Thanks for the talk, please. Okay, so yeah, so with Yammer, you know, thanks to our viral freemium model, we, you know, the way we grew is we did about, well, back in those days, not everyone had standardized on ARR. We were standardized on TCV or total contract value. So I remember what the TCV numbers were. So that might be— some of the TCV numbers might have included multi-year deals, but we basically went from $1 million in sales our first full year as a company to $7 million the second, to $21 million, to about $56 million the year that Microsoft bought us. And at the time that Microsoft bought the company, I want to say that we had about 50 AEs. So that should give you a sense. And we had, you know, we had SMB, mid-market, and enterprise teams. So we were attacking all those markets. All right, let's keep going. Okay. What's your perspective on how to best structure the sales comp plan? Number 1, annual target with quarterly objectives. 2, semi-annual with quarterly targets. Or 3, quarterly. I think I would just go with quarterly. So I think it's simplest. Here's the problem with having, you know, an annual plan with quarterly targets is you're going to be learning all sorts of things throughout the year and you're going to be wanting to make adjustments and you may even want to be making adjustments more frequently than quarterly. I'm going to urge you not to because it undermines the confidence of the sales team, but at a minimum, you're going to make— be making quarterly adjustments. And if you've got somebody on an annual plan and all of a sudden you're changing the rules on them quarterly, and it involves their salary or their compensation, you're going to have a big dispute on your hands. So I really like the idea of the sales plans being quarterly so that you can essentially have carte blanche to rewrite those plans every quarter, not more than once a quarter, but every quarter you can rewrite them. Let's see here. A lot of questions about my investments. I really, I like talking about stuff that founders care about as opposed to stuff that investors care about. So I don't, but I'm very interested in bottom-up SaaS and we have some really cool companies that we're doing. Okay, this is really insightful. What tips do you have when the cadence gets broken, product doesn't hit or hits blocker or crisis like COVID? It's interesting, what I found is, if you're implementing the cadence, okay, let's talk about what a miss, would entail. Okay. So there's two kinds of misses. There's a miss in the product marketing system, or there's a miss in the sales system. So the miss on the product marketing system would be more embarrassing in a sense, because you've got this scheduled event, you can't miss it. You know, you don't let anyone ever change the, you know, the time and date of the event. That is a fixed point. Once you set it, you got to hit it. And so the question is, you know, what are you presenting on stage? And what a miss would mean, frankly, is just that you've got less stuff to show. I still think you do it because if, you know, that you don't want the goalposts to change. I think it's really important to set goalposts for the team. But if something doesn't get done in time for the big launch event, it's just gonna, it's gonna, it's gonna drop, it's gonna push to the next quarter. And unfortunately, you're just not gonna be able to include it. But again, if you're doing rocks, pebbles, and sand, you're going to be getting some things done. You're going to have something to show for it. And if you don't, it'll be a painful lesson that lets you reset for the next quarter. Sales, you know, again, it's not all or nothing. You know, you do have this quarter end. You should not let sales change the quarter end just because they're going to miss. Take that miss and learn from it. It just means that you didn't close as many deals as you wanted to. And take that, take that learning into the board meeting and, you know, have that conversation about why why there was a miss. Is that a product-market fit problem? Is it a competitive problem? Is it a sales training issue? What is the reason you missed? I think it's important. One of the reasons why it's so important to operate on the cadence is because it's not saying that you can't miss, but it doesn't let you change the goalposts. And so it forces you to deal with misses the way that you should. Okay, there's a question here. This advice seems more relevant for later stage, post-clear product market fit. Curious, what are the recommendations for seed Series A before clear product market fit to ensure you drive towards product market fit? Okay, I think that that is a good point and it's accurate. I mean, I've really said that the cadence is for the phase of a company's life where you have product managers, you have functional areas, you've got a sales leader, a marketing leader, a product leader, and you need to take this ragtag band of forces and turn them into an army. This is not the right— the cadence doesn't apply to a 10-person startup. What I think I would recommend for the 10-person seed stage startup is it really is more like a guerrilla force, or it's not an army yet. Maybe it is like the Navy SEALs or something, which it should be very experimental. There should not be a lot of overhead. The founder— you may not even have any product managers. You don't necessarily need them. It's really about the founders working with the engineers and the designers and sales, making sales themselves to figure out what is the customer need, and then immediately feeding that back into to the dev cycle. And I guess my big piece of advice for companies, you know, C-stage startups, or, you know, I call this the wilderness period. You may want to check out my blog. It's called The Wilderness Period, where it talks about how to cross the penny gap. And the thing you really got to do for those startups is you got to find the immediate need. You know, what is the one thing that somebody is willing to buy right now? That you got to find that buyer and that immediate need. And then that gives you the wedge or the initial product market fit, the initial wedge into the market. And then you go raise a Series A and then you go do the cadence. So next question, how do you prioritize features to build for your SaaS product? That's something where you got to listen to— that's a tricky thing. That is where founder judgment is required. You obviously want to listen to customers, you want to listen to prospects, but you can't just do that or you'll have the faster horses problem. And so, you know, figuring out what you're going to prioritize is— it very much has to do with some combination of founder vision and what the market is telling you. Next question: are successful SaaS companies sales-led or engineering or product-led? I think it's another great Question. I think that if I had to choose one, I would choose— first of all, they can all be successful. You obviously need all three functional areas to make a SaaS company work. You're going to need engineering, you're going to need sales, you're going to need product. I would say that at Yammer, we were product-driven. My expertise before Yammer were product, and we were very focused on this idea of consumerization of the enterprise. We were product-driven and then learned how to do sales. I think now that model, this kind of consumerized enterprise model, is the dominant model. And so, you know, I like to see founders coming with a lot of product vision, but you're absolutely gonna have to learn to do sales if you want to be successful. And if you don't learn how to do sales, you will not be successful. It's just that simple. Um, let's see here. Um, gosh, there's, I think more questions here I can possibly answer. I think we're supposed to end at 2:50, so— all right, maybe I'll do this. Let's see here. Gosh, there's so many questions. Okay. How do you think about replatforming scenarios where the whole product needs to transition to a new architecture design, could take 1 to 2 years? How would you recommend the process or scheduling it? Okay. So this is what I call the— this is a good one to end on. This is what I call the V2 problem, and maybe it should be called the V2 fallacy. I'm very much against taking 1 to 2 years off to go re-platform. It almost never needs to be done. You should find a way not to do it. It will kill your startup. And one of the reasons why we insisted on this 2 to 10 engineers for 2 to 10 weeks rule at Yammer is because what we found is whatever the unit of time is that you're— that you've got, that you've— that you're measuring how long a feature is going to take, you will be off by at least that amount. So if you're measuring, you know, how long it'll take you to do a feature in days, you'll be late by days. If you're measuring how long it's going to take you to do a feature in weeks, you'll be off by weeks. If it's taking you months, you'll probably be off by a month. And if you think you're— it's going to take you, you years to get a feature done, you will be off by years. It's very important. I don't let— when I was operating, I just would reject the idea that any feature that was going to take quarters was a necessity. Big companies have the luxury of doing that, small startups don't. All right, so why don't I end there? Thanks, everyone. I really appreciate you joining me today.