Communication and Collaboration = Customer Success

In an earlier post, I wrote about the customer success doughnut hole. It is the moment on the customer journey when everything is in flux — the vendor thinks implementation is complete and is passing the ball from the implementation team to the support teams, and the customer is transitioning from implementation to operations. It is a pivotal moment that will set the course of the relationship, but it is often the moment when teams drop the ball.

To close the customer success ‘doughnut hole,’ start with an effective handoff from the Sales team to the Services organization. There has to be a clear understanding of what was sold and what was bought. The project kickoff with the customer needs to include pre- and post-sale team members, and it is a moment to make it crystal clear what will occur during implementation. This a time when the customer is excited about the purchase and eager to get going, so the objective is not to throw cold water on their enthusiasm, but it is important to have a clear discussion about what will happen during implementation and where there may be pitfalls along the way.

I am an advocate of insisting on the involvement of the senior buyer in the early phases and establishing a routine reporting mechanism to assess project progress and satisfaction every week. Most importantly, the vendor must establish an ongoing channel of communication with the senior buyer to share weekly assessments and to continually inform and alert the senior buyer to successes and challenges. Too often, the senior buyer steps away from implementation and their only source of news is the customer’s implementation team. The vendor team and the product are always positioned as the reason for any failure, and the relationship with the customer can go south quickly if there is not a channel for discussion and resolution with the original senior buyer. Maintaining a routine channel of communication with all of the stakeholders for good and bad news goes a long way to avoiding disaster..

During the implementation phase, it is also critical to foster solid lines of communication among the vendor’s Services teams. Collaboration across the Implementation, Success, and Support teams to align everyones understanding of the customer challenges and decisions is imperative. Post implementation teams may feel that their involvement need not start until later in the project, but in fact, the more they are aware and involved from the start and throughout implementation, the more prepared they are to smooth the customer’s path to operational success.

Collaboration requires brutal honesty and fact-based candor.  Each team has to check their egos and defensive nature at the door.  You need to build a mutual understanding that the goal is success, not assignment of blame. For each customer implementation, establish a routine process of after-action assessment to highlight where each journey went well, or went awry and could have been improved.  The services and sales teams needs to agree on process changes that will avoid bad situations from occurring in the future.  A valuable tool is a journey map to identify all of the potential forks in the road that will either lead to success or failure.  A journey map can help to build a roadmap to success and an early warning system for future issues.  As a customer transitions from sales to implementation, carefully follow the roadmap and be vigilant to identify and address deviations at every step of the journey - it will pay dividends.  Remember, the customer is implementing your system for the first and possibly only time in their career, while your team does it every day. You are the experts and your job is to guide them to success and away from making decisions that lead to failure. Your roadmap can predict where each fork in the road leads, and you know how to get to success.

If You Can’t Make It – Don’t Try To Fake It

Many software companies pursue acquisitions to advance their products.  All too often, the solution to integrating acquired products is to do a little UI work (lipstick on the pig), and some single-sign-on magic, and call it good to go.  In other words, fake it instead of actually creating the product that was imagined.  Nobody wants to acknowledge that sooner or later the tech from the company just acquired will need to be completely rebuilt in order to make the overall platform consistent and usable.  The leadership, the board, and the investors just made a buy versus build decision, and they landed on ‘buy,’ but now you have to build after all.  Not an easy discussion to have, but all too often, it is the right one.

A huge component of creating a product is defining the capability set and battle testing the product/market fit in the competitive market with real customers.  The product you just bought has presumably already covered this ground.  It is a comprehensive ‘spec’ for what you need, but often it was not built to be a natural fit in your existing platform.  The right, hard discussion is to decide if slapping the products together with some lipstick will deliver the best competitive solution, or will it open the door to a competitor that builds the right product from the start.

