Category Archives: Scaling

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 Build blog. 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!

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:

Using a demo as the primary call-to-action on a website [1]
Using demo as a sales cycle stage

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:

Prospecting
Contacting
Qualifying
Presenting
Objection handling
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:

Need established. Buyer a has problem for which they are seeking a solution, typically as verified by an SDR. [4]
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]
Deep dive completed. Buyer has performed a deep dive with the seller to fully explain the problem and answer questions about it. [6]
Solution fit confirmed. Buyer believes that the seller’s product can basically solve their problem. [7]
Vendor of choice. Buyer believes that the seller’s product is the best choice of solution to the problem.
Redline. Buyer’s legal team has reviewed the contract and submitted a turn of redline markup.
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

My Perspectives on Growth (Presentation)

Posted on November 4, 2021 | 1 comment

In my new capacity as an EIR at Balderton Capital, I recently gave a presentation to a leadership meeting at a high-growth, Balderton-backed startup offering my perspectives on growth and the challenges that come with it.

I discussed these five challenges:

Next-levelitis, an obsessive focus on scaling everything to the next level. (Which is great if not overdone.)
Absorbing new leaders, (aka, “FBI guys”) and the challenges that come when hiring the wrong next-level people and they blow themselves up at the start.
Conflation of regional culture and opinion, a common problem in international expansion. (What’s a bona fide regional difference vs. a difference of opinion masked as one?)
Missing an opportunity that you want (aka, getting “passed over” for a promotion) and what to do about it.
Getting things wrong to get other things right. Startups are 100% about getting what matters right. Which begs the question, what matters?

The slide deck is below.

By the way, you have to watch the referenced Die Hard videos; they do a superb job of portraying what it feels like in these situations:

“I’m Dwayne Robinson … and I’m in charge here.”

“Not any more.”

1 Comment

Posted in Growth, Management, People, SaaS, Scaling, Silicon Valley, Startups, VC

Structuring the Organization and Duties of Product Marketing and Competitive Analysis

Posted on July 24, 2021 | Leave a comment

I sometimes get asked about how to structure an enterprise software marketing organization and the relative roles of product marketing vs. competitive analysis. In this post, I’ll share my (somewhat contrarian) thoughts on this topic.

My first job in marketing, which served as my bridge from a technical to a sales-and-marketing career, was as a competitive analyst. Specifically, I was the dedicated Sybase competitive analyst at Ingres in the late 1980s, in a corporate job, but working out of the New York City sales office. Because, at the time, Sybase was a strong new entrant with a beachhead strategy in financial services, this was rough equivalent of working for the Wehrmacht on Omaha Beach on D-Day. I learned not only by watching Sybase’s market invasion, but more importantly by watching how the local reps [1] and corporate [2] responded to it.

I’m a huge believer in competitive analysis, which probably started when I first heard this quote watching Patton as an adolescent:

“Rommel, you magnificent bastard, I read your book!” [3]

My other formative experience came from watching yet another movie, Wall Street, where antagonist Gordon Gekko refers to Sun Tzu’s The Art of War.

While Gekko doesn’t use my favorite quote for these purposes [4], his reference to the book was very much in vogue at the time, and probably why I first read it. My favorite quote from The Art of War is this one:

“If you know the enemy and know yourself, you need not fear the result of a hundred battles. If you know yourself but not the enemy, for every victory gained you will also suffer a defeat. If you know neither the enemy nor yourself, you will succumb in every battle.”

Regular readers know I believe the mission of marketing is to make sales easier. So the question becomes: in enterprise software, how do we structure product marketing and competitive in the best way to do just that?

First, let’s review some common mistakes:

