Category Archives: Scaling

Design Your Organization for the Conflicts You Want to Hear About

Posted on October 12, 2024 | 2 comments

Organization design seems a popular topic these days. Maybe it’s the downturn. Maybe it’s just planning season. But either way, many people are asking me questions about how to design their organizations for 2025 and beyond. Questions like:

  • Should marketing report into sales?
  • Should engineering and product management (PM) report into a combined product org?
  • Should we unite customer success and sales?
  • Should North American and Europe report into a single head of sales?

The argument for combining teams is always about reducing span of control. This is a goal that many CEOs (and some boards) share, but one that somehow escaped one of the world’s most successful entrepreneurs, Jensen Huang, who has about 60 direct reports.

While 60 seems a bit much, I’ve frankly never understood span-of-control reduction as a top organization design goal. As CEO, you should be managing senior people so they shouldn’t take that much time. So, why not have 8 or 10 direct reports? If you can’t handle that, maybe the problem isn’t that you have too many reports, but that you’re managing them too closely. Maybe the solution isn’t to reduce their number, but to loosen the reins.

I have two rules for organization design:

  • Design for conflict. Specifically, design your organization for the conflicts you want to hear about.
  • Ensure value-add. Don’t put thing B under thing A unless the executive in charge can add value to both.

Design for Conflict

When you put, for example, engineering under product, what don’t you hear about anymore? Conflicts between PM and ENG about the time and resources required to build things. Those conflicts get silenced because the SVP of Product will suppress them, resolving them in the family.

When you put marketing under sales, what don’t you hear about anymore? Conflicts about whether sales strategy is too unfocused to enable marketing targeting. Or whether sales follows-up on new oppties in a timely manner. Those get silenced because the CRO wants to manage their own house. “Let’s resolve that at the sales QBR, not the e-staff meeting.”

When you put customer success under sales, what don’t you hear about anymore? Conflicts about whether sales is overselling to the point that customers won’t be successful and ergo won’t renew. If churn looks high, well, it must be the product. It’s not delivering, but against what expectations, set by whom? All silenced.

The rule is simple. By combining two departments, you are asking one person to resolve the conflicts between them. They’re not evil to do so; it’s the job you asked them to do. They will keep these conflicts in the family. And, as the organization grows, you will hire increasingly senior people to do just that. But with each layer and with each combination, you get more insulated from the ground truth.

So the question is simple: which conflicts do you want to hear about? Which do you want to pay someone else to resolve and which do you want brought to your office? Which are strategic to the company and potentially involve Crux-level issues?

  • If you separate PM and ENG, you’ll hear a lot about specs, resources, and timelines.
  • If you separate sales and marketing, you’ll hear a lot about awareness, leads, and follow-up.
  • If you separate customer success and sales, you’ll hear a lot about over-selling.

There’s no magical answer here. Just a framework for thinking about it. Determine the conflicts you want to hear about — presumably because you can add the most value in resolving them — and then design the organization to make sure you do.

Ensure Value-Add

The other principle is to always ensure value-add, beyond the (sometimes merely assumed) alignment that comes from having a common boss. So, sales wants the SDRs to report to them? Why? Has the sales VP managed an SDR team before? Are they good at it? Are they even interested in it? Can they add value? Are they sufficiently metrics and process-oriented, particularly if the VP comes from an enterprise background?

This principle drives a number of positive effects:

  • It defeats empire building. Sometimes the VP wants the SDR team not because they care about them, but because they want a bigger organization. Or they think it will look good on their resume for their next job search. They’re not actually interested in the job. They’re interested only in being able to say that they did it. That’s not good enough.
  • It encourages learning and development. When the VP of sales first asks about managing the SDRs, you can tell them to go make themselves a valid candidate. Get close to the SDRs now. Understand their challenges and offer to help out. Network with friends and colleagues on SDR team management. Read up on best practices. Convince me that you’d make the short list of candidates and then we can have a conversation.
  • You attract stronger department heads. Everyone should work for someone they can learn from. Saying the boss is the boss because, “well, we had to plug the team in somewhere,” is a terrible reason for an organizational structure. If you apply the value-add rule, functions will tend to report higher in the chain, creating a flatter org, and be placed only under those who can add value to them. This, in turn, attracts stronger candidates to run them. Who wants to be the CMO when it reports to a CRO who understands nothing about marketing? Nobody.

One great example is whether the VP of European Sales should report to the existing VP of Sales when you expand into Europe. If your VP of Sales is clever, they’ve already given themselves the title “VP of Worldwide Sales,” and you let them do it because it was moot at the time. But now they’ll argue it’s a demotion if Europe doesn’t report to them. And they’ll argue that they know how to sell the software in North America (really, the USA) and that knowledge should translate anywhere. And that everybody does it this way. You can almost hear them screaming: pick me, pick me!

