Category Archives: Startups

Using Time-Based Close Rates to Align Marketing Budgets with Sales Targets

This post builds on my prior post, Win Rates, Close Rates, and Milestone vs. Flow Analysis.  In it, I will take the ideas in that post, expand on them a bit, and then apply them to difficult problem of ensuring you have enough marketing demand generation budget to hit your sales targets.

Let’s pretend it’s 4Q17 and that we need to model 2018 sales based solely on marketing-generated SALs (sales accepted leads).  To do that, we need to decompose our close rate over time because knowing we eventually close 40% of SALs is less useful than knowing the typical timing in how they close over time.

decompose closed

In a perfect world, we’d have 6-8 cohorts, not two.  The goal is to produce the last line, the average of the in-quarter, first-quarter, second-quarter, and so on close rates for a SAL.

Using these time-based average close rates, we can build a waterfall that takes historical, forecast (for the current quarter), and planned 2018 SALs and converts them into deals.

waterfall

This analysis suggests that with the currently planned SALs you can support an ARR number of $16.35M.  If sales needs more than that, you either need to assume an improvement in close rates or an increase in SAL generation.

Once you’ve established the required number of SALs, you can then back into a total demand-generation budget by knowing your cost/SAL, and then building out a marketing mix of programs (each with their own cost/SAL) that generates the requisite SALs at the targeted overall cost.

Win Rates, Close Rates and Milestone vs. Flow Analysis

Hey, what’s your win rate?

It’s another seemingly simple question.  But, like most SaaS metrics, when you dig deeper you find it’s not.  In this post we’ll take a look at how to calculate win rates and use win rates to introduce the broader concept of milestone vs. flow analysis that applies to conversion rates across the entire sales funnel.

Let’s start with some assumptions.  Once an opportunity is accepted by sales (known as a sales-accepted opportunity, or SAL), it eventually will end up in one of three terminal states:

  • Won
  • Lost
  • Other (derailed, no decision)

Some people don’t like “other” and insist that opportunities should be exclusively either won or lost and that other is an unnecessary form of lost which should be tracked with a lost reason code as opposed to its own state.  I prefer to keep other, and call it derailed, because a competitive loss is conceptually different from a project cancellation, major delay, loss of sponsor, or a company acquisition that halts the project.  Whether you want to call it other, no decision, or derailed, I think having a third terminal state is warranted from first principles.  However, it can make things complicated.

For example, you’ll need to calculate win rates two ways:

  • Win rate, narrow = wins / (wins + losses)
  • Win rate, broad = wins / (wins + losses + derails)

Your narrow win rate tells you how good you are at beating the competition.  Your broad rates tells you how good you are at closing deals (that come to a terminal state).

Narrow win rate alone can be misleading.  If I told you a company had a 66% win rate, you might be tempted to say “time to add more salespeople and scale this thing up.”  If I told you they got the 66% win rate by derailing 94 out of every 100 opportunities it generated, won 4, and lost the other 2, then you’d say “not so fast.”  This, of course, would show up in the broad win rate of 4%.

This brings up the important question of timing.  Both these win rate calculations ignore deals that push out of a quarter.  So another degenerate case is a situation where you win 4, lose 2, derail 4, and push 90 opportunities.  In this case, narrow win rate = 66% and broad win rate = 40%.  Neither is shining a light on the problem (which, if it happens continuously, I call a rolling hairball problem.)

The issue here is thus far we’ve been performing what I call a milestone analysis.  In effect, we put observers by the side of the road at various milestones (created, won, lost, derailed) and ask them to count the number opportunities that pass by each quarter.  The issue, especially with companies that have long sales cycles, is that you have no idea of progression.  You don’t know if the opportunities that passed “win” this quarter came from the opportunities that passed “created” this quarter, or if they came from last quarter, the quarter before that, or even earlier.

Milestone analysis has two key advantages

  • It’s easy — you just need to count opportunities passing milestones
  • It’s instant — you don’t have to wait to see how things play out to generate answers

