Book Review of Good Strategy, Bad Strategy by Richard Rumelt

Good Strategy, Bad Strategy by UCLA Anderson professor Richard Rumelt is by far my favorite book on strategy.  In this post I’ll explain why I love this book, provide an overview of Rumelt’s core concepts, and offer a few thoughts on (and dare I say an enhancement to) his strategy framework.

Why I Love This Book
I love this book for two reasons.  First, he skillfully eviscerates all of the garbage that far too often passes for strategy in corporate America.  It’s borderline therapeutic to watch him tear down case after case of junk that is pitched by executives and consultants as strategy.  His four telltales:

  • Fluff.  Corporate doublespeak that,“uses ‘Sunday’ words and apparently esoteric concepts to create the illusion of high-level thinking.”
  • Failure to face the challenge“Bad strategy fails to recognize of define the challenge.  If you can’t define the challenge, you cannot evaluate a strategy.”
  • Mistaking goals for strategy.  Here at the center of the OKR universe, it’s common to find companies with lists of “statements of desire” rather than “plans for overcoming obstacles.” [1]
  • Bad strategic objectives“Strategic objectives are ‘bad’ when they fail to address critical issues or when they are impracticable.”

His dismemberment of bad strategy is so surgical and so deft that it alone is worth the price of the book.

The second thing I love about this book is focus.  As my high school Latin teacher, Mr. Maddaloni, always reminded us:  focus is singular [2].  Most companies — often due to the group consensus process used to create strategy — fail at rising to the challenge of picking and end up with multiple, strategic foci instead of a single, strategic focus [3].

This can reflect avoidance of a dead moose issue threatening the company or simply lead to a laundry list of incoherent and unattainable goals.  Either way, Rumelt’s approach sidesteps this problem by forcing the company to focus on a single issue.

The Core Concepts of Good Strategy, Bad Strategy
Per Rumelt, “good strategy is coherent action backed up by an argument, an effective mixture of thought and action with a basic underlying structure called the kernel.”

Excerpt:

The kernel of a strategy contains three elements:

A diagnosis that defines or explains the nature of the challenge. A good diagnosis simplifies the often overwhelming complexity of reality by identifying certain aspects of the situation as critical.

A guiding policy for dealing with the challenge. This is an overall approach chosen to cope with or overcome the obstacles identified in the diagnosis.

A set of coherent actions that are designed to carry out the guiding policy. These are steps that are coordinated with one another to work together in accomplishing the guiding policy.

This is brilliant in its simplicity and in its recognition that a huge part of strategy is an accurate and insightful simplification of the situation:  determining which elements are essential and boiling it down to a short, simple narrative as to “what’s going on”  and ergo what to do about it.

I use a trick to indirectly make this point when I’m in a strategy meeting.  At some point the discussion inevitably fades into, “argh, this is so complicated, there are so, so many things to consider” and room is lost to sense of hopelessness.  I’ll then ask one of the participants, “can you tell me the story of the last company you worked at?”

You’ll usually hear something like this in response:

  • “We pushed too far up market without the product to support it.”
  • “We got caught in a squeeze between a high-end enterprise vendor and low-end velocity disrupter.”
  • “We got out-marketed by a company with more capital and a more aggressive team.”

I’ll then say, “why do you suppose it’s so easy for us to tell short, simple stories about our prior employers but nearly impossible to make one about us?  What do you think we’ll say in four years about this company?”  It’s the same idea as Rumelt’s — to force simplification of the story to its core narrative and to focus on one thing in the diagnosis.  We do it naturally when looking at the past.  In the present, we resist it like the plague.

I believe that 80% of strategy is the diagnosis — and sometimes the diagnosis simply can’t get made through a group process, but instead has to be decided by the CEO [4] [5].  The other half, to paraphrase Yogi Berra, is the guiding policy and coherent actions.

Thoughts on the Framework
While I love the fact that Rumelt forces executives to diagnose the single most important challenge facing the company — and avoid creating lists of many such challenges — doing so is quite difficult for both good and bad reasons.

The good reason is that it forces “table stakes” conversations, well, “off the table.”  If it’s a discussion about something that everyone in the industry must do (e.g., build quality product, train and scale sales), then it’s almost definitionally not the single most important challenge facing that company.  That’s good, because while those table stakes operations are undoubtedly hard work, they are not strategic.  Operating executives too often confuse the two.