But what they should be screaming is: I can add value, I can add value! And if they can, you should listen. But my questions would be:

  • Do you have a passport? (This wipes out about half of Americans.)
  • Have you ever lived in Europe?
  • Do you speak any European languages?
  • Have you ever sold and/or managed people in Europe?
  • Do you you have a network of people we can hire in Europe?
  • Do you have relationships with contacts at target customers in Europe?
  • Do you know any strategic partners we can work with in Europe?

So, other than not having a passport, never having been there, knowing no one, and not being able to communicate, you strike me as an outstanding candidate for the job.

We do this all the time nevertheless, and Europeans have grown accustomed to reporting into people who can’t add value. But for my nickel, I’d rather hire a VP of EMEA who had great answers to my questions and reported directly to me.

Mitigation Strategies

As your organization grows, you will invariably combine teams and lose your line of communication into certain conflicts. I know three ways to mitigate this:

  • Build a culture of transparency where direct reports into e-staffers are encouraged to and rewarded for speaking frankly about in-the-family problems.
  • Run an extended QBR. Don’t just invite the e-staff to the quarterly business review, but also invite people among their direct reports. For example, the head of customer success if it reports into the CRO, or the head of engineering if it reports into product. Ask them to deliver the same, standard presentation that the e-staffers do. This effectively flattens the organization by creating an extended leadership team that goes beyond the CEO’s direct reports.
  • Use reporting. Good reporting can reach through organizational layers and keep you in touch with what’s happening. For example, even if customer support doesn’t report to you and isn’t represented on the extended leadership team, you can still keep an eye on metrics and KPIs as well as simply on OKRs.

In this post, I’ve argued that the primary goal in organization design should not be reducing of span-of-control, but in surfacing conflicts most important to the company. I’ve also introduced a value-add rule that says no department should report into an executive who can’t add value to it. And finally, knowing that consolidation is inevitable over time as a successful company scales, I’ve offered three strategies to mitigate some of the signal loss that comes with such expansion.

2 Comments

Posted in Entrepreneurship, Leadership, Management, Scaling, Startups

Tagged ,

Startup Growth Trajectories and the SaaS Mendoza Line

Posted on August 1, 2024 | 3 comments

Back in 2018, Rory O’Driscoll, a VC at Scale and the inventor of the SaaS magic number, came up with another important SaaS concept: the Mendoza line for SaaS growth. Taking an idea from baseball, the Mendoza line is a measure of “offensive futility” named after Mario Mendoza, one of the best defensive shortstops in baseball, who unfortunately was challenged as a hitter, constantly struggling to maintain a .200 batting average. The question considered by the Mendoza line is: how low a batting average can a player have and remain in Major League Baseball, even with a very high level of defensive talent? The answer, in Mendoza’s day, was around .200. Above that, they’d keep you on the team for your defensive abilities; below that, they’d probably send you down to the minor leagues [1].

Driscoll translated this concept to SaaS, creating a line that provides, across a range of ARR sizes, a growth rate below which a company is not on a venture-backable trajectory. In short, if you’re above the SaaS Mendoza line, VCs will want to invest in your company, and if you’re not, they won’t. So it’s an important concept and one that helps answer a very difficult question for founders: how fast should we be growing?

Here’s the Mendoza line from Rory’s original post:

Note that the Mendoza line is a growth trajectory rule and thus should be considered along with other growth trajectory rules and metrics like T2D3 (triple, triple, double, double, double) by Battery’s Neeraj Agrawal, the growth endurance observations periodically discussed by Janelle Teng of Bessemer, or my Rule of 56789 published with my then-colleague at Balderton, Michael Lavner.

The inspiration for today’s post was a recent update to the SaaS Mendoza line published by Scale’s Eduard Danalache in July. Since the line changed with this update, I’ll refer to the original as the 2018 Mendoza line and the new one as the 2024 Mendoza line.

Now, let’s dive in.

The Two Assertions Behind the 2018 Mendoza Line

O’Driscoll said the Mendoza line was based on two assertions (paraphrased):

  • That most venture investors prefer to invest in companies with a chance to become standalone public companies. Looking at the (then-)realistic low bar of what that takes, this implied ARR of $100MM at the time of IPO, while still growing at 25% or greater.
  • That, most of the time, growth rates decline in a way that is fairly predictable. For a best-in-class SaaS company, the growth rate for any given year is between 80% and 85% of the growth rate of the prior year. Scale refers to this as growth persistence and argues this assumption holds true from about $10M on.

Some quick comments:

  • My how times have changed. Last week, I heard OneStream, at nearly $500M in ARR, referred to as “on the small side” for an IPO today [2]. That’s five times bigger than Rory’s bar, set only six years ago. Since a viable path to IPO is inherent in the definition of the SaaS Mendoza Line, the math needs to be updated to account for this.
  • What Scales calls “growth persistence” is now commonly called growth endurance. I’ll use the latter term henceforth.