The big disadvantage is it can be misleading, because the opportunities hitting a terminal state this quarter were generated in many different time periods.  For a company with an average 9 month sales cycle, the opportunities hitting a terminal state in quarter N, were generated primarily in quarter N-3, but with some coming in quarters N-2 and N-1 and some coming in quarters N-4 and N-5.  Across that period very little was constant, for example, marketing programs and messages changed.  So a marketing effectiveness analysis would be very difficult when approached this way.

For those sorts of questions, I think it’s far better to do a cohort-based analysis, which I call a flow analysis.  Instead of looking at all the opportunities that hit a terminal state in a given time period, you go back in time, grab a cohort of opportunities (e.g., all those generated in 4Q16) and then see how they play out over time.  You go with the flow.

For marketing programs effectiveness, this is the only way to do it.  Instead of a time-based cohort, you’d take a programs-based cohort (e.g., all the opportunities generated by marketing program X), see how they play out, and then compare various programs in terms of effectiveness.

The big downside of flow analysis is you end up analyzing ancient history.  For example, if you have a 9 month average sales cycle with a wide distribution around the mean, you may need to wait 15-18 months before the vast majority of the opportunities hit a terminal state.  If you analyze too early, too many opportunities are still open.  But if you put off analysis then you may get important information, but too late.

You can compress the time window by analyzing programs effectiveness not to sales outcomes but to important steps along the funnel.  That way you could compare two programs on the basis of their ability to generate MQLs or SALs, but you still wouldn’t know whether and at what relative rate they generate actual customers.  So you could end up doubling down on a program that generates a lot of interest, but not a lot of deals.

Back to our original topic, the same concept comes up in analyzing win rates.  Regardless of which win rate you’re calculating, at most companies you’re calculating it on a milestone basis.  I find milestone-based win rates more volatile and less accurate that a flow-based SAL-to-close rate.  For example, if I were building a marketing funnel to determine how many deals I need to hit next year’s number, I’d want to use a SAL-to-close rate, not a win rate, to do so.  Why?  SAL-to-close rates:

  • Are less volatile because they’re damped by using long periods of time.
  • Are more accurate because they actually tracking what you care about — if I get 100 opportunities, how many close within a given time period.
  • Automatically factor in derails and slips (the former are ignored in the narrow win rate and the latter ignored in both the narrow and broad win rates).

Let’s look at an example.  Here’s a chart that tracks 20 opportunities, 10 generated in 1Q17 and 10 generated in 2Q17, through their entire lifetime to a terminal stage.

oppty tracking

In reality things are a lot more complicated than this picture because you have opportunities still being generated in 3Q17 through 4Q18 and you’ll have opportunities that are still in play generated in numerous quarters before 1Q17.  But to keep things simple, let’s just analyze this little slice of the world.  Let’s do a milestone-based win/loss analysis.

win-loss

First, you can see the milestone-based win/loss rates bounce around a lot.  Here it’s due in part due to law of small numbers, but I do see similar volatility in real life — in my experience win rates bounce within a fairly broad zone — so I think it’s a real issue.  Regardless of that, what’s indisputable is that in this example, this is how things will look to the milestone-based win/loss analyzer.  Not a very clear picture — and a lot to panic about in 4Q17.

Let’s look at what a flow-based cohort analysis produces.

cohort1

In this case, we analyze the cohort of opportunities generated in the year-ago quarter.  Since we only generate opportunities in two quarters, 1Q17 and 2Q17, we only have two cohorts to analyze, and we get only two sets of numbers.  The thin blue box shows in opportunity tracking chart shows the data summarized in the 1Q18 column and the thin orange box shows the data for the 2Q18 column.  Both boxes depict how 3 opportunities in each cohort are still open at the end of the analysis period (imagine you did the 1Q18 analysis in 1Q18) and haven’t come to final resolution.  The cohorts both produce a 50% narrow win rate, a 43% vs. 29% broad win rate, and a 30% vs. 20% close rate.  How good are these numbers?

Well, in our example, we have the luxury of finding the true rates by letting the six open opportunities close out over time.  By doing a flow-based analysis in 4Q18 of the 1H17 cohort, we can see that our true narrow win rate is 57%, our true broad win rate is 40%, and our close rate is also 40% (which, once everything has arrived at a terminal state, is definitionally identical to the broad win rate).