Not specializing competitive, instead declaring that each product marketing manager (PMM) will cover their respective competitors. Too much scope, too little focus.
Understaffing competitive. Even in organizations where competitive exists as its own team, it’s not uncommon to see a ratio of 5-10 PMMs per competitive analyst in terms of staffing. This is too unbalanced.
Chartering competitive as strategic. While I often euphemize the competitive team as “strategic marketing” or “market intelligence,” that’s not supposed to actually change their mission into some think tank. They exist to help sales win deals. Don’t let your competitive team get so lofty that they view deal support as pedestrian.
Putting competitive under product marketing. This both blurs the focus and, more importantly, eliminates a healthy tension [5]. If your messaging doesn’t work in the field, the CMO should want to hear about it early (e.g., in their own staff meeting) and have a chance to fix it before it escalates to the corporate QBR and a potential sales attack on marketing in front of the CEO.
Putting competitive in the field. This happens when marketing abdicates responsibility for producing sales-ready competitive materials and someone else picks up the ball, usually the sales productivity team, but sometimes field marketing [6]. This disconnects corporate product marketing from the realities of the field, which is not healthy.

Now, let’s tell you how I think structuring these departments.

Product marketing exists to build messaging and content [7] that describe the features and benefits of the product [8]. The job is to articulate. They are experts in products.
Competitive analysis exists to research competitors, devise plays, and build tools to help sales win deals. The job is to win. They are experts in the competitors.

As long as we’re in movie quote mode, here’s one of my favorite quotes from James Mason’s character in The Verdict [9]:

I’d prepared a case and old man White said to me, “How did you do?” And, uh, I said, “Did my best.” And he said, “You’re not paid to do your best. You’re paid to win.”

While he was speaking to about lawyers, he might as well have been speaking to competitive: you’re paid to win.

That’s why I believe competitive needs to be holistic and play-oriented. Simply put, take everything you know about a competitor — e.g., products, leadership, history, tactics — and devise plays that will help you win against them. Then train sales on how to run those plays and supp0rt them in so doing.

If you adopt this mindset you end up with an organization where:

Product marketing and competitive are separate functions, both reporting directly to the CMO
Product marketing is product-oriented, focused on articulation of features and benefits
Competitive is competitor-oriented, focused on using all available information to create plays that win deals and support sales in executing them
Product marketing staffing is driven by the number of products you’re covering
Competitive staffing is driven by the number of competitors you’re covering (and at what depth level or tier).
You end up with a ratio of more like 3:1 than 10:1 when it comes to the relative staffing of product marketing and competitive

You think of these organizations as a matrix:

# # #

Notes

[1] In the case of the reps, their response was to walk away from financial services deals because they knew they were likely to lose. This, of course, had the effect of making it easier for Sybase to enter the market. The smart reps went to Westchester and Long Island and sold in other verticals. The dumb ones battled Sybase on Wall Street, lost deals, missed mortgage payments, broke marriages, and got fired — all for doing what the c0mpany strategically should have wanted them to do: to slow down the invasion. A classic case of micro and macro non-alignment of interests.

[2] The corporate response was to blame sales management. Rather than seeing the situation as a strategic problem where an enemy was breaking through lines with an integrated strategy (e.g., partners), they chose to see it as an operational or execution problem. Think: we’re hiring bad reps in NYC and losing a lot deals — fire the sales manager and get some new talent in there.

[3] Good Strategy, Bad Strategy tells the presumably more common inverse tale, where during the Gulf War in 1991 General Schwarzkopf was widely credited with a left-hook strategy described as “surprise,” “secret,” and “brilliant,” that was clearly published in the US Army Field Manual 100-5 saying the following, complete with an illustration of a left hook.

Envelopment avoids the enemy’s front, where its forces are most protected and his fires most easily concentrated. Instead, while fixing the defender’s attention forward by supporting or diversionary attacks, the attacker maneuvers his main effort around or over the enemy’s defenses to strike at his flanks and rear.

[4] Gekko refers to: “Every battle is won before it’s ever fought.”

[5] Organization design is all about creating and managing healthy tensions. Such tensions are a key reason why I like marketing reporting to the CEO (and not sales), customer success reporting to the CEO (and not the CRO/sales), and engineering reporting to the CEO (and not product), for a few examples.