This product conversation should be a part of the diligence process.  It needs to factor into the buy versus build equation, and all of the internal constituents need to have an honest conversation about the potential timing and need to rebuild the acquired tech.  The team has to understand the long-term strategy and the path to success.  Too often, the business metrics and financials of the target drive the acquisition discussion, and the tech evaluation is done in a silo that only considers the quality of the tech being acquired, and not the reality of what it will take to create the ideal combined product.  In tech company after tech company, if you look back a few years after they acquired a product, you will find that they ultimately rebuilt the product.  Rarely was that the plan going in, but maybe it should have been.

The problem is that too much energy and angst goes into trying to make it work before some bold soul declares it is time to rebuild.  The market and reputational damage of having an inferior product in the market for too long is done, and now future success hinges on successfully building Version 2. 

This is not an argument to avoid M&A.  A good deal can bring clients and expertise and market penetration and a host of other advantages.  Even the existing acquired product may be highly valuable as a bridge to gain market share while you create V2.0 as long as that is the understanding and strategy at the onset.  However, if nobody is willing to talk about the elephant in the room that the tech may need to be rebuilt, then there is a pretty good chance the shiny new acquisition is headed for product trouble in the future. It is important to have the discussion and set the strategy up front, and factor it into the buy versus build decision.

Keep Your Customer Out Of The Doughnut Hole

One of my favorite doughnut shop proverbs is “as you go through life brother, whatever be your goal, keep your eye on the doughnut and not on the hole.” However for enterprise SaaS tech companies, I beg to differ (a little).

For complex SaaS offerings, one of the root causes of customer angst is often what I refer to as the ‘doughnut hole’ in the customer journey. This is the step on the post-sale path where the vendor wants to declare that the system is implemented, but the customer may not have quite launched all of the processes and features they imagined when they made their purchase decision. It is also the time when the customer team may not be quite stable enough to be self-sufficient. From the vendor’s perspective, this point in the journey is often when the relationship is handed off from the implementation team to the customer success team and the customer support team. On the customer side, they frequently have team members coming and going as the implementation winds down. All of the new people show up with new requirements and lots of questions about past decisions. Unfortunately, the new people are joining right when all of the vendor resources are also in flux, and the launch can fall into the doughnut hole.

The transition from implementation to operation is like a child learning to ride a bike.  Implementation is when the bike has training wheels and it is hard to fall off. Once the implementation phase is “over,” it is like taking the training wheels off and letting go to send the customer peddling on their own. Some children instantly get it and take off, while others fall and want to put back the training wheels, or quit and never ride again. Similarly, some customers “get it” and are immediately self-sufficient, while others panic and become dissatisfied.  The transition from implementation to operation is a very shaky and stressful time in the customer journey, and it is certainly not a time to let the customers fall into the doughnut hole.

A contributing factor to the doughnut hole is similar to a concept from a seminal tech business book by Geoff Moore called “Crossing the Chasm.”  Moore suggests that early buyers are often visionaries with a grand vision of what they want, and no matter how clearly a vendor describes what they actually have to offer, the visionary imagines that the vendor has exactly what they want. Moore says it can be nearly impossible to make a visionary happy. The chasm is the gap between these visionary early buyers and the bigger mainstream market. You need the visionaries to stick with you and be references so you can grow your offering and cross the chasm to sell to mainstream customers, but first you need to find a way to make them happy. If you don't cross the chasm, you are stuck on the wrong side with unhappy visionary customers.

From a little less macro view, think of the visionary as the senior buyer at your customer, and think of the people who actually have to implement and deploy the system as the mainstream. The buyer had a vision and made a lot of assumptions about the system the vendor was selling.  However, decisions were made all along the implementation journey that may not quite align with the initial vision. Each deviation may have seemed small at the time, but each step off of the visionary’s path is like a grain of sand in the machinery.  Eventually, the grit adds up and the machine grinds to a halt with a very unhappy customer. Commitments and promises the visionary made to upper management are missed, and the customer is left trying to figure out what to do - get back on the bike or run away.