cohort7

Hopefully this post has helped you think about your funnel differently by introducing the concept of milestone- vs. flow-based analysis and by demonstrating how the same business situation results in a very different rates depending on both the choice of win rate and analysis type.

Please note that the math in this example backed me into a 40% close rate which is about double what I believe is the benchmark in enterprise software — I think 20 to 25% is a more normal range. 

 

Don’t Let Product Management Turn Into “The Roadmap Guys”

At many enterprise software companies product management (PM) ends up defaulting into a role that I can’t stand:  The Roadmap Guys*.

Like a restaurant with one item on the menu, the company defaults into ordering one thing from product management:  a roadmap pitch.

  • “The VP of PM is in Boston and Providence this week, can she visit some customers and do a few roadmap presentations?”
  • “Hey, there’s a local user group in NY this week; can PM do a roadmap pitch?”
  • “There’s a big customer in the executive briefing center today; can the PM do a roadmap?”
  • “As part of our sales cycle with prospect X, we’d love to get PM in to discuss the roadmap.”
  • “We’ve got a SAS day with Gartner next week, can PM come in a present the roadmap?”

You hear it all the time.  And I hate it.  Why?

From a sales perspective, roadmap presentations are the anti-sales pitch:  a well organized presentation of all the things your products don’t do.  Great, let’s spend lots of time talking about that.

From a competitive perspective, you’re broadcasting your plans.  If you’re presenting roadmap to every prospect who comes through the briefing center and at every local user group meeting, your competition is going to learn your roadmap, and fast.  Then they can copy it and/or blunt it.

But what irks me the most is what happens from a product management perspective:  you turn PM into “the talking guys” instead of “the listening guys.”  Given enough time, PM starts to view itself as the folks who show up and pitch roadmaps.

But that’s not their job.

PM should be the listening folks, not the talking folks.  Just like sales, PM should remember the adage:  we have two ears and one mouth; use them in proportion.

Wouldn’t the world be a better place if we changed the five previous bullets as follows?

  • “The VP of PM is in Boston and Providence this week, can she visit some customers and observe how people actually use the product?”
  • “Hey, there’s a local user group in NY this week; can PM break off a small focus group to ask customers about how they use the product?”
  • “There’s a big customer in the executive briefing center today; can PM come in and interview them about their impressions on evaluating the product?”
  • “As part of our sales cycle with prospect X, we’d love to get PM in to discuss what specifically they are trying to accomplish and how the product can do that?”
  • “We’ve got a SAS day with Gartner next week, can PM come in and hear from Gartner about what they’re seeing in the market and in their interactions with customers?”

So every time you hear the word “roadmap” in the same sentence as “product management,” stop, pause, and think of a better way to use the PM team.  Sure, there are certainly times when a roadmap presentation is in order.  But don’t default to it.  Keep your PM team listening instead of talking.

# # #

* I’m using “guys” here in a gender-neutral sense like “folks.”

Kellblog (Dave Kellogg) Featured on the Official SaaStr Podcast

Just a quick post to highlight the fact that last week I was the featured guest on Episode 142 of the Official SaaStr  podcast produced by the SaaStr organization run by Jason Lemkin and interviewed by a delightful young Englishman named Harry Stebbings (who also runs his own podcast entitled The Twenty Minute VC).

In the 31-minute episode — which Harry very nicely says was “probably one of his favorite interviews to record” — we cover a wide range of my favorite topics, including:

    • How I got introduced to SaaS, including my experience as an early customer of Salesforce in about 2003.
    • Challenges in scaling a software business, learned at BusinessObjects as we scaled from $30M to $1B in revenues, as well as at MarkLogic and Host Analytics.
    • My favorite SaaS metric.  If you had to pick one, I’d pick LTV/CAC.
    • Why simple churn is the best way to value the annuity of a SaaS business.
    • The loose coupling of customer satisfaction and renewal rates.
    • Why SaaS companies need to “chew gum and walk at the same time” when it comes to driving the mix of new and renewal business.
    • User-based vs. usage-based pricing in SaaS and how the latter can backfire in disincenting usage of the application.
    • My thoughts on bookings vs. ARR as a SaaS metric.  (Bookings is generally seen as a four-letter word!)
    • Why SaaS companies should make “the leaky bucket” the first four lines of their financial presentation.
    • Why I think it’s a win/win when a SaaS company gives a multi-year prepaid discount that’s less than its churn rate.
    • Why I view non-prepaid, multi-year deals as basically equivalent to renewals (just collected by finance/legal instead of customer success.)
    • Why it’s OK to “double compensate” sales and customer success on renewals and incidental upsells, and why it’s OK to pay sales on non-incidental upsells to existing customers (don’t put your farmer against someone else’s hunter).
    • Why you can’t analyze churn by analyzing churn and why you should have a rigorous taxonomy of churn.
    • My responses to Harry’s “quick fire” round questions.