The bad reason it’s difficult is that you might get it wrong.  And in this framework, where everything is tied to a diagnosis about the company’s single-most important challenge, if you get the diagnosis wrong, the whole strategy collapses along with it.

The hardest part I’ve found is balancing immediate vs. longer-term challenges.  For example, say it’s 2003 and you’re at CRM leader Siebel Systems.

  • Your most immediate challenge is likely your direct competition, PeopleSoft or Oracle who are much larger than you and providing broad suites.
  • Your biggest strategic challenge is your indirect competitor Salesforce.com, who is disrupting the business model with software as a service.

Perhaps one of my friends who worked at Siebel at the time can weigh in with an informed comment, but my guess is that Siebel (who was doing $1.4B in annual revenue) minimized Salesforce (who reported doing a mere $65M in its S-1) and, to the extent they would have used a framework like this, would have picked the wrong challenge and gotten the wrong strategy as a result.

Another potential criticism of this framework is that it tends to orient you to competitive threats in a Silicon Valley that would much rather talk about vision (and making the world a better place) than competition.  In my experience, there are few vendors who have the luxury of being totally vision-driven, those who claim otherwise are often practicing revisionism [6], and there’s nothing in the framework, per se, that says the central challenge has to be competition-related.  It could be about building the product, creating distribution channels, or landing your first ten customers.  The framework doesn’t dictate the nature of the challenge, it simply demands that you pick one.

My last thought on the framework is that it appears to be missing an element [7].  In order to make a guiding policy from a diagnosis it helps to have a set of beliefs (or assumptions) as the bridge in between, because these beliefs are neither an explicit part of the guiding policy nor necessarily documented in the diagnosis.

So my slightly revised format of the template is:

  • Diagnosis:  the single most important challenge faced by the company (where immediate or strategic)
  • Beliefs:  a short list of key assumptions that bridge from the diagnosis to the guiding policy.
  • Guiding policy:  the overall approach to dealing with the challenge
  • Coherent actions:  a set of actions designed to carry out the guiding policy

Or, in English form, given the diagnosis and this set of beliefs, we have chosen this guiding policy which is to be carried out by this set of coherent actions.

Closing Thoughts
I’d say that while I love this book it might have been better titled Bad Strategy, Good Strategy because it’s stronger at tearing apart the garbage that masquerades as strategy than it is at helping you build good strategy yourself [8].  That said, if you can learn by example and through emulation of the many good strategy examples Rumelt provides, it should be enough to help you and your company not only avoid falling for garbage instead of strategy, but building a good strategy yourself.

I’ll end with the best news of all:  I wrote Rumelt to ask him a few questions and he told me that he’s working on a new book that should address some of my issues.  I can’t wait to read it.

# # #

Notes
[1] OKRs are great and I love OKRs.  But OKRs are for establishing clarity about goals, their unambiguous measurement, and (typically by omission) their priority.  OKRs should be implied by a strategy, but the existence of OKRs (particularly an overly long or incoherent set) does not imply the existence of strategy.

[2] The plural, of course, being foci.

[3] A common case of this is simply failing to make a strategy at all, instead saying (as I’ve actually heard at strategy meetings), “we’ll we’re going to need two financial goals, two sales goals, two product goals, a marketing goal, a customer goal, an alliances goal, and a people goal, so there you go, that’s 10, so let’s just sit down and start making them.  I know the people goal (“attract, develop, and retain the best talent”) and customer goal (“delight our customers”) already, so there’s only 8 more to go.”

[4] I’m slightly twisting Rumelt’s example of a Condorcet Paradox which was really about strategy formulation, not diagnosis, but to the extent that people often gun jump in offering a diagnosis that leads to their desired strategy it still holds.  Adapting his example, the Services person wants a diagnosis that leads to Solutions, the design head wants a diagnosis that leads to Chips, and the systems person wants a diagnosis that leads to Boxes.  The paradox actually occurs not there, but in how each ranks the relative strategies.

[5] If everyone on the team can agree to it, I’d argue it’s almost definitionally a bad strategy.  In a good strategy choices are made, some areas are resources, others are starved, and some are discontinued.  The Chips person voting for Solutions would be, as the saying goes, like the turkeys voting for Thanksgiving.

[6] In conference talks and podcasts it’s far cooler to talk about being vision-driven than talking about competitive strategies; thus I have found the best companies talk little about the competition externally, but are fiercely competitive internally.