This is the worst possible time for a SaaS vendor to miss commitments or promises, or to be slow to respond when the customer is in a panic. Unfortunately, this moment in too many journeys aligns with the handoff doughnut hole in our support model.  This moment is when the trajectory of the relationship with the customer hangs in the balance - will they pull through and become delighted, or will they be soured and look for an exit at the earliest opportunity? Being truly customer-centric means anticipating the issues and adjusting processes to avoid the problems. ‘Keep your eye on the hole,’ and keep the customer on track for success.

What’s Wrong With Procurement?

Despite all of my years in the enterprise technology industry, every time there is a large enterprise purchaser, I am surprised and reminded of just how difficult it is to get a deal across the finish line with a big company.  Big companies develop a kind of procurement arrogance that hobbles their ability to move forward efficiently.  Internal politics and fiefdoms, and legal and IT mandates create numerous hurdles in the path of progress.  The businesspeople know what they want, but the arrogance of procurement, legal, and IT leads those groups to assume they know better, and they are the self-styled protectors of the company intent on slowing down purchases and insisting on their pet requirements, regardless of whether they make sense in the context of the business.

Our prospects are operational businesspeople, and they do not routinely buy technology products.  As a result, they don’t really know how to buy technology, or more importantly, how their organization buys technology.  That naivety leads us to face two sales cycles instead of just one.  The first cycle is to convince the business buyer that we have the platform they want.  The second cycle is to help the business buyer sell the purchase internally, and it requires us to navigate the gauntlet of all the procurement influencers and decision makers to finally get a deal signed.  The business buyer, and frankly many salespeople, are often surprised by some of the crazy demands, hurdles, and minutiae that pop up when IT, legal, and procurement get a hold of a deal.

Fortunately, an experienced enterprise sales team knows what to expect. They are adept at educating business buyers about the process early in the deal.  They tell them what is likely to happen and encourage them to get ahead of it:  engage IT early, start working with legal early, line up signers and inform everyone that the transaction is coming.  Despite our best coaching, however, some corporate bureaucracies are just insurmountable and simply must run their course.  These procurement machines become an unstoppable force - they have their “process” and nothing is going to change it. 

The good news for a SaaS business is that while we measure bookings, meaning signatures on contracts, we really focus on adding to our Annual Recurring Revenue (ARR), and we report actual revenue according to generally accepted accounting principles (GAAP), which follows a different course than bookings.  We count the full value of the deal as a booking, but we typically recognize and report license revenue over the duration of the deal.  That means a week or two delay in signing has a big impact on whether the booking is in one quarter or the next, but from a reported revenue and run-rate ARR perspective, it doesn’t have that much of an impact on a go-forward basis.  This is not to say we are indifferent to a booking being delayed from one quarter to another.  In fact, we typically manage ourselves based on quarterly bookings, and we hold our sales team (and everyone else) accountable for the bookings targets and forecasts in each quarter.  What it does mean, however, is that the most important thing is to win the deal, collect the cash, and add the customer, because that is what drives our business and revenue growth.  SaaS businesses can tolerate a little variability in when a buyer signs as long as they do in fact sign. The sales skill is to learn how to forecast accurately when you don’t know all of the procurement hurdles that have to be cleared. Too many sales people forget about the second sales cycle and stumble trying to forecast when a deal will actually close. Our sales teams need to discover the hurdles early, educate the business buyer as to what is ahead of them, and together with the buyer, manage the second-cycle as early as possible in the transaction.

Time To Lift Up The Back Foot

Often when a company decides to launch a new version of a platform, they work really hard to preserve the user interface to keep everything familiar for existing customers.  That sounds like a good goal, but it can be fraught with problems.  A clean Version 2 will have the freedom to innovate across all areas of the platform, including user interface.  Often, the interface is actually the problem that is limiting the further success of Version 1.  As products mature, they get feature after feature added to their UI, and eventually it is just too bogged down with choices and screens and options to be usable.