You can listen to the podcast via iTunes, here.  Enjoy!

 

Can You Solution Sell without Selling Solutions?

Yes.  And for those who get the distinction, I’d might add, somewhat obviously.

But too many people don’t get it.  Too many folks equate “solution selling” with “selling solutions.”  In fact, they’re quite different.  So, in this post, we’ll try to make the world a better place by explaining the difference between selling solutions and solution selling [1].

What is Solution Selling?

First and foremost, Solution Selling is a book [2].  And it’s a book written by a guy, Michael Bosworth, who, if memory serves, was trying to sell Knowledge Management Software in the 1980s.  Never forget this.  Solution Selling wasn’t written by a guy selling easy-to-sell products in a hot category, such as (at the time) Oracle database or PeopleSoft applications.  Solution Selling was written by a guy trying to sell in a tough category. Look at the subtitle of the book:  “Creating Buyers in Difficult Selling Markets.”

Necessity, as they say, is the mother of invention.

When you’re selling in a hot category [3], this is what you hear from the market.

“Yes, we’re going to buy a business intelligence tool and Gartner tells us it should be one of Cognos, Brio, and you — so you’re going to need explain why we should pick you over the other two.”

Nothing about value.  Nothing about problems.  Nothing about ROI.  We’ve already decided we’re going to buy one and you need to convince us why to buy yours.  [4]

When you’re selling in a cold category, the conversation goes something like this:

“A what?  An XML database system?  Wait, didn’t Gartner call that ‘the market that never was’ about two years ago — why in the world would anyone ever buy one of those.” [5]

In the first case, the sales cycle is all about differentiation.  In the second case, it’s all about value.  In the first case, it’s why buy one from me.  In the second, it’s why buy one at all.

Solution selling is the process of identifying a business problem that the product solves, finding the business owner of that problem, and selling them on the value of solving that problem and your ability to do so.

To use my favorite marketing analogy [6], solution selling is the process of selling the value of a ¼” hole.  Product selling is talking all about the wonderful titanium that’s in the ¼” drill bit.

For example, at MarkLogic we sold the world’s finest XML database system and XQuery processing engine.  In terms of market interest, that plus $3 will get you a tall latte.  That is, no one cared.  You could call up IT people and database architects and database administrators all day and tell them you had the world’s finest XQuery engine and no would care.  They weren’t interested in the category.

Certain businesspeople, however, were quite interested in what you could do with it.

  • If you called the SVP of K-12 Education at Pearson and talked about solving the tricky problem of customizing textbooks to meet many and varied state regulations, you’d get a call back.
  • If you called an intelligence officer at your favorite three-letter agency and talked about gathering, enriching, and querying open source content to build next-generation OSINT systems, you’d get a call back.
  • If you called the SVP of Digital Strategy at McGraw-Hill and talked overall about how the industry needed to separate content from the container in building next-generation products in response to the massive threat to media caused by Google, you’d get a call back.

Simply put, if you called a person about an important problem that they needed to solve, they’d call you back.  Whether they’d buy from you would come down to the extent they believed you can solve the problem based on several factors including a technology assessment, conversations with reference customers for whom you’ve solved the problem before, the cost/benefit associated with the project, and whether they wanted to work with you. [7]

What is Selling Solutions?