[7] Hat tip to my friend Raj Gossain for figuring this out.

[8] By this I mean that while the book provides examples of good strategy, and a simple framework for expressing it, I find the framework missing an important element (beliefs) and the book doesn’t even attempt to outline a process whereby an executive team can work together to devise a good strategy.

Ten Pearls Of Enterprise Software Startup Wisdom From My Friend Mark Tice

I was talking with my old friend, Mark Tice, the other day and he referred to a startup mistake as, “on his top ten list.”  Ever the blogger, I replied, “what are the other nine?”

Mark’s been a startup CEO twice, selling two companies in strategic acquisitions, and he’s run worldwide sales and channels a few times.  I first met Mark at BusinessObjects, where he ran our alliances, we worked together for a while at MarkLogic, and we’ve stayed in touch ever since.  Mark’s a seasoned startup executive, he’s go-to-market oriented, and he has some large-company chops that he developed earlier in his career.

Here’s an edited version of Mark’s top ten enterprise software startup mistakes list, along with a few comments prefaced by DK.

1. Thinking that your first VP of Sales will take you from $0 to $100M.  Startups should hire the right person for the next 18-24 months; anything beyond that is a bonus.  (DK:  Boards will often push you to hire someone “bigger” and that’s often a mistake.) 

2. Expecting the sales leader to figure out positioning and pricing.  They should  have input, but startups should hire a VP of Marketing with strong product marketing skills at the same time as the first VP of Sales. (DK:  I think the highest-risk job in Silicon Valley is first VP of Sales at a startup and this is one reason why.)

3. Hiring the wrong VP Sales due to incomplete vetting and then giving them too much runway to perform.  Candidates should give a presentation to your team and run through their pipeline with little to no preparation (and you should see if they pay attention to stage, last step, next step, keys to winning).  You should leverage backdoor references.  Finally, you should hire fast and fire faster — i.e., you’ll know after 3 months; don’t wait for more proof or think that time is going to make things better.  (DK:  a lot of CEOs and boards wait too long in denial on a bad VP of Sales hire.  Yes, starting over is difficult to ponder, but the only thing worse is the damage the wrong person does in the meantime.)

4. Marketing and selling a platform as a vertical application.  Having a platform is good to the extent it means there is a potentially large TAM, but marketing and selling it as an application is bad because the product is not complete enough to deliver on the value proposition of an application.  Align the product, its positioning, and its sales team — because the rep who can sell an analytic platform is very different from the rep who can sell a solution to streamline clinical trials.  (DK:  I think this happens when a company is founded around the idea of a platform, but it doesn’t get traction so they then fall back into a vertical strategy without deeply embracing the vertical.  That embrace needs to be deeper than just go-to-market; it has to include product in some way.)

5. Ignoring churn greater than 15%.  If your churn is greater than 15%, you have a problem with product, market, or most likely both. Don’t ignore it — fix it ASAP at all costs.  It’s easy to say it will get better with the next release, but it will probably just get a bit less bad.  It will be harder to fix than you think. (DK:  if your SaaS bucket is too leaky, you can’t build value.  Finding the root cause problem here is key and you’ll need a lot of intellectual honesty to do so.)

6. Waiting too long to create Customer Success and give it renewals.  After you have five customers, you need to implement Customer Success for renewals and upsells so Sales can focus on new logos. Make it work. (DK:  Truer words have never been spoken; so many startups avoid doing this.  While the upsell model can be a little tricky, one thing is crystal clear:  Customer Success needs to focus on renewals so sales can focus on new ARR.)

7. Pricing that doesn’t match the sales channel.  Subscriptions under $50K should only be sold direct if it’s a pilot leading to a much larger deployment.  Customers should become profitable during year two of their subscription. Having a bunch of customers paying $10K/year (or less) might make you feel good, but you’ll get crushed if you have a direct sales team acquiring them. (DK:  Yes, you need to match price point to distribution channel. That means your actual street price, not the price you’re hoping one day to get.)

8. Believing that share ownership automatically aligns interests.  You and your investors both own material stakes in your company.  But that doesn’t automatically align your interests.  All other things being equal, your investors want your company to succeed, but they also have other interests, like their own careers and driving a return for their investors.  Moreover, wanting you to succeed and being able to offer truly helpful advice are two different things.  Most dangerous are the investors who are very smart, very opinionated, and very convincing, but who lack operating experience.  Thinking that all of their advice is good is a bit like believing that a person who reads a lot will be a good author — they’ll be able to tell you if your go-to-market plan is good, but they won’t write it for you. (DK:  See my posts on interest mis-alignments in Silicon Valley startups and taking advice from successful people.)