There were some objections to the Mendoza line when it was introduced and Scale responded to them with a follow-up post. It’s a good read, but I won’t dig into it here. The headline news is simple: somebody needs to update the math.

The 2024 Mendoza Line

Last month, Scale released an update entitled, The Path From Zero to IPO: Revisiting the Mendoza Line in 2024.

The first thing they did was change the IPO criteria:

For the sake of this analysis, we’ll use a more ambitious target of $250M ARR growing at 25%, with a clear path to profitability. Again, don’t take this as gospel truth for when to IPO, but for the math to work we have to draw a line in the sand to aim for, and we believe this is a fair target in today’s world.

While this raises the bar significantly, I think it’s still too low. Anecdotally, per some recent Meritech S-1 breakdowns:

  • OneStream just went public with ARR of $480M growing at 34%
  • Rubrik went public earlier this year with $784M of ARR, growing at 47%
  • Klavyio went public in 2023 with $658M of implied ARR, growing at 51%

The last Meritech breakdown that resembles their target is Hashicorp, which went public in 2021 with $294M of ARR but was growing at 50%. But that stock, after some initial highs, was basically a dud in the public markets, so it’s perhaps not the ideal case study.

If I had to guess, I’d say the IPO bar today for software companies is more like $400M growing at 40% than $250M growing at 25% [3]. Many, me among them, would argue that the bar is much higher than it needs to be, but there are things we can’t control and this is certainly one of them.

Once you pick the destination (in terms of size and growth rate) and the growth endurance factor (Scale picks 85%), the rest is just a math problem.

But with one catch. Where do you start? The 2018 Mendoza line chart goes all the way down to $1M in ARR [4]. In the 2024 version, they basically say we don’t care how you get to $10M, but once you get there the Mendoza line takes effect.

Here’s the chart they published that compares the 2018 and 2024 Mendoza lines.

And here’s me backing into a curve based on the targets for ending ARR, growth rate, and growth endurance [5].

Running this model forward is all just about powers of 0.85. You pick a starting size, growth rate, and GE factor. You then use the GE factor (85%) to shrink the growth rate every year. So, for example, after 3 years your growth rate 0.85^3 = 61% of what it started at.

The problem with powers of 0.85 is they don’t scale very well. Scale realized this in scaling down, hence the 2024 advice to apply the rule only at $10M+. But, by picking the $250M ending target, they also avoided a degree of scaling up, pushing the rule to the edge of where it stops working because after about 10 years the growth rates it produces are too low. For example, the year 11 the growth rate is only one-fifth of what it was at the “start” [6].

So I’d say the 2024 Mendoza line is decent, but it doesn’t scale infinitely and is best used within a range, starting at $10M and for about the next 10 years.

Comparison to Other Growth Trajectory Rules and Metrics

Let’s conclude by comparing the Mendoza line to other rules and metrics for thinking about startup growth trajectory. Namely:

  • T2D3, which says once a company hits $2M in ARR it should seek to triple twice and then double three times.
  • The Rule of 56789, which says that startups should seek to break $10M in 5 years, $20M in 6 years, $50M in 7 years, $75M in 8 years, and $100M in 9 years [7].
  • The 85% growth endurance rule, which says you should pass $1M at some very high growth rate, then retain 85% of that growth every subsequent year [8]. I only now realize this is essentially a Mendoza line rose by any other name — which highlights a disadvantage of using catchy names (e.g., magic number, Mendoza line) over descriptive ones [9].

Here’s a tabular comparison of these rules [10]:

The outlier is T2D3 which I suspect has some lingering ZIRP growth-at-all-costs logic built in. The other rules tend to generate similar trajectories, none of which (by the way) get you to an IPO in 12 years. This is consistent with what I’m guessing is today’s median of around 14 years to IPO. More than ever, building a startup from inception to IPO is a marathon, not a sprint. Spend your energy accordingly.

Finally, for those who prefer charts, here is a visual comparison of those trajectories.