Geoffrey Moore refers to an important concept called “whole product” in Crossing the Chasm.  And it’s the idea that you’re not just selling technology platform to your beachhead market, you’re selling the fact that you know how to solve problems with it. Solving those problems might require hundreds of hours of consulting services, integration with complementary third-party software packages, and data integration with existing core systems.

But nobody said the “whole product” had to be packaged up, for example, as a set of templates that you customize that help accelerate the process of solving the problem.  This is the zone of “solutions.”

Many companies, early in their lifecycle for focus reasons or late in their lifecycle to increase the size of a saturating market [8], decide they want to package up a solution after repeatedly solving a problem in a certain area.  This often starts out as leftover consulting-ware and over time can evolve into a set of full-blown applications.

At most software companies, particularly bigger ones, when you start talking about packaged solutions, this is what you mean:  the combination of know-how and leftover intellectual property (IP) from prior engagements not licensed as software product but nevertheless used to both accelerate the time it takes to build the solution and reduce the risk of failure in so doing.

For example, during my time at MarkLogic, we often debated whether and to what extent we should create a packaged custom publishing solution or simply think of custom publishing as a focus area, something that we had a lot of know-how in, and re-use whatever leftover IP we could from prior gigs without glorifying it as a packaged solution.  Because the assignments were so different (publishers used as the the platform to build their products) we never opted to do so.  Had we been selling a business-support application as opposed to do product development platform, we probably would have.

The Difference Between Solution Selling and Selling Solutions

Solution selling is an approach to (and a complete methodology for) the sales process.  Selling solutions means selling packaged, typically application-layer, know-how typically built into a series of templates and frameworks that help accelerate the process of solving a given problem.

They are different ideas.

You can solution sell without a single packaged solution in your product line.  To again answer the question posed by the title of this post:  Yes, you can solution sell without selling solutions.

Solution selling is simply an approach to how you sell your product.  Certainly it can be easier to solution sell when you are selling solutions.  But it is not required and one is not tantamount to the other.

# # #

Notes

[1] In fact, rather perversely, you can sell solutions without solution selling.  If your company built a custom-tailored solution to solve a specific business problem and if you sold it emphasizing the features of the solutions (i.e., “feeds and speeds”) without trying to understand the customer’s specific business problem and its impacts, then you’d be guilty of product-selling a solution.  See end of the post.

[2] Which has largely been replaced by the author’s next book, Customer Centric Selling, but which – like many classics – was better before it was “improved” in my humble opinion.

[3] Which leads to one of my favorite sayings:  “if you have to ask if you’re working in a hot category, you’re not.”  If you were, two things would be different:  first, you’d know and second, you’d be too busy to ask.  QED.

[4] Which results in what I call an “axe battle” sales process, reminiscent of knights in heavy armor swinging axes at each other where each is blow can be thought of as feature.  “We have aggregate awareness, boom.”  “We have dynamic microcubes, boom.”  And so on.

[5] Gartner did, in fact, say precisely this about this XML database market, but that didn’t stop us from building MarkLogic from $0 to an $80M revenue run-rate during my six years there.  It did, however, provide a huge clue that we needed to adopt a solution-selling methodology (and bowling-alley strategy) in so doing.

[6] “Purchasing agents buy ¼” holes, not ¼” bits.”  Theodore Levitt.

[7] Because a startup can only develop this fluency and experience in a small number of solutions, you should cross the chasm by focusing on an initial beachhead and then build out into other markets through adjacencies (aka, bowling alley strategy) as described in Inside the Tornado.  In many ways, the solution selling sales methodology goes hand in hand with these strategy books by Geoffrey Moore.

[8] Geoffrey Moore calls these +1 additions that help grow the market as the once-hot core technology market saturates and you need to switch back to a solution focus if you wish to increase the market size.

Are You a “Challenging” or Simply a “Difficult” Direct Report?

Most managers, save for true sycophants, want to challenge their boss.  Few managers want to be puppet yes-people to the boss.  They’ve worked hard to get where they are.  They bring years of wisdom and experience.  They want to push and challenge.  But many don’t know when or how.  More importantly, they don’t know what they don’t know.

How often do you think you’re challenging the boss when he/she thinks you’re just being plain difficult?  Challenging direct reports keep their positions and rise with the organization.  Difficult ones get jettisoned along the way.