9. Making decisions to please your investors/board rather than doing what’s best for your company. This is like believing that lying to your spouse is good for your marriage. It leads to a bad outcome in most cases.  (DK: There is a temptation to do this, especially over the long term, for fear of some mental tally that you need to keep in balance.  While you need to manage this, and the people on your board, you must always do what you think is right for company.  Perversely at times, it’s what they (should, at least) want you to do, too.)

10. Not hiring a sales/go-to-market advisor because they’re too expensive.  A go-to-market mistake will cost you $500K+ and a year of time. Hire an advisor for $50K to make sure you don’t make obvious mistakes.  It’s money well spent.  (DK:  And now for a word from our sponsor.)

Thanks Mark.  It’s a great list.

Branded Features: Resist the Temptation

Software startups seem drawn by sirens to brand their features. Hey, Apple does it.  Think:  Siri, Facetime.  Microsoft tries it:  Cortana.  Starbucks even brands a cup size:  Venti.  So if they can do it, we should too, right?

Wrong [1].

49557741_s

But it’s so cool.  Imagine it’s a long time ago and we’re about to launch the first DBMS with stored procedures [2].  Shouldn’t we call them Intelliprocs™ as opposed to plain, old stored procedures?

Then our competitors won’t be able to copy Intelliprocs!

Wrong.  If that’s what you want, get a patent, not a trademark.

Oh, well, then our competitors won’t be able to call them Intelliprocs.

That’s correct.

But we’ll make Intelliprocs the industry term and we’ll  be widely acknowledged as having created both the term and the feature.  Customers will ask competitors if they have Intelliprocs, too!  It will be like going to Peet’s and asking for a Venti latte!

Wrong.  In fact, calling them Intelliprocs and trademarking it virtually guarantees that won’t happen.  The industry will be forced to call them anything but Intelliprocs.  Furthermore, Intelliprocs sounds stupid, and no self-respecting database architect is going to call them that.

By the way, we’re a small company.  Most prospective customers are yet to hear of us here at Sybase [2], so we’re going to dilute our branding efforts.  Instead trying to make people know that Sybase means fast relational DBMS, we’re going split our efforts between that and getting them to first learn the term Intelliprocs and second that Intelliprocs come from Sybase.  That’s three branding efforts when we should be putting all our wood behind one arrow.

Plus, where does it end?  If we call stored procedures Intelliprocs, should call fast commit QuickCommit™, on-line backup ContinuBack™, optimistic locking OptiLock™, group commit GroupFlush™.  You’ll need a thesaurus to understand us when we speak.  And to what end?

If we want the industry to use our language and to know that we invented [3] these features, we should give them common, descriptive names so that others will use them, and then we can market — to the industry and its influencers — the fact that we were the first to deliver them.  That’s how you get known as an innovator.

We’ll save money by not having to register all those marks in 47 countries around the world.

Speaking of international, descriptive features names translate better into other languages than branded names.  If you think we’ll be hard to understand when we speak English, imagine how hard it will be when we’re speaking French, Greek, or Mandarin — with all these untranslatable, English-rooted, branded feature names popping up every two seconds.

We’ll be in a way better position, legally, when it comes to defense.  If we name stored procedures descriptively, it will help us if someone else claims our name is their mark.  We’ll just argue, correctly, that it’s a descriptive name and not a brand.  The more “brandy” we name them, the harder that is to do.  So our branding strategy should be to have one brand, Sybase, and then name everything (e.g., products, features) else descriptively.  It the best marketing, and the best legal, strategy.

Last of all, remember branding first principles.  It’s Jell-O brand gelatin.  Levi’s brand denim jeans.  Kleenex brand tissues.  Zoom brand videoconferencing.  Tinder brand dating.  While you certainly can brand features, the primary purpose is to name and differentiate your company’s offering from the other ones.  Branding is not first and foremost about features.  It’s about companies.

So, if you’re not a multi-billion-dollar company, then maybe you shouldn’t emulate the marketing strategy of one.  If you take a breath, pause, and think about what it means to create branded features — to your branding, to your comprehensibility, to your industry leadership, to your international operations, to your legal strategy (and associated costs) — you’ll decide to pass on branded features every single time.