In this post, we’ve examined the 2024 Mendoza line for SaaS and learned a few things in the process:

  • That the 2018 Mendoza line is hopelessly out of date given the market changes in IPO requirements. This might explain why it never became as popular as other Scale creations like the magic number.
  • That since top VCs want to invest in companies that have a shot of going public, that founders should keep an eye on growth trajectories and the outcomes to which they lead. Specifically, if you’re clearly on a trajectory that cannot lead to an IPO, maybe should raise money through PE, regional and/or lower-tier VCs with lesser ambitions, venture debt, or revenue-based financing.
  • That the Mendoza line is a fancy way of saying retain 85% of your growth each year and (in the 2024 version) that you should start applying it after $10M. Personally, I’ll just use the 85% growth endurance rule as I think it’s simpler and comes without the somewhat arbitrary provisos.
  • That these rules only work within certain zones. T2D3 works from $2M to $144M and is undefined after that. The 2024 Mendoza line works from $10M to $250M, but beyond that produces growth figures that are too low. The 85% growth endurance rule works across the broadest range, but relies on starting at small size with an amazing growth rate from which to decay.
  • That rules reflect the environment in which they were created. The 2018 Mendoza line took you to $100M, which was Scale’s assumed IPO bar in 2018 [11]. T2D3 has an in-built high-growth bias reflective of the ZIRP era and best applied today only in greenfield markets where you have lots of capital available (e.g., AI).
  • That God did not decree that growth needs to decay every year. While this is certainly a common pattern, I have run startups where we accelerated growth (i.e., GE of >100%) and the average growth rate in Meritech’s public comparables is 19% today, higher than the age-driven growth rates which the Mendoza line would imply [12].

Thanks for reading. The spreadsheet I used in making this post is here.

# # #

Notes

[1] Fans will be happy to know that Mendoza ended his career with a .215 batting average. The lowest hitting shortstop today is batting .219.

[2] To really blow your mind, back at Business Objects, we went public in 1994 off $30M in revenues, which was fairly normal at the time. The IPO bar has gone way, way up over the decades and changed many things in Silicon Valley as a result. For example, creating the entire asset class of VC/PE growth equity which was unnecessary when companies went public with a $100M round off $30M in revenues.

[3] The IPO bar is ever-changing, somewhat ill-defined, and not something you can easily get data on unless you’re friendly with a bunch of investment bankers. For more data, go here, here, and here.

[4] Which is odd because the text of the article says the growth endurance behavior doesn’t start until $10M. I suspect the comment was added after the initial posting and the spreadsheets weren’t changed.

[5] Note that Mendoza line is presented as a curve which makes me think they calculated the equation for this curve and then plugged in the nice neat 10, 20, 30, etc. ARR sizes along the bottom. See my spreadsheet where I do that using an Excel trendline and accompanying formula.

[6] That is, your growth rate in the year in which you passed $10M.

[7] Reminder: this is about a trajectory and break means break, not hit. Some people misread the rule by translating the thresholds to growth rates which is not correct. By the way, those figures were arrived at by seeing what it took to be top quartile in the Balderton universe of data.

[8] I called it Growth Retention Rule in the 56789 blog post but don’t like how that abbreviates to GRR, so I switched to Growth Endurance here both to use today’s more commonplace language and avoid ambiguity around GRR (which means gross retention rate to most).

[9] It maps pretty well to the 2018 Mendoza line, though today’s now starts at $10M per Scale.

[10] Where the second and third rows are not the only possible trajectories, but each an example of a reasonable rule-compliant trajectory.

[11] I still think that was a low-ball estimate even in 2018.

[12] Though, in defense of Scale, they argue the Mendoza line is a tool for determining if you’re on an IPO trajectory and it was not designed to work beyond the IPO timeframe.

3 Comments

Posted in Growth, Metrics, Scaling, Startups, VC

Tagged ,

Target Pipeline Coverage is Not the Inverse of Win Rate

Posted on June 9, 2024 | 2 comments

I was reading a SaaS benchmark report the other day and encountered this line:

“Win rates declining [over the two-year period] from 23% to 19% might not seem all that significant. But in terms of required pipeline, it represents a dramatic shift from 4.3x to 5.3x coverage.”

It’s the kind of sentence that you might read, nod your head in hasty agreement, and then keep going. But you’d be wrong to do that. Quite wrong. And a lot of people make this mistake.

Thus, in this post, I’ll explain why it’s wrong to invert win rate to calculate target pipeline coverage, demonstrate that with a spreadsheet, and then give you a better way to determine target pipeline coverage.

Before diving into the math, let’s take a second to sanity check the conclusion reached above: you’re going to need 5.3x pipeline coverage [1]. Given that the rule of thumb for pipeline coverage is 3.0x, how do we feel about requiring 5.3x? My thoughts [2]:

  • I wonder who’s going to generate that? In many companies, it’s primarily marketing. So this potentially passing the buck: “hey marketing, we’re not closing as much as we used to, so we need more coverage.” It’s your problem, now.
  • At what cost? Let’s say that it costs $4K to generate a sales-accepted (aka, stage 2) opportunity [3]. If we needed 3x coverage before — e.g., 30 opportunities (“oppties”) to generate 10 deals — now we are going to need 53. That’s 23 more oppties at an incremental cost of $92K. Who’s going to pay for that? What’s that going to do to our CAC ratio and CPP?
  • Why do we lose so much? Sales is telling us that they can win only 19% of the oppties that they accept as valid sales oppties? That strikes me as low. If a tougher macro environment means lower quality stage 1 oppties, then why is sales accepting them? Lower quality stage 1 opportunities should show up in a higher stage 2 rejection rate, not a lower win rate [4].