[6] At one point, way back, Oracle had a huge market intelligence organization, but housed within Americas Marketing, a field marketing organization.

[7] Content being collateral (e.g., web content, white papers, e-books), presentations (internal and external), and demonstrations — all built around communicating the key messages in their messaging blueprint.

[8] Often, but not always, with a primary emphasis on differentiation.

[9] It’s not lost on me that the character was morally bankrupt and was implicitly saying to win at any and all costs. But I nevertheless still love the quote. (And yes, win within normal legal and societal constraints! But win.)

Using To-Go Coverage to Better Understand Pipeline and Improve Forecasting

Posted on April 29, 2021 | 8 comments

This is the second in a three-part series focused on forecasting and pipeline. In part I, we examined triangulation forecasts with a detailed example. In this, part II, we’ll discuss to-go pipeline coverage, specifically using it in conjunction with what we covered in part I. In part III, we’ll look at this/next/all-quarter pipeline analysis as a simple way to see what’s happening overall with your pipeline.

Pipeline coverage is a simple enough notion: take the pipeline in play and divide it by the target and get a coverage ratio. Most folks say it should be around 3.0, which isn’t a bad rule of thumb.

Before diving in further, let’s quickly remind ourselves of the definition of pipeline:

Pipeline for a period is the sum of the value of all opportunities with a close date in that period.

This begs questions around definitions for opportunity, value, and close date which I won’t review here, but you can find discussed here. The most common mistakes I see thinking about the pipeline are:

Turning 3.0x into a self-fulfilling prophecy by bludgeoning reps until they have 3.0x coverage, instead of using coverage as an unmanaged indicator
Not periodically scrubbing the pipeline according to a defined process and rules, deluding yourself into thinking “we’re always scrubbing the pipeline” (which usually means you never are).
Applying hidden filters to the pipeline, such as “oh, sorry, when we say pipeline around here we mean stage-4+ pipeline.” Thus executives often don’t even understand what they’re analyzing and upstream stages turn into pipeline landfills full of junk opportunities that are left unmanaged.
Pausing sales hiring until the pipeline builds, effectively confusing cause and effect in how the pipeline gets built [1].
Creating opportunities with placeholder values that pollute the pipeline with fake news [1A], instead of creating them with $0 value until a salesrep socializes price with the customer [2].
Conflating milestone-based and cohort-based conversion rates in analyzing the pipeline.
Doing analysis primarily on either an annual or rolling four-quarter pipeline, instead of focusing first on this-quarter and next-quarter pipeline.
Judging the size of the all-quarter pipeline by looking at dollar value instead of opportunity count and the distribution of oppties across reps [2A].

In this post, I’ll discuss another common mistake, which is not analyzing pipeline on a to-go basis within a quarter.

The idea is simple:

Many folks run around thinking, “we need 3.0x pipeline coverage at all times!” This is ambiguous and begs the questions “of what?” and “when?” [3]
With a bit more rigor you can get people thinking, “we need to start the quarter with 3.0x pipeline coverage” which is not a bad rule of thumb.
With even a bit more rigor that you can get people thinking, “at all times during the quarter I’d like to have 3.0x coverage of what I have left to sell to hit plan.” [4]

And that is the concept of to-go pipeline coverage [5]. Let’s look at the spreadsheet in the prior post with a new to-go coverage block and see what else we can glean.

Looking at this, I observe:

We started this quarter with $12,500 in pipeline and a pretty healthy 3.2x coverage ratio.
We started last quarter in a tighter position at 2.8x and we are running behind plan on the year [6].
We have been bleeding off pipeline faster than we have been closing business. To-go coverage has dropped from 3.2x to 2.2x during the first 9 weeks of the quarter. Not good. [7]
I can easily reverse engineer that we’ve sold only $750K in New ARR to date [8], which is also not good.
There was a big drop in the pipeline in week 3 which makes me start to wonder what the gray shading means.