# # #

Notes

[1] This post is a fresh take on a post I did in 2006 entitled On Branded Features, which actually uses the same example.

[2] This is a fictitious conversation about a real example.  Sybase was the first relational database to introduce stored procedures.

[3] See note 2.

[4] Closer to reality, first brought to the relational DBMS more than invented.

All trademarks are the property of their respective owners.

 

Upcoming PMM Hive Interview, Marketing Strategy in Hot vs. Cold Markets

Just a quick post to plug my upcoming appearance on a podcast / live interview hosted by PMM Hive, a product marketing community that was recently launched by my old friend and colleague Crispin Read, and that’s already loaded with some superb product marketing content.  Check it out.

I’m excited about this session both because it’s one of my favorite topics and because Crispin is one of my favorite marketers.  The topic is critical because too many marketers (and CEOs) hit rewind/play on their last successful experience without considering their situation and the marketing strategy that should support it.  Crispin’s great because he’s world-class at messaging and positioning, sharp as a tack, enjoys what we’ll call “spirited debate,” and has a dry English sense of humor that keeps things not only interesting, but fun.

The session is on July 8, 2020 at 9:00 California time.  You can register here if interested.  Playback should be available after the event if you’re interested and can’t make it.

Hope to see you there!

Why You Should Eliminate the Title “Implementation Consultant” from Your Startup

I’ve worked with several startups that fell into the following pattern:

  • Selling a SaaS application at a healthy price (e.g., $100K to $200K ARR)
  • With low, fixed-cost implementation packages (e.g., $25K)
  • But a product that actually takes maybe $50K to $75K to successfully deploy
  • Resulting in an unprofitable professional services business (and wrecking the market for partner services)
  • High adoption failure
  • And, depending on the initial contract duration, high customer churn [1]

For example, one company had a CAC of 4.0, churn of 25%, and services margins of negative 66% when I started working with them [2].  Ouch.

Before proceeding, let me say that if you have a low-touch, high-velocity, easy-adoption business model — and the product to go with it — then you don’t need to read this post [3].  If you don’t, and any of the above problems sound familiar, then let’s figure out what’s going on here and fix it.

The problem is the company is not charging the appropriate price for the services needed.  Perhaps this is because of a zero-sum fallacy between ARR and services.  Or perhaps they feel that customers “just won’t pay” that much for implementation services.  Or perhaps their product takes more work to deploy than the competition and they feel forced to match price on services [4].

This under-pricing usually triggers a number of other problems:

  • In order to work within the self-created, low-cost implementation services model, the company “hires cheap” when it comes to implementation consultants, preferring junior staff and/or staff in offshore locations.
  • The company’s “implementation consultants” are overloaded, working on too many projects in parallel, and are largely focused more on “getting onto the next one” than getting customers successfully implemented.
  • Once a certain number of hours are clocked on any given project, the consultants go from “in a hurry” to “in a big hurry” to finish up and move on.
  • Customers are left high-and-dry with failed or partial implementations that, if left unfinished, will likely lead to churn.
  • Customer success, whose job is to prevent churn, is left holding the bag and is pulled away from its primary mission of adoption, renewal, and expansion into the implementation-completion business, potentially changing its hiring profile from more sales-oriented to more product-oriented and/or complementing CSMs with customer success architects (CSAs) or technical account managers (TAMs) to try and fill the implementation void.

I sometimes consider fixing this corporate chiropractor work, because one maladjustment results in the whole organization being twisted out of shape [5].  The good news is that, as with chiropractors, one adjustment can pop the whole system back into alignment.

Now, before we move onto fixing this, there’s one more problem we haven’t discussed yet — and give yourself ten pats on the back if you figured out before I got here:

Who ever said the customer defined success as getting the software implemented?

Oh shit.  We were so tied up trying to deliver a $25K services package that costs $40K to deliver that we forgot about the customer.  What customer equates implementation with success?  None.  Zero.  Nobody.

“Hey, it’s all set up now, you can login, gotta go!” is not the credo of a success-oriented consultant.

But what do we call our consultants again?  Implementation consultants.

What do implementation consultants think they do?  Well, implementations.

When an implementation consultant reads their own business card, what does it tell them they their job is?  Implementations.