So, if the answer is that we need 5.3x pipeline coverage to make plan, I’m going to have a lot of questions without doing any math at all. But now, let’s cut to the math.

What is Win Rate?

Most people define win rate as follows:

For all oppties that reached a terminal state during the quarter, win rate = wins / (wins + losses). I call this narrow win rate because it excludes no-decisions (also known as derails) where an oppty hits a terminal state without anyone winning it — for example, where the customer decided to stick with the status quo or the whole evaluation gets derailed by a surprise merger [5]. Because derails can happen a lot [6], I define an additional metric, broad win rate = wins / (wins + losses + derails).

Note that both of these win rates exclude slips, when the close date for an opportunity is moved out of the current quarter into a future one. Slips happen a lot. In fact, my basic rule of thumb is you win a third, you lose a third, and you slip a third [7]. Also note that I’m doing this on a count basis, not a dollar basis, which is my default preference [8].

You should already see why inverting win rate is not a great way to determine pipeline coverage requirements:

  • It’s ambiguous. Which win rate, narrow or broad?
  • Slips are common, but excluded from win rates. (Definitionally, because slipped oppties do not hit a terminal state in the quarter.)
  • The timing is wrong. We use pipeline coverage at the start of the quarter to see if we have a chance at hitting the number. But win rates are based on when oppties die, not their start-of-quarter status.

What is Close Rate?

I define close rate as a cohort-based metric that answers the question: given a set of oppties, what percent of them do we close/win [9] in some time period. For example, the six-quarter close rate for the cohort of stage-2 oppties created in 1Q22 = oppties in the cohort closed in the period [1Q22 to 3Q23] / oppties created in 1Q22. Let’s show it with an example:

The first block shows oppty count, the second shows percent. Here, we see a 27% six-quarter close rate. You can also run a cumulative rate along the bottom of the table that would show, for example, that the four-quarter close rate is 23%.

Win rates are period metrics that tell you what happened to the oppties that a hit a terminal state in a given period. Close rates are cohort metrics that tell you, in the fullness of time, the percent of a set of oppties that we win.

  • They are different.
  • They are both valuable.
  • Win rates are great for tracking progress against the enemy.
  • Close rates are great for knowing how much value we expect to extract, and when, from a set of oppties.
  • Neither is good if you want to invert something to find required pipeline coverage.

Week 3 Pipeline Conversion Rate

Let’s look at a different metric. Instead of starting with the fate of oppties in the pipeline, let’s start with an early-quarter snapshot of the current-quarter pipeline and then compare it to how much we close. Ideally, we’d take the snapshot on day one of the quarter, but that’s not realistic because sales invariably needs some clean-up time after the end of a quarter. Ergo, I typically use week-3 starting pipeline. If you have a monthly cadence, I’d suggest doing this same analysis on a monthly basis and using day-3 starting pipeline [10]. You can then calculate week-3 pipeline conversion rate = new ARR closed / week-3 starting pipeline. See [11] for some notes on this metric.

Because the conversion rates often differ significantly between new and expansion business, most people segment week-3 pipeline conversion rate by new business (newbiz) vs. expansion. In my endless desire to keep things simple, I always start with the total, unsegmented pipeline and break it out later if I need to. The reality is that while the conversion rates are different, if the mix remains roughly constant, it all comes out in the wash.

Here’s a table to show this concept at work:

To get implied target pipeline coverage, I take a trailing nine-quarter average of the week-3 pipeline conversion rate (34%) and then invert it to get 2.86. You could also have fun with the percent-of-plan row, asking questions like: what pipeline coverage do we need to hit plan 90% of the time?

In this post, I’ve hopefully blown a hole in the conventional wisdom that you can invert win rate to get target pipeline coverage. And I’ve provided a far better metric for accomplishing that task: week-3 pipeline conversion rate.

My metrics brother Ray Rike and I recently released an episode of our podcast, SaaS Talk with the Metrics Brothers, on this very topic. The spreadsheet for this post is here.

# # #

Notes

[1] When I used to help my kids with math homework, I’d always include a sanity check review of the answer. If you’re calculating the mean summer temperature in Alaska and the answer is 451 degrees, then go back and check your work.

[2] And I find that rule of thumb high in many situations. At the last company I ran, we could consistently hit plan with 2.5x coverage.

[3] In practice, the average cost of a stage 2 oppty varies considerably. I think a range of $2K to $10K probably covers 90% of cases, with a mean around $4-5K. These are mid-market and enterprise figures. SMB is presumably cheaper. These are sales-accepted so the cost is equivalent to your stage 1 oppty cost dividied by your stage 2 acceptance rate (typically 60-80%).