I experienced an example of this phenomena first-hand in the form of a new BMW versus a new Tesla.  BMW has a long history, and its interface has grown over the years.  They have strived to maintain an interface that is familiar for repeat buyers.  It was initially a clean interface, but over time it has been bogged down with baggage.  The progression started with extra buttons on the dashboard.  In time, they added similar buttons to the steering wheel.  Then they added a joystick-like device on the console to manage all the features on a video screen.  As more and more features were added, the menus on the video screen grew deeper and deeper, and it became less and less obvious where to look for the controls.  More recently, they improved the video screen to be a touch screen, and they enabled all the same features from the joystick on the touch screen.  Along the way, they added voice commands for the same features, but I don’t know anyone that is fluent enough speaking BMW to actually find all of the features.  Most recently, they added Apple Carplay with Siri, but the two voice systems are overlapping, and not compatible.  The result is a car with three or four or five different ways to do the same things.  What a jumble of interfaces!  By contrast, the Tesla has almost no buttons, and just a touch screen with limited depth of menus and a simple integrated set of voice commands (although I’m not sure anyone truly speaks the full Tesla vocabulary either).

One of my favorite sayings is “if you want to move forward, you have to pick up your back foot.”  BMW is an example of an interface where they did not pick up their back foot and drop the old ways in favor of the new.  They stayed rooted in the old and just layered on one after another duplicate controls.  The result is a complex interface that is anything but ‘ultimate.’

We have to maintain a willingness to break with the past as we innovate, and not get trapped in the BMW cycle of layering on top of layering.  As we invent new and creative ways to accomplish tasks, we have to be willing to pick up our back foot and let go of old ways.  We have to embrace the new and remove the old.  To keep it simple, we have to eliminate the complexity of too many options to achieve the same result and eliminate the tech-debt that is preventing us from building products to be what they are supposed to be.

Is It Time To Re-Platform?

When is it time to consider rebuilding a product from the ground up versus just continuing to add features?  The software landscape is littered with ‘version 2’ projects that were over-engineered and failed to see light of day.  However, on the other hand, as a product matures it tends to get featured to death and become unusable or at least unfriendly.  Like the management “Peter Principle” that describes how employees rise to their level of incompetence, when a product matures with too many add-on features and capabilities, it reaches the point where it it starts to be trapped by all the baggage.

It is a huge decision to replace a mature product with a new Version 2.  The implications go far beyond just the engineering project, and the decision has to be a cross-functional strategic one.  Having said that, companies need to be bold when the time comes to re-platform and rebuild a product.  Everyone should embark on the project with open eyes and a clear understanding of the objectives, the potential pitfalls, and the likely progression of the project.  Replacing a mature product with a new version will pass through a trough of capability, where the new product is less feature rich and less capable than the old mature product, and therefore less competitive in the marketplace.  Most companies are ‘forced’ to continue to incrementally invest in the old product to appease existing customers and remain competitive while the new product is coming up the curve.  Investment in the new product is high, and duplicative to the investment to sustain the old, and unless there is a clear plan, it can seem like the new product is constantly chasing the old but never quite surpassing it.  So, does it ever make sense to start over?

The answer is yes.  If you are considering the old product to be a problem, you can be sure your customers realized it long before you did.  You probably see it in a declining rate of expansion, or increased churn, or lower win rates, or longer sales cycles.  Maybe it is evident in less efficient engineering, or technical roadblocks to adding new capabilities.  Maybe it surfaces in increased quality problems and slower break/fix cycles due to the complexity of the code.  Maybe it only manifests in a higher volume of support calls and the need for ever increasing product training.  If you look for it, you will see that the time for re-platforming is upon you.  If you don’t see it, someone else will, and you will probably face a competitive threat challenging your market position.