The gray shading is there to remind us that sales management is supposed to scrub the pipeline in weeks 2, 5, and 8 so that the pipeline data presented in weeks 3, 6, and 9 is scrubbed. The benefits of this are:

It eliminates the “always scrubbing means never scrubbing” problem.
It draws a deadline for how long sales has to clean up after the end of a quarter: the end of week 2. That’s enough time to close out the quarter, take a few days rest, and then get back at it.
It provides a basis for snapshotting analytics. Because pipeline conversion rates vary by week things can get confusing fast. Thus, to keep it simple I base a lot of my pipeline metrics on week 3 snapshots (e.g., week 3 pipeline conversion rate) [9]
It provides an easy way to see if the scrub was actually done. If the pipeline is flat in weeks 3, 6, and 9, I’m wondering if anyone is scrubbing anything.
It lets you see how dirty things got. In this example, things were pretty dirty: we bled off $3,275K in pipeline during the week 2 scrub which I would not be happy about.

Thus far, while this quarter is not looking good for SaaSCo, I can’t tell what happened to all that pipeline and what that means for the future. That’s the subject of the last post in this three-part series.

A link to the spreadsheet I used in the example is here.

# # #

Notes

[1] In enterprise SaaS at least, you should look at it the other way around: you don’t build pipeline and then hire reps to sell it, you hire reps and then they build the pipeline, as the linked post discusses.

[1A] The same is true of close dates. For example, if you create opportunities with a close date that is 18+ months out, they can always be moved into the more current pipeline. If you create them 9 months out and automatically assign a $150K value to each, you can end up with a lot air (or fake news/data) in your pipeline.

[2] For benchmarking purposes, this creates the need for “implied pipeline” which replaces the $0 with a segment-appropriate average sales price (ASP) as most people tend to create oppties with placeholder values. I’d rather see the “real” pipeline and then inflate it to “implied pipeline” — plus it’s hard to know if $150K is assigned to an oppty as a placeholder that hasn’t been changed or if that’s the real value assigned by the salesrep.

[2A] If you create oppties with a placeholder value then dollar pipeline is a proxy for the oppty count, but a far less intuitive one — e.g., how much dollar volume of pipeline can a rep handle? Dunno. How many oppties can they work on effectively at one time? Maybe 15-20, tops.

[3] “Of what” meaning of what number? If you’re looking at all-quarters pipeline you may have oppties that are 4, 6, or 8+ quarters out (depending on your rules) and you most certainly don’t have an operating plan number that you’re trying to cover, nor is coverage even meaningful so far in advance. “When” means when in the quarter? 3.0x plan coverage makes sense on day 1; it makes no sense on day 50.

[4] As it turns out, 3.0x to-go coverage is likely an excessively high bar as you get further into the quarter. For example, by week 12, the only deals still forecast within the quarter should be very high quality. So the rule of thumb is always 3.0x, but you can and should watch how it evolves at your firm as you get close to quarter’s end.

[5] In times when the forecast is materially different from the plan, separating the concepts of to-go to forecast and to-go to plan can be useful. But, by default, to-go should mean to-go to plan.

[6] I know this from the extra columns presented in the screenshot from the same sheet in the previous post. We started this quarter at 96% of the ARR plan and while the never explicitly lists our prior-quarter plan performance, it seems a safe guess.

[7] If to-go coverage increases, we are closing business faster than we are losing it. If to-go coverage decreases we are “losing” (broadly defined as slip, lost, no decision) business faster than we are closing it. If the ratio remains constant we are closing business at the same ratio as we started the quarter at.

[8] A good sheet will list this explicitly, but you can calculate it pretty fast. If you have a pipeline of $7,000, a plan of $3,900, and coverage of 2.2x then: 7,000/2.2 (rounded) = 3,150 to go, with a plan of 3,900 means you have sold 750.

[9] An important metric that can be used as an additional triangulation forecast and is New ARR / Week 3 Pipeline.

8 Comments

Posted in Forecasting, Pipeline, SaaS, Sales, Salesops, Scaling, Startups