[4] Yes, I’m aware of the “desperation effect” whereby sellers with weak pipeline accept lower-quality opportunities, but sales management must fight to hold some objective quality bar to preserve pipeline discipline, to ensure resources are only put against quality oppties, and to ensure the validity of pipeline analysis. So yes, the effect is real, but it’s sales management’s job to limit it. (See the “floating bar” problem discussed here.)

[5] Many people code no-decisions as losses and then have a reason code for no-decision. I think this potentially blurs up win/loss analysis because losing to a competitor is different from a no-decision. (Plus, it usually precludes putting no-decision codes on no-decisions which I also want.) The fact is they are two different cases: losing to a competitor vs. an evaluation process ending without selecting a winner.

[6] Particularly in new markets where people are primarily exploring whether they want to buy one at all. In more developed markets — where the customer is more likely thinking, “I’m going to buy one, the question is which” — you should see lower derail rates. And those derails should be more surprise-driven — e.g., we got acquired, the CFO quit, we missed a quarter, we failed an audit, we’re being sued, etc.

[7] Which implies in a 50% narrow win rate, a 33% broad win rate, a 33% slip rate. This is realistic if you are one of two competitors going head-to-head in a market segment. If it’s more of a horse race, I’d expect to see a lower rate. Also, the “a third, a third, a third” rule excludes derails which you can skim off the top. For example, if 20% derail and the balance split by thirds, then you win 27%, lose 27%, and slip 27% of your deals.

[8] I prefer counts to dollars because they’re more visceral and less messed up by big deals. If you are running two sales motions (e.g., corporate and enterprise), I’d first try to stay count-based, but segment the analysis before going to a dollar basis. But there’s a time and a place for both.

[9] Which some might prefer to think of as a “closed/won rate,” but that’s too many syllables for me.

[10] Both generously allows about 10% plus or minus of the period to elapse before snapshotting: 3 days out of 30 (10%) and, depending on how you calculate weeks and what day the quarter starts on, up to 14 days out of 91 (15%).

[11] This assumes (a) sales cycles much longer than the period (e.g., 6-12 months) and (b) no sales are made prior to the snapshot. It ignores (a) deal expansion or shrinkage after week 3, and (b) where closed/won deals came from (e.g., they may be in the week-3 snapshot, created after it, or pulled-forward from a future quarter). This asymmetry bothers some people but it’s really supposed to be a macro measure. The real risk you face using it is when ceteris aren’t paribus.

2 Comments

Posted in Metrics, Pipeline, Sales, Salesops, Scaling, Startups

Tagged , ,

Preview of My SaaStr Europa Talk: The Top 5 Scale-Up Mistakes

Posted on May 23, 2022 | Leave a comment

I’ll be speaking next month in Barcelona on the first day of SaaStr Europa, held at the International Convention Center on June 7th and 8th.   My presentation is scheduled at 11:25AM on June 7th and entitled The Top 5 Scale-Up Mistakes and How to Avoid Them.  While I usually speak at SaaStr, this is my first SaaStr Europa, and I’ll be making the trip over in my capacity as an EIR at Balderton Capital.

For those concerned about Covid, know that SaaStr Europa, like its Silicon Valley namesake, is a primarily outdoor and open air conference.  I spoke at SaaStr Annual in Silicon Valley last September and between the required entry testing and the outdoor venue felt about as safe as one could in these times.  Earlier this year, the folks at SaaStr moved the Europa venue from London to Barcelona to enable this primarily outdoor format.

After historically focusing a lot of my SaaStr content on the start-up phase (e.g., PMF, MVP), this year I thought I’d move to scale-up, and specifically the things that can go wrong as you scale a company from $10M to $100M in ARR.  Even if your company is still below $10M, I think you’ll enjoy the presentation because it will provide you with a preview of what lies ahead and hopefully help you avoid common mistakes as you enter the scale-up stage.  (If nothing else, the rants on repeatability and technical debt will be worth the price of admission!)