There are two great ways you can figure out how often you’re being which:

  • Think of things from the boss’s perspective
  • Ask the boss

Think from the Boss’s Perspective

Bosses want to get things done.  Things generally fall into two buckets:  easy and hard.  Easy things may still entail a lot of work and planning, but there’s nothing really conceptually difficult or unknown about them.

Running the company’s presence at a tradeshow you attend every year might be a lot of work, but I’ll consider it easy for this conversation because that work is known.

Deciding to terminate a problem employee is easy.  (Note inclusion of word “problem.”)  If you see a problem, the adage goes, everyone else has probably already seen it for months and the damage done is more than you know.  This decision is hard from a personal perspective — I’ve never met anyone who enjoys terminating people.  But firing someone who routinely misses deadlines, training sessions, and team meetings isn’t hard in this context.

Launching the new version of a product is easy.  Yes, the positioning may be hard, but managing the overall launch process is easy.   It’s hopefully done a few times per year.  Yes, it’s a lot of work and planning, but there’s nothing conceptually difficult about running the process.

Difficult direct reports make easy things hard.  How?

  • Complexification.  When you ask someone the time you discover that there are three types of people in the world:  those who tell you the time, those who tell you how to build a watch, and those who tell you how to build a Swiss village.  Simplifiers go far in organizations, complexifiers get stuck.
  • Lack of follow through.  Bosses want to talk once about a project, agree to it, and then have it get executed.  As my friend Lance Walter always said bosses want “set it and forget it” direct reports.  If you have a question, come ask.  But otherwise I assume you are tracking our agreed-to objectives and they’re going to happen without me having to check and re-check.  Ditto for feedback given along the way.
  • Drama.  Difficult directs tend to take things personally.  They turn criticism of work into criticism of them.  They view a heavy workload as dramatic sacrifice and not a prioritization problem.  They are sensitive to criticism, defensive when questioned or given feedback, and often unable to separate bad performance from bad intent.

The result is that over time the boss starts to loathe the idea of meeting with the direct report which results in a downward spiral of communication and relationship.

Challenging direct reports keep easy things easy.  They get shit done without a lot of supervision, complexification, or drama.  On the flip side, challengers don’t just go along for the ride when it comes to inherently hard things like fixing a break in the sales pipeline, selecting company or product strategies, or working on a competitive campaign strategy.  They weigh in, sometimes challenging the majority or consensus view.  They provide good arguments for why what everyone else is thinking could be wrong.  Their selective Devil’s advocacy helps the company avoid groupthink and the organization make better decisions.  And they do this without going overboard and positioning themselves as the resident contrarian.

Simply put, when you say something to the boss or in a meeting, imagine how the boss will react and then count the ratio between the following two reactions

  • God, what a pain in the ass.
  • Wow, I hadn’t thought of that.

Ratios above 1.0 indicate you are a net difficult direct report.  Ratios below 1.0 indicate you are a net challenger.

Ask the Boss

Since knowing is always superior to guessing, I’ll give you a set of good questions that can help you figure out where you stand.

  1. If you had to rank your direct reports from top to bottom in terms of difficultly, would I fall above or below the median and why?
  2. Can you please list 3-5 things I do that make it difficult to manage me so I can work on them?
  3. To what extent do you find me difficult/contrarian for difficulty’s sake vs. genuinely challenging ideas and helping the company reach better decisions?
  4. When it comes to strategic debates do you feel that I sit on the sidelines too much, participate too much, or strike a good balance?
  5. If there is a pattern of skipped/cancelled 1-1’s (a sign of avoidance) or higher frequency 1-1’s with other directs, then ask why?

Sycophants know they are sycophants.  Challengers usually know they are challengers.  The risk is that you are a difficult when you think you’re a challenger — and that rarely ends well.  So think about, ask, and take appropriate measures to correct the situation.  Before your boss doesn’t want to talk to you anymore.

Simple Rules to Make It Easier To Build Your Startup’s Board Deck