Are implementations what customers want?  No.

So why do we have implementation consultants again?  I have no idea.

What do customers what?  Overall they want success, but what’s a good proxy?  How about attaining their first business objective?  If you sell:

  • A recruiting app, running your first recruiting campaign
  • A financial planning app, it’s making your first plan
  • A demandgen marketing app, it’s running your first demandgen campaign
  • A customer service app, it’s your first day running the call center
  • A deflection app, it’s deflecting your first cases
  • A sales enablement app, it’s training your first reps
  • An IT support app, it’s handing your first tickets

So, what’s the fix here?  While not all of this will be possible or recommended in all situations, here’s the long list:

  • Re-frame services as in the success business, not the implementation business
  • Eliminate the job title implementation consultant in favor of consultant
  • Get services to make plans that end not with implementation, but with the achievement of an agreed-to first business objective.
  • Increase your services pricing, if needed, so they can both deliver success and break even.
  • Hire more experienced consultants who can better make customers successful and don’t be afraid to charge more for them.  (They’re worth it.)
  • Agree to an ARR price before negotiating the services price; refuse to trade one off against the other.
  • Involve your services team in the sale well before the contract is signed so they propose the right prix fixe package (e.g., small, medium, large) or create an appropriately-sized bespoke statement of work.
  • Modify your product so it is not at a competitive disadvantage on required implementation work.

# # #

Notes
[1] With one-year contracts, a failed implementation that takes 6-9 months to fail typically results in churn, whereas with three-year contracts, you will often get another swing at the problem.

[2] These horrific unit economics result in an LTV/CAC of 1.0 and make the company totally uninvestable.  The CAC would be even higher if hard-ass investor added the services losses back into the CAC on the theory they were subsidizing sales.

[3] Product-led growth business models are great, but when companies that are not designed for them try to emulate pieces of the business model, they can get into trouble.  Implementation is an area that quickly goes awry when companies not built for PLG attempt bottom-up, try-and-buy, viral go-to market strategies.

[4] In which case, an obvious solution is to reduce the deployment workload requirements of the product.

[5] Put differently, the sales bone is connected to the services bone, and the services bone is connected to the customer success bone.

Congratulations, You’ve Created a Category. Now What?

(Revised 06/27/20)

I was talking to an old friend the other day who’s marketing chief at a successful infrastructure startup.  “Congratulations,” I said, “I know it was a long slog, but after about a decade of groundwork it looks like things have really kicked in.  I hear your company’s name all the time, I’m told business is doing great, and Gartner literally can’t stop talking about your technology and category.”

“Yes, we’ve successfully created a category,” he said, “But I have one question.  Now what?”

It reminded me, just for a minute, of the ending of The Candidate.

While it’s definitely a high-class problem, it’s certainly a great question and one you don’t hear very often.  These days a lot of very clever people are out dispensing advice on how to create a category — including some wise folks who first dissuade you from doing so — but nobody’s saying much about what to do once you’ve created one.  That’s the topic of this post. category2

Bad Fates That Can Befall Category Creators
Let’s start with the inverse.  Once you’ve created a category, what bad things can happen to it?

  • It can be superannuated.  Technology advances such that it’s not needed any more.  Think:  buggy whips or record cleaners [1].
  • You can lose it to someone else.  Lotus lost spreadsheets to Microsoft.  IBM lost databases to Oracle [2].  Through a more oblique attack, Siebel lost SFA to Salesforce.  Great categories attract new entrants, often big ones.
  • It can be enveloped, either as a feature by a product or as a sub-product by a suite.  Spellcheckers were enveloped as features by word processing products, which were in turn enveloped by office suites.  See the death of WordPerfect [3].

Given that we don’t want any of these things to happen to your category, what should we do about it?  I’ll answer that after a quick aside on my views on categories.

