Category Archives: Organizational Behavior

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.

Handling Conflict with the “Disagree and Commit” and “New Information” Principles

In every executive team there are going to be times when people don’t agree on certain important strategic or operational decisions.  Some examples:

  • Should we split SDRs inbound vs outbound?
  • Should we map SCs to reps or pool them?
  • How should we split upsell vs new business focus in mid-market reps?
  • Should CSMs get paid on upsell or only renewals?
  • Should we put the new buzzword (e.g., AI, ML, social) into the release plan?
  • Should we change the company logo ?

The purpose of this post is to provide a framework to get decisions made and executed, without certain decisions becoming a form of weekly nagging at the e-staff meeting, a topic of discussion at every board meeting, or worst of all, a standing joke among the team.

The Disagree-and-Commit Principle

The first time I heard disagree-and-commit I thought it was corporate, doublespeak garbage.  What the heck did it mean?  I’m supposed to go to a meeting, say that I believe we should go left, get overrun by the group who eventually decides to go right, and then I’m supposed to say “sure, everybody, just kidding, let’s go right.”  How disingenuous — everybody knows I wanted to go left.  How controlling of the establishment.  How manipulative.  This is thought control!

“You may disagree, but you must conform … (wait, was that our outside voice) …  you must commit.”

(Recall my first professional job was as at a company we referred to as The People’s Republic of Ingres.)

Let’s just say I missed the point.  My older, wiser self now thinks it’s a great, but often misunderstood, rule.  (And that’s not just because now I am the establishment.)

Here’s a nice definition of disagree-and-commit from The Amazon Way via this blog post.

Leaders are obligated to respectfully challenge decisions when they disagree, even when doing so is uncomfortable or exhausting. Leaders have conviction and are tenacious. They do not compromise for the sake of social cohesion. Once a decision is determined, they commit wholly.

I always missed two things:

  • I took commit to mean change your mind (or “get your mind right” in the Cool Hand Luke sense). It actually means committing to execute the decision wholly, i.e., as if it were the one you had voted for.  You can’t undermine or sabotage the decision just to prove yourself right.  This is a great rule.  People aren’t always going to agree, but if you want to work at the company, you must execute our decisions wholeheartedly once they are made.  There is no other option.
  • The obligation to disagree.  I love this part because some people lack the courage to speak up in the meeting, and then want to passive-aggressively work against the decision and/or attempt a pocket veto by going to the person who was in charge of the meeting and saying, “well, I didn’t feel comfortable saying this in the meeting, but, ….” Such behavior creates a potential paradox for the executive in charge — particularly if she agrees with the pocket veto argument.  Does she overrule the group decision based on the new argument (and reward dysfunctional behavior) or does she stick with a decision she no longer prefers in order to avoid incenting pocket vetoes.  In my opinion, in 95% of the cases you want say, “Sorry Joe, I wish you’d said something in the meeting because that’s an interesting point, but the decision stands.” Worst case call another meeting.  Never, ever just overrule the decision.

Explicitly embracing the disagree-and-commit principle is one great way to end endless, nagging disagreements:  we met to discuss the issue, we came to a conclusion, I know you didn’t agree with it, but you need to commit to execute it wholeheartedly.  (Else we’re going to have a conversation about insubordination.)  We want a rational culture.  We debate ideas.  But we need to make and execute decisions, and you’re not going to agree with every one.

The New Information Principle

But what if the issue keeps coming up anyway?  Perhaps via periodic serious requests to reconsider the decision.  Perhaps through a series of objections coming from someone not responsible for executing the decision (so “commit” is less relevant) — but who just can’t stand the idea.  Or maybe someone has a personal ax to grind (e.g., I know we’ve talked about this before, but can we please relocate the office) and who just won’t take no for an answer.

The problem is if you always shut down these requests, then you risk creating a big problem with corporate agility.  On one hand you want to shut down the constant nagging about adding data mining capabilities from the data mining zealot. On the other hand, you don’t want to make the subject taboo because maybe your top competitor launched a new data-mining addition last month and it’s hurting you in sales.

So, the principle is simple:  if you want to re-open discussion on something we’ve already decided, do you have any new information that wasn’t available at the time we made the decision?

If the answer is no, we’re not re-opening it here, and we can do at either next quarter’s ops review or next year’s strategy offsite (pending prioritization against other topics).

If the answer is yes, find out what the new information is, and then decide if it warrants an immediate or deferred re-examination of the decision.

With this principle you can keep a firm hand against those who won’t give up on an issue while still being open to new information that might cause the need for a  valid re-examination of it.