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

David Sacks outlines a two-system cadence for scaling SaaS startups from 50 to 500 people: sales-finance cycles and product-marketing cycles, offset so product launches land mid-quarter. He uses PayPal and Yammer as examples, and covers comp plans, tooling, and why multi-year rewrites fail.
Questions this video answers
January 31st fiscal year end.
Max 10 engineers for 10 weeks per project (projects should be scoped to fit this limit).
Sales should be run on quarterly quotas (not annual or monthly in most cases).
About a half-quarter offset (launches mid-quarter, sales quarters end later).
Approximate progression: ~$1M → $7M → $21M → ~$56M (by acquisition); ~50 AEs at time of Microsoft acquisition.
Chapters
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. Rather than the CEO running around telling the engineers exactly what to build. You now have product managers. The company starts getting divided up into functional areas or silos. Product management, sales, customer support, marketing, and so on. This sort of 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. So probably the topic that I get asked about the most over the past 20 years based on my operating experience is just how do we 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. To me, that's what the cadence is. I learned this operating myself first. I was the founding or CEO of PayPal during the PayPal mafia period. And I sort of a self taught product person and kind of learned how to do product management operations there. And then my next company I founded Yammer. I was the CEO and we adapted this sort of operating philosophy for a SaaS company. We had to learn how to do sales and sales marketing, compete in heads up sort of battles against other companies selling similar products. And we refined the cadence then and it worked extremely well. We went from 0 to 56 million in sales in under four 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 at 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 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 and 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. 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 annual quotas or you can run them on monthly quotas. 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. 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 start feeling undermined. So the first part of 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 every quarter is going to start off the same. You're going to start off with a sales kickoff. At that kickoff, the sales team is going to receive their plans or territories. If there's any company objectives or spiffs 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 sales team on the product. You're going to train 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. The second month mid quarter, you're doing a lot of pipeline inspections. You're the sales leader is making sure the team's going to hit their goal, they're making adjustments, giving advice in terms of how to actually close those deals. And then we'll talk about this in a minute. But the marketing and product are going to be generating news in the second month of the quarter and sales can use that news to warm up prospects, email them news, collateral 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 have you the entire year's number because 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 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 ahold of prospects during that time. And so I Recommend Generally a January 31st. You'll also avoid kind of being 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. 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 got the Q4 is going to end now on January 31st. So that means that my Q1, my quarter end is going to 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. 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 snap board meetings because you want the board to review the information while it's still fresh. And so I like to see board meetings, typically quarterly board meetings occur two to three weeks after the close of these quarters that we talked about, when the results are fresh or 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 the product calendar. I want to tell you about my philosophy on product management. And this is something I learned at PayPal and then refined it at Yammer is 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. 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 want to fill a jar with rocks, pebbles and sand. We have this graphic here, down on the bottom, right? And so how do you do it? And 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. You're trying to maximize the amount of stuff that you can get push through the system with a fixed amount of resources. 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 or two things happens. Number one, they just ship sand, right? They don't think in terms of shipping, tentpole 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 supposed to take 1/4, and you'll still be doing it 2, 3, 4/4 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 two and 10 engineers for two to 10 weeks. And so the absolute biggest project that we could ever DO would be 10 engineers for 10 weeks. 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 product needs to be re scoped, it needs to be shrunk down into something that 10 engineers could ship in 10 weeks that we could put in front of users, get feedback about whether they liked the product before we then went on to the next round. And so, you know, this is what, this is the system 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, where 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 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 marketing those product features. And those product features should be the centerpiece of marketing events. I also believe that for marketing purposes, having four 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 winter, spring, summer, fall release. And 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. And I don't know why more startups and more founders don't do this. Some of the most successful founders, CEOs that we've ever had in our industry have used this technique of event based marketing. Steve Jobs, the iPhone release. 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 is based on a live product demo. 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 can, 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. 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 Marc Benioff at Dreamforce. Knowing that you're sending your CEO on stage with that product is, you know, 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 to 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 think about the product marketing calendar this way, it makes it a little bit more like the sales finance calendar where 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 sort of, that sort of, that's sort of 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. It's, it creates too much chaos inside the organization. Also, it's not good change management. You don't want the product and the product demos changing, right? When sales is trying to close deals, you want some stability in the product. And by the same token, when you have these big 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 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 and 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. And that's why I thought of Yammer is that we decided we're going to do this thing called Yam Jam and we made it our annual user conference. And 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 just look at Dreamforce, the products that Elon and Tesla have rolled out and what Steve Jobs did at Apple. Obviously those are very sexy products. But what Marc Benioff has done at, at Salesforce, that's CRM. It's not inherently the most exciting product is business software. And yet they've been able to, 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 one user conference a year and then three smaller webinars or city events. Doesn't have to be a huge event for the other quarters, but again, it forces that discipline around, making sure that what you're working on matters. So let's translate this. So now you've 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 this beat and you'll be well organized. So every month one, 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 prep for that sales kickoff, and the sales kickoff, you're going to get new sales plans, territories and quarters are going to be finalized. Meanwhile, the finance team is closing out the quarter. 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 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 two. So month two is going to be dominated by, you know, say in week seven, 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 launch event and the first couple of weeks of month two are going to be dominated by people getting ready for that. The marketing collateral is going to get finalized, the event prep event details are going to get finalized. You're certainly going to be doing QA and testing on the release. You might be in closed beta with some customers 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 two, you're going to want to debrief. You've just done this big launch event. How did it go? What are 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 teams can 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 launch, next quarter's release, and then finally you've got the third month of the quarter, which is really a heads down period inside the company. So what's happening in month three 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, if it hasn't already, for the next quarter's release. Remember that in month two, the PMs and designers really finalized, they're part of the release, the planning, and now coding begins in earnest. And so month three 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 start again with right back at it. 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 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 for people who are into fitness, 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. 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 sprint hit this big launch. Let the sales team, let them sprint to hitting their quarter end. But then you have a recovery period, 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 questions. So, you know, what is the cadence? I think the cadence is four sort of key calendars in the company which consolidate into two synchronized systems and then one operating cadence. When you have those two 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 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 two, 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 through streaming 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. The all hands meeting after the board meeting, I think it's a good idea to review what you just talked about with the board. And so you should also be thinking about 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 the compounding effect of shipping just four great quarters a year. I know if you're shipping daily or weekly and you say, well, wait. 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 get. 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 four lightning strikes or four 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. 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 a sprint. Think in terms of ladders. I think you'll be pleasantly surprised culturally at what that does for you. So why don't I pause there and I'm happy to answer any questions. Okay, wait. Should be in the right Q and A button. 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 processes? 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 and product board, so there are some pretty robust software for managing the product development process. So you should check them out. And there's a lot of great product management or project management software out there now, and you should check those out. Let's see here. Okay, a lot of questions. Me. All right. How do you ensure predictability in the ladder, Sprint, then 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 leaders 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 gonna 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 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, 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 yeah, that's the way to implement the ladders. Let's see here. Okay, question here. What was the 3rd to 4th year AR growth compared to sales team gross size? Was it 3322x for AR growth of the sales team, 2 or 3x and headcount year 4. Thanks for the talk, breeze. 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 to about 56 million the year that Microsoft bought us. At the time that Microsoft bought the company, I want to say that we had about 50 AES. So that, that should, you know, that 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 one, annual target with quarterly objectives, two, semi annual with quarterly targets, or three, quarterly? I think I would just go with quarterly. So I think it's simplest. Here's the problem with having 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 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, that's, you know, 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, 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. You know, I, 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 don't let anyone ever change the time and date of the event. That is a fixed point. Once you set it, you got to hit it. 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 going to, it's going to, it's going to drop, it's going to push to the next quarter and unfortunately you're just not going to 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 learning into the board meeting and learn. Have that conversation about 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, you know, 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, you know, or, you know, it's not an army yet. It's, you know, maybe it is like the Navy SEALs or something which, you know, it should be very experimental. There should not be a lot of overhead. You know, the founder, you know, you may not even have any Product managers, you don't necessarily need them. It's really about the founders working with the engineers, the designers to and sales, making sales themselves to figure out like what is the customer need and then immediately feeding that back into the dev cycle. I guess my big piece of Advice for Companies, CSafe Sharps, or 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. What is the one thing that somebody's willing to buy right now? 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? You know, that's something where you got to listen, that's a tricky thing. That is where you know, founder judgment is required. You know, it's, it's, 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. You know, 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 and we were so we were product driven and 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 going to 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. Let's see here. Gosh, there's I think more questions here I can possibly answer. I think we're just end at 250. So. All right, maybe I'll do this. Let's see here. Gosh, there's so many questions. Okay, how do you think about re platforming scenarios where the whole product needs to transition to a new architecture design? Could take one to two years. How would you recommend the process of 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 should be called the V2 fallacy. I'm very much against taking one to two 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'll 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 it's going to take you years to get a feature done, you'll be off by years. And so 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. Why don't I end there? Thanks everyone. Really appreciate you joining me today.