As someone who has assembled many startup board decks over the years, I thought I’d offer some advice to executives who contribute slides to board decks that should make it easier for the point-person to assemble, improve the deck’s appearance, and avoid any painful and/or embarrassing mistakes in the process.  Marketing folks, who both build a lot of presentations and live in PowerPoint, tend to get these basics right.  Everybody else, in my experience, not so much.

  • You are your metrics.  Remember the old quote that’s often misattributed to Peter Drucker, “if you can’t measure it, you can’t manage it.”  I prefer its corollary, “if you’re not measuring it, you’re not managing it.”  And, in turn, its corollary, “if you’re not presenting it at a board meeting, then you don’t care about it.”  Remember, the metrics you choose to present — and perhaps more importantly those you choose not to present — say a lot about you and what you think is important.  Put real thought into selecting them.
  • Take the time to write a short letter.   Remember the again often-misattributed quote from Blaise Pascal:  “if I had more time, I would have written a shorter letter.”  It’s your board — take the time to include as few slides (and as few numbers per slide) as are needed to tell the story.  But no fewer.  Don’t make the classic mistake of just grabbing your ops review slides and pasting them into your board deck.  Don’t make the deck assembler have to decide which slides, from a pile you provided, should be in the deck.
  • Provide context for numbers.  Repeat after me:  the board is not afraid of numbers.  So don’t be afraid to present them.  Don’t drown them — be selective in which metrics you show.  But when you choose to show a metric, provide context so board members can analyze it.  That means providing trailing nine quarters of history, sequential and YoY growth rates, and % of plan attainment.  Thus, each metric translates to 12 numbers, so pick your metrics carefully.
  • Use the right design template.  Assembly is much easier if everyone is using the same corporate slide template, ideally a confidential version of it that includes good security footers (e.g., Company Confidential and Proprietary, Internal Use Only).
  • Learn how to use slide layouts.  Don’t be the guy putting text boxes onto blank slides when you should be using the Title+Content layout.  One great part about using layouts is re-applying them to make sure you, or a prior author, hasn’t changed anything.
  • Don’t hack the layout.  If your layout doesn’t include a subtitle, don’t use one.  It just makes it harder to reformat things downstream.  Plus, too many folks are lazy and make a sequence of slides with the same title, only varying the subtitle.  Bad habit.  Integrate the two and make varying titles.  Less is more.
  • Don’t put numbers into embedded tables.  The easiest way to get math errors in your board slides if to either cut/paste or re-type numbers into embedded Word tables.  Use embedded worksheets for numbers and ideally do live total calculations to ensure all the numbers are right.
  • Be careful as heck with embedded worksheets.  That said, note that Office has a terrible habit of taking the whole workbook along for the ride when you paste a table as an embedded object.  Don’t be the person who pastes in a table of payroll by department, accidentally including everyone’s salary on an adjacent tab, and then mailing that not only to the board, but also the whole executive team.
  • Paste charts as images.  The major upside here is you eliminate problems related to the prior point, the downside if you give zero power to the deck-assembler to fix things at 2 AM.  The best practice is to ship your slides with charts pasted as images and attach a separate Excel file as the source.  That way, you both reduce risk and give the assembler the power to change things if needed.
  • No more than one table of numbers per slide.  While board members love numbers, don’t mentally overload them with too many concepts on a single slide.
  • Use a standard capitalization convention.  I Recommend Title Case for Slide Titles.  I recommend sentence case for slide body copy.  It’s a pain in the neck to fix this if everyone is doing something different.
  • Use a standard convention for notes and sources.  I use * and ** and put the notes (which are often data sources) in 8-point type right above my confidentiality footer.  It doesn’t matter where you do it; what matters is that everyone puts them in the same place.
  • Don’t use slide notes.  In reality, you have two choices here — either always distribute your board slides in PDF or never use slide notes.  Any middle ground is very dangerous — imagine copying a slide from someone else’s deck that has embarrassing commentary in a slide note that you don’t notice, but a board member does.  Ouch.
  • Type text directly on objects.  Don’t create a separate text box and then put it atop on object; make the text and the object one.

If everyone on the e-staff follows these tips you’ll end up with a better board deck and it will take whoever assembles it — often the CEO at smaller companies — far less time to do so.