My Principles of Categories
Here are my principles of enterprise software categories:

  • Companies don’t name categories, analysts do.  Companies might influence analysts in naming a new category, but in the end analysts name categories, not vendors [6].
  • Categories sometimes converge, but not always.  Before the SaaS era, enterprise software categories almost always converged because IT was all-powerful and saw its role as entropy minimization [7].  SaaS empowered line of business buyers to end-run IT because they could simply buy an app without much IT support or approval [8].  This is turn led to category proliferation and serious “riches in the niches” where specific, detailed apps like account reconciliation have born multi-billion-dollar companies.
  • Category convergence is about buyers.  Analysts like predicting category convergence so much they get it wrong sometimes.  For example, while the analyst prediction that BI and Planning apps would converge [9] served as the face that launched 1000 ships for vendor consolidation [10], the reality was that BI was purchased by the VP of Analytics and Planning was purchased by the VP of FP&A.  You could put Brio and Hyperion under one roof via acquisition, but real consolidation never happened [11] [12].  Beware analyst-driven shotgun weddings between categories sold to different buyers.  They won’t result in lasting marriages.
  • In category definition, the buyer is inseparable from the category.  Each category is a two-sided coin that defines the buyer on one side and the software category on the other [13].  For example, when categories converge it’s either because the buyer stayed the same and decided to purchase more broadly or the buyer changed and what they wanted to buy changed along with it.  But if there is no buyer, there is no category.

What’s a Category Creator To Do?  Lead!
Having contemplated the bad things that can happen to your category and reviewed some basic principles of categories, there is one primary answer to the question:  lead.

You need to lead in three ways:

  • Grow like a weed.  Now is the time to invest in driving growth.  Nothing attracts competition like fallow land in a new category.  You created a category, you’re presumably the market share leader in the category, and now your job is to make sure you stay that way.  Now is the time to raise lots of VC and spend up to $1.70 to purchase each new dollar of ARR [13A].
  • Market your category leadership.  Tech buyers love to buy from leaders because buying from leaders is safe.  Reinforce your position as the category leader until you’re tired of hearing it.  Then do it again.  Never get bored with your own marketing.
  • Lead the evolution of your category by talking about your vision and your plan to realize it.  This makes you a safe choice because customers know you’re not resting on your laurels.  It also forces your would-be competitors to shoot at a moving target.

The vision for category evolution typically takes one of three forms:

  • Double down.  Make your thing the best thing in the market.  Stay incredibly close to your customers.  Understand and cater to their precise needs.  Your strategy is thus category defense via customer intimacy.  You simply know the buyer better.  Large companies can’t put their best people on everything, so this works when your best people are better than their average ones, they don’t put a massive investment in the space (instead preferring a good-enough solution), and the buyer cares enough to want to buy the best and can continue to do so [14].
  • Build out (i.e., lateral expansion)Move into adjacent categories, ideally sold to your existing buyer, giving yourself economies of scale in go-to-market and your buyer the ability to buy multiple products on one platform [15].  GainSight’s move into product analytics is one example.  Another is Salesforce’s systematic move across buyers, from VP of Sales to VP of Service to VP of Marketing.  This strategy works when you can afford to build or acquire into the adjacent category and, if the category involves a different buyer, that you can afford to invest in the major transition from being a single-buyer to a multi-buyer firm [16].
  • Build up (i.e., vertical expansion) [17]. Build up from your platform to create one or more applications atop it.  An ancient example would be Oracle expanding from databases into applications [18] which was first attempted via in-house development.  Anaplan is a contemporary example.  They first launched a multidimensional planning platform, had trouble selling the raw engine in finance (a more saturated market with more mature competition), shifted to build sales planning applications atop their platform, and successfully used sales planning as their beachhead market.  Once that vertical (i.e., upward) move from platform to application was successful, they then bridged (now laterally) into finance and later into supply chain applications.

What If You Can’t Afford to Lead?
But say you can’t afford any of those strategies.  Suppose you’re not a particularly well-funded company and your market is being attacked on all sides, by startups and megavendors alike.  What if staving off those attacks is not a viable strategy.  Then what?

If you’re at risk losing leadership in your category, then your strategy needs to be segment.  Pick a segment of the market you created and lead it.  That segment could be on several dimensions.

  • Size, by focusing on SMB, mid-market, or enterprise customers only — this works when requirements (or business model) vary significantly with size.
  • Vertical, by focusing on one or two vertical industries — ideally those with idiosyncratic requirements that can serve as entry barriers to horizontal players.
  • Use-case, by focusing on a specific use-case of a platform that supports multiple use-cases.  For example, what if Ingres, instead of focusing on appdev tools after placing 4th round I of the RDBMS market, instead had focused on data warehousing, a distinct use-case and one to which the technology was well-suited?

Conclusion
If you’re reading this because you’ve created a category, congratulations.  You’ve done an incredibly difficult thing.  Hopefully, this post helps you think about your most important question going forward:  now what?