Without excessively scooping myself, here’s a taste of what we’ll talk about in the presentation:

  • Premature go-to-market acceleration.  Stepping on the gas too hard, too early and wasting millions of dollars because you thought (and/or wanted to believe) you had a repeatable sales model when you didn’t.  This is, by far, the top scale-up mistake.  Making it costs not only time and money, but takes a heavy toll on morale and culture.
  • Putting, or more often, keeping, people in the wrong roles.  Everybody knows that the people who helped you build the company from $0 to $10M aren’t necessarily the best people to lead it from $10 to $100M, but what do you do about that?  How do you combine loyalists and veterans going forward?  What do you do with loyalists who are past their sell-by date in their current role?
  • Losing focus.  At one startup I ran, I felt like the board thought their job was to distract me — and they were pretty good at it.  What do you do when the board, like an overbearing parent, is burying you in ideas and directive feedback?  And that’s not mention all the other distraction factors from the market, customers, and the organization itself.  How does one stay focused?  And on what?
  • Messing up international (USA) expansion.  This is a European conference so I’ll focus on the mistakes that I see European companies make as they expand into the USA.  Combining my Business Objects experience with my Nuxeo and Scoro board experience with both Balderton and non-Balderton advising, I’m getting pretty deep on this subject, so I’m writing a series on it for the Balderton site.  This material will echo that content.
  • Accumulating debilitating technical debt.  “I wear the chain I forged in life,” said Jacob Marley in A Christmas Carol and so it is with your product.  Every shortcut, every mistake, every bad design decision, every redundant piece of code, every poor architectural choice, every hack accumulates to the point where, if ignored, it can paralyze your product development.  Pick your metaphor — Marley’s chains, barnacles on a ship, a house of cards, or Fibber McGee’s closet — but ignore this at your peril.  It takes 10-12 years to get to an IPO and that’s just about the right amount of time to paralyze yourself with technical debt.  What can you do to avoid having a product crisis as you approach your biggest milestone?

For those in attendance, we will have an Ask Me Anything (AMA) session after the presentation.  I’ll post my slides and the official SaaStr video after the conference.

This should be fun.  I hope to see you there!

Leave a comment

Posted in Boards, GTM, Leadership, Management, Marketing, People, SaaS, SaaStr, Sales, Scaling, Startups

Sorry, But Demo Is Not A Sales Cycle Stage

Posted on December 15, 2021 | 11 comments

I think two demo practices are nearly universal these days and I’m not a big fan of either:

I discussed using demo as the primary website CTA in a previous post.  In this post, I’ll cover my objections to using demo as a sales cycle stage.  I know that both of these viewpoints are controversial, so please classify them in the thought-provocation department [2].

What are Sales Cycle Stages?
Companies use stages to decompose the sales process into a series of steps.  For example:

  1. Prospecting
  2. Contacting
  3. Qualifying
  4. Presenting
  5. Objection handling
  6. Closing

Sometimes those steps are phases that you exist within, other times they are milestones that you pass [3].  Companies use stages to track the progress of deals, the aging of deals to ensure they don’t get stuck, and typically weight the pipeline by stage as a way of triangulating the forecast.

Seller-Out or Buyer-In?
When you first learn about sales cycle stages they are typically presented, as they are above, from the seller’s point of view.  Over time, most people realize this is wrong, particularly when they’ve moved to the increasingly popular framing that selling is not a process unto itself, but more the facilitation of a customer’s buying process.

In this paradigm you try (and it’s not always easy) to define stages from the buyer’s viewpoint instead of the seller’s.  For example, using milestone-based stages, this might look like:

  1. Need established.  Buyer a has problem for which they are seeking a solution, typically as verified by an SDR.  [4]
  2. BANT verified.  Buyer has not only a need, but budget, authority to spend it, and a timeframe for purchasing a solution — all as verified by a seller.  [5]
  3. Deep dive completed.  Buyer has performed a deep dive with the seller to fully explain the problem and answer questions about it.  [6]
  4. Solution fit confirmed.  Buyer believes that the seller’s product can basically solve their problem.  [7]
  5. Vendor of choice.   Buyer believes that the seller’s product is the best choice of solution to the problem.
  6. Redline.  Buyer’s legal team has reviewed the contract and submitted a turn of redline markup.
  7. Contracted.  Buyer has completed the contract and other required paperwork.  Also known as closed/won.

Notice that the first word of every stage definition is “buyer” in order to keep us focused on the buyer, not the seller.  There are three other great features of the above style of system:

  • Every stage is verifiable.  In many staging systems, it’s hard to know what stage you’re in [8] and nearly impossible for a sales manager to verify it.
  • Sellers can be pushed for evidence in deal reviews and pipeline scrubs.  Example.  Manager: “You classified this as stage 4, why?”  Seller:  “Because, they said they think we can basically solve their problem.”  Manager:  “Who said that and when?”  Seller:  “Paula the VP said it at the end of the meeting last week.”
  • Management verification can be done by asking the buyer a single question.  Manager:  “So, your seller Joe says you’ve done a deep dive together on the problem you’re looking solve?”  If yes, stage 3.  Manager:  “So, your seller Jane tells me you think we can basically solve your problem?”  If yes, stage 4.