We see vibrant innovation in start-up competitors that don’t have an installed base or an old product holding them back.  They are learning from your mature product and innovating a new and better approach to replace you.  If it isn’t a start-up, then one of your mature competitors is going to see opportunity and swoop in to take advantage of it.  The automobile industry and specifically the electric car revolution is a good example.  How did Tesla become one of the leading automobile manufacturers in what seemed like overnight?  To the casual observer, a Tesla may look like just another car.  It has the same basic features and capabilities as all the other cars.  However, under the covers, Tesla was designed from the ground up to be a new, ‘version 2’ of an automobile.  It was built to be new and better, and to replace the status quo.  By contrast, most traditional cars were designed and built in a different era with different concepts, and they have a lot of history and features from times gone by.  They have an installed base and entrenched engineering and production.  In software terms, they have a lot of tech-debt, and they were resting on their laurels of past success.   With its clean modern architecture and design, Tesla created a platform for innovation that can be enhanced and improved at a pace well beyond what traditional manufacturers could achieve.

When a product is built from a clean slate, it eliminates the tech-debt.  With no tech-debt, all of the investment in engineering is directed toward innovation, and the product can move forward faster than competitors that are struggling with baggage.  When it is done well, ‘Version 2’ delivers a springboard to the future, and it enables you to set the pace for the market.

The challenge is that troublesome trough of capability.  A common term used to describe the design point for a first commercial release is ‘minimum viable product’ (MVP).  There are a few problems with this concept.  First, it has to be defined in the context of a market segment with a clear value proposition.  If Version 2 is slated to enter the exact same market as Version 1, then to be viable it will need to compete at least as effectively upon launch.  To do so, it will have to be feature rich, so ‘minimum’ is really not aligned with the market if the goal is to be ‘viable.’  One approach is to design Version 2 for a different market or sub-segment where limited features can still deliver a value proposition that is viable.  This could be a down-market offering.  Maybe the mature product addresses the needs of large global organizations with multiple languages and currencies, while the early release of Version 2 could target smaller companies that don’t have the same global requirements.  Perhaps the points of enterprise integration or flexibility of configuration can be limited on initial release if the target buyer is less demanding.  The key is to select a market segment where Version 2 in its early form can in fact be viable*. 

Once launched, the market can lead the growth of the product.  The ultimate goal may be to make Version 2 so attractive that traditional customers of Version 1 will find it compelling to adopt even if they have to give up some of their existing V1 features.  Alternatively, Version 2 may open the door to a new and potentially larger market than Version 1 ever could address, and it could facilitate a corporate pivot to a steeper success curve.  The most challenging design point for Version 2 is to attempt to launch with greater capabilities than Version 1.  It has been done, but this is the scenario that typically leads to over-engineering Version 2, and greatly increases the risk of never crossing the finish line.

* Note: I have a real problem with the term ‘minimum viable product - MVP.’ It sounds like the commercial that talked about aspiring to be ‘mediocre.’ Products should aspire to be ‘successful’ not just viable. I insist on aiming for the ‘minimum successful product -MSP’, which has a higher goal than simply being viable.

Innovation Or Invention

We can always dream up more product bells and whistles, but the important ones truly advance the flexibility of a product to meet real world needs.  When allocating resources, we have to balance the desire to boldly go where no product has gone before, with the mundane need to fix ‘broken windows’ and put a fresh coat of paint on tired older elements of the foundation.  I am an advocate of periodically requiring the product/engineering team to perform an entire customer implementation from start to finish.  Three benefits will come of it.  The first is it will highlight for the product/engineering team all the places where “people putty” is required to fill a gap in deploying the product.  The benefit of closing the gaps will be a significant increase in implementation efficiency, shorter launch windows, and faster time to value for customers.  Secondly, it will build a stronger understanding of the customers’ journey and needs, and hopefully create more empathy.  Lastly, it will serve as an engine for innovation.

How many times have you had the experience of doing something and when you finished you suddenly had a flash of an idea about how you could have done it better or differently.  To innovate you need to understand the status quo so that you know what you are innovating and why.  There is a difference between innovation and invention.  Invention is creating something new and unique.  According to the U.S. Patent office “an invention can only be considered patent-eligible if it is new, non-obvious, and useful.”  This is in the camp of boldly going where no product has gone before, and for a portion of our product / engineering journey, we need to be on the path to creating capabilities that meet this definition.  However, we also need to invest in the more mundane innovations that simply ensure we have the best product on the market.