# #  #

Notes

[1] I struggle to find software examples of this because the far more common fate is envelopment, typically into a feature — e.g., spellchecker.  I suspect it happens more in hardware as the underlying components get smarter, they eliminate the need for higher-level controllers and caches.

[2] Despite both inventing the relational database and being the leader in the prior-generation database market with IMS.

[3] The precise cause of death is still debated and a final lawsuit concluded less than a decade ago.

[4] Software industry evolution led to the SaaS model, which then put huge importance on renewals which in turn led to the creation of the VP of Customer Success role which created both the demand for and buyer of Customer Success software.

[5] And either way, a great company.  (I know both the founder and the CEO, so see my disclaimer.  I can say I’ve also been a customer and a happy one.)

[6] I credit Arnold Silverman with pointing this out to me so clearly.

[7] To reduce the degree of disorder in a company’s software stack, IT had a strong tendency to prefer one-stop-shop value propositions over best-of-breed.  Ergo, vendors incented by economies of scale in go-to-market, were naturally aligned with buyers who wanted to buy more from fewer vendors.  Both forces pushed towards developing suites, either in-house or through acquisition.

[8] As I did in the early 2000s when I was CMO of a $1B company and the CIO said I needed to wait 4 years for lead management in Europe during our CRM deployment.  “That’s funny,” I thought, “we have leads today and if I wait 4 years for lead management, I can assure you of only two things:  I won’t be CMO anymore and the CIO will be the only person coming to my going-away party.”  That’s when I bought Salesforce.

[9] That was the initial use of the category name enterprise performance management (EPM), which later evolved before eventually, and only of late, being retired.  A key point here is that while these categories organ-rejected each other, that took place literally over the course of decades.  Thus, paradoxically, you likely would have been “dead right” as a BI vendor if you rejected the inclusion of financial planning in 2003 .

[10] Cognos acquiring Adaytum, Business Objects acquiring SRC and Cartesys, and Hyperion acquiring Brio, among others.

[11] Meaning you could ask someone who worked in the organization “which side” they worked on, and they would answer without hesitation.  You can’t sell financial planning systems without significant domain expertise that the BI side lacked, and that was more about DNA than training.  (For example, most EPM sales consultants had years of experience working in corporate finance departments before changing careers.)  It was more conglomeration than consolidation.

[12] Amazingly, this pattern repeated itself within EPM in the past decade.  EPM  was redefined as the convergence of financial planning with financial consolidation, both within the finance department, but again sold to different buyers.  Planning is sold to the VP of FP&A, Consolidation to the Corporate Controller.  While both report to the CFO, they are two different roles, typically staffed with two very different people.  Again, the shotgun wedding ended in divorce.

[13] Each category has one primary buyer.  A given buyer may buy in several different categories.  As a marketer, the former statement is 10x more important than the latter.

[13A] See my post on the CAC ratio.  Data source, the KeyBanc 2019 SaaS survey, shows median of $1.14 with mid 50-percentile range of $0.77 to $1.71.

[14] The tension here is between letting, e.g., the VP FP&A purchase their own best-of-breed Planning product versus a good-enough Planning module subsumed into a broader ERP suite decided upon by the CFO.  This is a real example because Planning exists on both sides today; there remain several successful SaaS planning vendors selling best-of-breed outside the context of a financial suite while most ERP vendors bundle good-enough Planning into their suite.

[15] When accomplished via M&A, the single-platform benefits are typically limited to pre-defined integration but can hopefully over time — sometimes a long time (think Oracle Fusion) — become realized.

[16] Typically this means creating product-line general managers along with specialized overlay sales and sales consultants, product management, product marketing, and consulting teams.  It also means the more difficult task of going to market with products at differing levels of maturity, something very hard to master in my experience.  Finally, in apps at least, the more you are multi-buyer, the more IT needs to get involved, and the firm must master not only the art of the sale to the various business buyers, but to IT as well.  Salesforce has done this masterfully.

[17] Vertical in the sense of up, i.e., atop your platform; not vertical in the sense of focusing on vertical markets.

[18] Which, for ancient software historians, was the failed strategy that Oracle gave a mighty try before giving up and acquiring PeopleSoft in 2005, the first in a long series of applications acquisitions.

On Recent Events

Capture

Please join me in donating to the Equal Justice Initiative or other charitable organization of your choosing.