My Problems with Using Demo as a Stage 
Given that I like buyer-in, verifiable staging systems, it’s probably no longer a surprise that I don’t like demo as stage, but here’s the full list of reasons why:

  • Demo is seller-out.  I learned to hate seller-out stages back in the day when “proposal” was also a stage.  You can send a proposal to anyone at any time — what does that actually tell you about the progress of a deal?  Nothing.  The same holds true for demo.
  • Demo is not buyer-in.  It doesn’t tell us anything about where the buyer is in their buying process.  Just that they got a demo.  By the way, which kind of demo did they get?  Did we do a custom demonstration mapped to a precise problem they are desperate to solve or did they just passively watch a 30-minute generic demo?
  • Buyers may want demos at very different phases of their buying cycle.  Gadget people want a demo of everything.  Others may want a demo before making their long list.  Some may want a demo before making their short list.  Others may only want demos of two finalists.  Many will want multiple demos to different people along the way.  Remind me how demo tells you where are you in the sales cycle again?
  • Buyers should be able to get demos when and how they want them.  Could you imagine saying, “you can’t have that white paper until we’ve completed step 3 of our process?”  That’s effectively what you’re doing when you make demo a stage.  Think:  “I’m sorry, demo is our stage 4 and we haven’t completed stage 3 yet; can we get back to what I’m focused on, please?”  In a world where buyers want ever more control over the buying process, that dog don’t hunt.
  • You risk building an expensive custom demo into your sales process.  Once demo is a declared a stage, sellers start focusing on the demo as the big event.  Well, we need to gather requirements for the demo.  Oh, we’ll be showing you how that works as part of the demo.  Yes, we’re working on customizing the demo for your industry and solution.  What if the customer didn’t want or need some big customized demo to buy your software?  What if believing you could basically solve their problem and thinking you were the market leader (i.e., safe choice) were enough?  You risk imposing the demo on the buyer (“well everybody does it”) in the name of process rather than remaining focused on their buyer and their solution.
  • Conceptually, demo is part of confirming solution fit.  The usual reason for a demo is to help the buyer establish if the product can (basically) solve their problem [9].  What we should be focused on is whether they think we can solve their problem [10], and not whether they got the demo.
  • Be careful what you wish for.  If you wish for a lot of demos, you’ll end up doing a lot of demos.  The question is will they lead to sales?  I’d rather focus on convincing a lot of people that we can basically solve their problem or that we’re the best solution to their problem — or that we can basically solve their problem and we’re the clear market leader — than on giving a lot of demos.
  • Demo defaults to the reference point.  Once people start using demo as a stage, it quickly becomes the default mid-funnel checkpoint and two metrics rise to the top of management reporting:  demos/week and demo-to-close rate. If you think demo is effectively meaningless as a stage, this is obviously problematic.  It’s like saying how many schmumbles did we do this week?  50.  How many did we do last week?  30.  Awesome, schmumbles are up this week!!  What’s a schmumble?  I don’t know.

All that said, I understand why people like to use demo as a stage — demos are tangible, you know when they happened, they often do happen at roughly the same place in the sales cycle, and they are indeed often required.

But making demo a sales cycle stage hard-codes demos into your sales process and, like hard-coding in programming, while it may be expedient in short-term, you may well live to regret it in the long.

# # #

Notes

[1]  Except in product-led growth (PLG) models, where it’s trial, which is indeed the point.

[2]  In both cases, I know these practices are entrenched so I’m not asking anyone to blow up their website or their sales pipeline management process.  I am, however, asking you to think twice about how you use demo both on your website and in your sales cycle, with an eye towards potentially changing your approach.

[3]  It’s shocking how many companies can’t answer the question:  are your stages phases or milestones?  That is, does “stage 4” mean you are “in” stage 4 or that you have completed stage 4.  When defined as phases, you will often find “exit criteria” that define what needs to be done to exit the stage.  Either way, it has to be crystal clear when you have exited a stage or not.

[4]  This is typically done after other preliminary qualification has occurred, such as company-size or industry to ensure the buyer is in the target market.

[5]  Also known as a sales-accepted opportunity.  This is the point, in most companies, where the opportunity officially enters the pipeline.

[6]  This may involve a single meeting, or a sequence of them, depending on the complexity of the problem and the potential solution.

[7]  Notwithstanding certain detailed issues that remain open questions, but overall, the buyer has reached the conclusion that the product can basically solve this problem.  This is not to say that it’s the best, the only, or the most cost-effective solution to the problem; merely that it can solve the problem.  Think:  a tank could likely solve my stump-removal problem, but then again so could The Dominator.

[8]  Among other ways, this can happen in a phase-based system where there are lots of exit criteria per stage.  I’ve literally seen systems where you could win the deal before clearing all six of the stage 3 exit criteria!

[9]  Putting aside purely educational demos which I think are best handled by marketing.

[10]  Which can be accomplished through other means as well — e.g., case studies, reference calls.  Believing that someone like me solved a problem very similar to one like mine is often a far more powerful way of confirming solution fit.  As is merely demonstrating deep expertise in the problem to solved by, e.g., completing a few of the customer’s sentences when they’re describing it.

11 Comments

Posted in SaaS, Sales, Scaling, Startups