Lower Customer Effort = Higher Loyalty

A couple of years ago, I watched a Gartner webinar titled “How To Improve Customer Experience By Focusing On The Fundamentals.”  The basic guidance was to “Stop thinking about your customers and start thinking like your customers. Focus on the fundamentals.”  A key observations was that you can’t think ‘like’ your customers if you don’t know who they are. The recommendation was to do a detailed analysis of customer personas to understand the wants, needs, goals and mindset of each persona in order to design processes and products to be most valuable. It was a good reminder to get outside of our echo chamber and actually get to know our customers.

We need to understand what stressors make things worse for a customer—more effort, more pain, more questions, longer wait times, more errors. Then we can map out the things we can do to reduce or eliminate the stressors. If we really look through the eyes of our customers, we can change the trajectory of the customer journey.

It turns out that the less effort a customer has to invest, the more loyal they become. They spend more, stay longer, and speak more highly of solutions that require less effort.  Gartner suggested that the score we should consider is the Customer Effort Score (CES). Similar to the NPS question scored from 0-10 :

To what extent do you agree with the following statement: “The company made it easy for me to [achieve my goal].” 

We need to look at all aspects of our product, user experience, processes and procedures to see what we can do to reduce customer effort.

A lot of companies place a major emphasis on designing for customer self-service, but when we speak about self-service, we have to also consider effort. Is it less effort to ask the vendor to do something or to do it themself?  Customers don’t want to be required to ask their vendor to do the work. It frustrates them if they can’t do things themself.  Often, the vendor solution is to expose more knobs and levers and capabilities to customers so they can control everything, but how does that relate to increased complexity and effort?  If the vendor is doing the work for the customer, they can ‘hide’ the complexity from the customer.  The customer’s level of effort is to make the request, and behind the scenes, the vendor’s level of effort can be huge - it is just hidden.  However, if we move to a self-service model where we simply add more controls and transfer the effort to the customer, then we are likely failing on the Customer Effort Score (CES), and we will not enjoy the loyalty that comes with low effort.

One company I know is totally focused on self-service, but they take a unique approach to monitoring their success in maintaining a high CES.  If a customer has to contact the vendor for anything, they consider the contact to be the equivalent of a bug.  It goes into their tracking system and becomes a ticket to be addressed.  They aggressively work to eliminate the root cause of the contact so that no customer will ever have to face the issue again.  Sometimes the fix is in the documentation or the help system, or it can be in the product interface, or even the corporate website and sales and marketing materials.

Another way some vendors focus on self-service is through education and training. They assume that if they teach clients how to do things, then the client can be self-sufficient.  Once again, this concept has to be tested against the measure of effort.  If a task is hard and requires a lot of effort, simply training the user better will not result in a higher CES and will not produce the desired loyalty results.  Even taking a training course requires effort.  It could be said that if you have to train me, then it is too complicated (i.e. too much effort).  

The precursor goal to self-service is to go back to basic ease-of-use and meaningful automation. Customers should be able to be self-sufficient, but we need to do so in a manner that is predicated on ease of use and reduced effort. The benchmark should be to ask ourselves if it is less effort for a customer to ask us to do something or for them to do it themselves?  We don’t want the answer to be that they need to ask us to do the work for them.  However, if that is the answer, then we need to address the fundamentals before we try to transfer the effort to the customer.  Focus on minimizing effort, and loyalty will follow.

Get to the Point!

My good friend Jim Farrell suggested I write about the importance of brevity and clarity when creating a presentation, and answering the question “So What?” What is the point you are trying to drive home and for what purpose. Why is it important? If the audience does not immediately understand your point, then fix it or get rid of it. If you present a fact or a statement, you need to make sure the presentation answers the question “so what?”  The audience requires context, but they also require a filter to ensure the point is worth making, and is relevant or important?

Too often, presentations are loaded with data or features.  It either indicates that the presenter is not sure what is important, so they throw it all against the wall and hope that something sticks, or they think that if they present all of the minutia and data they will appear to have a deep command of their subject.  In either case, they leave it up to the audience to figure out what is important, and that rarely goes well.  We call this “show up and throw up.”

Answering the ‘so what’ question is particularly important when creating a board presentation because board members are not in the day-to-day operations, and need management to filter out the minutia and guide the board to focus on what matters.  The same is true in a sales presentation. The prospect needs a clear and concise understanding of your unique value proposition and competitive differentiation.  Whatever you present needs to answer the ‘so what’ question for the audience.

As I thought about this topic, it reminded me of what I have called the democratization of leadership and the importance of applying the same ‘so what’ filter to internal presentations.  As an organization grows, there are increasing layers of management and increasing specialization of roles.  The further we get from the source of the information, the more it loses context and becomes distorted and shaded by opinion.  If we reserve decision making to the top of the hierarchy, we are basing decisions on watered down information. Instead of flowing all of the data to the top of the organization and waiting for an answer or decision to come down from the mountain, it becomes increasingly important to move decision making closer to information and empower more people to take the lead and responsibility for decisions.  

When we move authority to make decisions closer to the source of the information, we can increase efficiency and leverage a deeper understanding of the data, but, as it is said, ‘with great power comes great responsibility.’  Leaders have to develop confidence and trust before they are willing to let go of decision making authority. To get there, we need concise communication and presentations that answer the ‘so what’ questions, and make senior leaders believe in the presenter’s grasp of the information.

The three underlying questions a presenter has to answer are: “What do you think?” “Why do you think that?” and “What would you like to do about it?” We want individuals to demonstrate that they have an understanding of the situation and an opinion, so the first question is “what do you think?”  It requires thinking, and observation, and an understanding of the goals and objectives so that we know your opinion is informed.  

The second question is “why do you think that?” The answer to this question will elicit the inputs and reasoning behind the answer to the first question. It should illuminate the presenter’s logic and understanding of the situation, and it can open the door to dialog and sharing differing perspectives.

Lastly, question 3 asks “what would you like to do about it?” This is really the meat of the ‘so what’ test. If there is no action or decision to be taken, then what was the reason for presenting the information in the first place?  Even if it is just a status update, there must be a reason for presenting it and a next step to be taken, otherwise ‘so what?'  

Answering the ‘so what’ question is a powerful communication tool.  At all levels and in all situations, we need to ask the question so that we test the relevance and importance of what we are communicating.  Nobody wants to sit through a lengthy presentation or detailed demo only to get to the end and be left with a feeling of ‘so what?’  The presenter owes it to the listener to filter the presentation content and guide the discussion by answering the question and eliminating superfluous content.

Customer Engagement = Customer Retention

In a recurring revenue business, one of the most important metrics is Net Revenue Retention (NRR) — a measure of preserving and growing revenue from the customer base.  Every company expects some level of churn (customers that do not renew their relationship), and some amount of down-sell (customers that reduce the amount of money they spend).  These two measures are both negative.  If we start with 100% of our revenue up for renewal, churn and down-sell are reductions in revenue.

On the positive side is upsell, when a customer spends more this year than last year.  There are a number of sources of upsell, including price increases, increased usage, add-on capabilities or modules, and new projects.  These sources and others increase the revenue from the customer base. Net Retention is the net of the negatives and the positives.  The minimum goal is to have upsell offset churn and down-sell so that the revenue we start with is at least preserved in the next year. That would be 100% Net Retention.  However, a good outcome is to have Net Retention above 100%, so that the base of revenue coming from existing customers grows year over year and contributes to overall growth.  A really good metric is Net Retention of 115% or more.  

If Net Retention is less than 100%, then we have a leaky bucket - revenue is dripping out of the bucket. We need to sell new customers just to maintain our revenue level and fill the bucket back up. To grow total revenue we need to preserve what we have (NRR) and add new revenue on top, but if a portion of new sales is just refilling the bucket, then even if we succeed in selling new, our growth is constrained by the rate at which revenue is leaking out of the bucket.

We could just double our efforts and sell more new to outrun the leak. It is certainly a good idea to sell more, but to maximize growth we really need to plug the leak.  I have read estimates that it costs five times as much to sell a new account as it costs to preserve an existing account. In other words, it is more cost efficient to plug the leak than it is to try to outrun it.

Companies often see churn and down-sell as inevitable and just accept it, but that is simply not good enough.  The first step to improving the situation is to do a deep dive into the reasons for churn and down-sell.  We often hear vague generalities and ‘guesses’ about why clients are leaving or scaling back. But, fixing the problem will take real analysis.

Death and marriage (bankruptcy and mergers) account for some of the leak, as will changes in management or strategy, but we need to go deeper.  We have to recognize that churn and down-sell are not just the purview of the customer success team. It is a companywide challenge. The product team needs to see how the product and their decisions are impacting churn. The sales team needs to recognize where they may have closed a deal for the wrong reasons. The implementation team has to acknowledge how they contributed to the problem, and even the marketing team needs to evaluate if the leads were actually a good fit for the solution being offered.

Once we have a clear, multi-faceted understanding of the causes, we can collaborate on strategies to turn things around. I believe that one of the biggest drivers is lack of customer engagement. We focus on selling and implementing, but too often we do not pay enough attention to ongoing engagement. If we follow the trends for some simple metrics, we can usually see if engagement is growing or shrinking, and engagement is the leading indicator of churn and down-sell:

  • Is the number of users growing?

  • Is the frequency of use growing?

  • Is the time spent on the site, or the number of features being used growing?

  • What is the frequency and tenor of support calls?

  • Is there ongoing training and certification or did it stop when the system was first launched?

  • How many contacts do we have in the customer organization and how many levels of management do we have relationships with?

  • How often are we interacting with the customer contacts?

Think about engaging customers like we think about engaging employees.  We should provide continuous updates and encouragement. We should deliver performance reviews and strategy sessions about the customers vision and aspirations for our platform. We should communicate frequently and listen for feedback.  Too often we know when the relationship is not going well, but we are afraid to confront the situation. Our teams need to recognize that while churn is bad for us, it is also bad for the customer.  It is embarrassing to admit they made the wrong choice, or they failed to get value after spending money on our solution. They want it to work just like we do, so help them.  Establish a customer advisory board.  Hold frequent open forums with customers to share updates and get feedback. Launch an active customer marketing program.  Engage customers in new feature designs and decisions. Start a meaningful newsletter.  We need to guide customers to do the “right” things and follow best practices to drive their program success. Make them feel like part of the family.

Improving engagement will drive up retention, and it costs way less to preserve revenue than it does to find new revenue.  Stop the leak so that all of the new revenue goes to actual company growth.  The bottom line is that we have every opportunity to up our game on Net Retention and focus on mining the base for upsell, just like we focus on growing new-name revenue. 

Optimism Scales and Inspires - Pessimism Does Not

I try to go for a long walk every day, and while I walk I listen to a lot of news oriented podcasts.  I admit that most of it is politically oriented, and it is often infuriating or shocking.  Given our polarized society, it is easy to be consumed by strong opinions.  One piece really got my attention, and I translated it into how I feel about business leadership.

The pundit was comparing a dystopian view of the present and future with an upbeat positive view.  It was a comparison of “everything is terrible and those guys are going to make it worse” versus “things aren’t perfect, but they are getting better and the future is bright.”  The commentator’s opinion was that optimism “scales” and inspires believers, but pessimism does not.  They pointed to several great U.S. presidents who won their contests and inspired the country with optimism, even in bleak times. The most notable was FDR in the depths of the great depression with his famous speech that “the only thing we have to fear is fear itself.”  Another example was Ronald Reagan who expressed a similar optimism with “America is a beacon of hope” and “a shining city upon a hill.”  These great communicators knew that optimism inspires and scales. It brings people together, even in the face of adversity.

As I thought about how this relates to business, I kept coming back to the question of what leadership behaviors inspire scale, and what behaviors inhibit scale.  We often talk about CEO optimism, or sales ‘happy ears.’  Over-optimism and wildly aggressive plans can quickly become demoralizing when the team feels the goals are out of reach.  ‘Stretch’ goals can turn into ‘impossible’ goals, and when the team stops believing the optimism we do not get the benefit of a scaling effort.  Alternatively, If we project too much caution and pessimism we head down the dystopian path that translates into not believing there will be more opportunities tomorrow than today.  The result is we don’t invest in our future, and that is a guaranteed recipe not to scale.

Teams internalize the slightest whiff of a leader’s negativity and they often adopt a ‘sky is falling’ victim mentality - ‘no matter what we do we can’t succeed.’  Leaders need to make prudent decisions about how to operate their businesses, but if we project paranoia and negativity it will lead to a corkscrew of planning for less, investing less, delivering less, and planning for even less, etc. Without optimism, instead of pulling together we pull apart.

Leaders have to strike the Goldilocks balance between realistic optimism and healthy paranoia. Teams want to be confident that we honestly understand our current situation, but our role is to inspire and lead the team to come together - to scale.  Teams are resilient and can handle honest tough messages if they are delivered with a vision for the path forward to success.  Optimism has to be believable, and when the balance is right, teams rally.  When we wrap our plans in a healthy dose of confidence and optimism we create the environment for scale.  Optimism scales.

Commitments Are The Engine of Performance

‘Objectives and Key Results” (OKR) is a popular management tool. OKRs are a way to disseminate goals throughout the company and ensure that everyone understands their role and responsibilities.  We take the top-level corporate goal, divide it up into a series of objectives that cascade throughout the company in a manner that will add up to achieving the goal.  Each objective has key results that are measurable, so we can determine progress toward achieving the corporate goal.  

The process makes me think about the whole topic of commitments. Commitments are the engine of performance and execution.  Nearly everything we do requires individuals and teams to work together in a coordinated way, and to collaborate across functional areas of the company.  Great execution happens when each team member can rely upon their teammates to deliver their commitments.

Real commitments have a special language all to themselves. A well formed commitment requires an agreement to do something by a certain date – “I will do this by then.”  It must include the time for completion, or else it is just an intention – “I will do this…”  People are usually truthful, and we often can rely on their good intentions, but without a timeframe, or a ‘by when,’ we don’t have a commitment. 

There is a formal language of commitment, and it is something we need to practice and perfect.  In the language of commitment, one party asks for the commitment - “will you do this by then?” The other party can answer in only four ways:

  • “yes, I will do this by then

  • “no, I will not do this by then, but I can commit to do it by another time

  • “I can commit to do something else by then”

  • “no, I will not do this

The distinction between commitments and intentions surfaces all the time in meetings and business interactions.  How many times have you participated in a meeting where you asked somebody to do something, and you received a positive response without a date-certain (in other words an intention), only to be disappointed later when whatever you asked for did not materialize?  All the time - right?  Unless there is an explicit timeframe in the response, a mismatch of your expectations and the other person’s intention for delivery is bound to happen.  You think it is immediate, but the other person intends to do it whenever they can get around to it.  A proper commitment is a contract between the parties.  It is clear, actionable, and measurable.

We expect people to be accountable for their commitments, and increasing the pace of performance is dependent upon being able to anticipate achievement of commitments.  For example, if we have a commitment for a feature to be available on a certain date, then we can start to gear up marketing and sales for the new feature in advance of that date so that when the feature ships, we are already moving forward.  Like a receiver sprinting forward anticipating a pass, or a player skating to where the puck will be, if we can anticipate then we can drive faster and harder toward the goal.  The alternative, if we cannot rely upon a commitment, is to hold off until we really, really see the result before we start the machinery to move forward.  If the whole machine is waiting to see if a commitment was real, then performance slows to a crawl.  

Making a commitment requires integrity, intention and truth.  The person making the commitment has to mean it and believe they will achieve the result as promised.  The person asking for the commitment has to trust the person making the commitment, and trust is earned by demonstrating integrity, intention and truth. Integrity requires that we mean what we say - be clear and precise in your commitment.  We also have to fully intend to do what we say. Lastly, truth is the bedrock of committing honestly - no hidden agendas.  Truth also requires honesty about capability and capacity to perform the commitment.  Don’t commit to something unless you believe you can truly do it.

If you are making a commitment, make sure you have integrity, intention, and truth, and expect to be accountable for your commitment.  If your success is dependent upon commitments made by others, make sure you have trust and you are really getting a commitment and not just an intention. Performance and execution depends upon driving true commitments from each other, and everyone being accountable for the commitments we make. When we do this well, we create an unstoppable machine!

True Time To Value

When you buy a cool new gadget, you can’t wait to bring it home and start using it. We all want instant gratification.  Business software buyers are no different.  Once they decide to buy, they want to see results ASAP.

The concept of time to value describes how long it takes for a technology buyer to actually get value from their purchase.  In the enterprise software world, it typically describes the lag from signing the purchase order until the initial launch of the new system. This is a pretty short-sighted view. Think about the broader customer journey, the clock really starts ticking during the early stages of the sales cycle – once a company decides they need to buy a new platform, and it extends beyond initial launch until the system is truly in production and delivering the benefits that spurred the purchase in the first place.

The typical view of a single measure for time to value is just too macro. There are multiple points along the journey where customers receive value and each one should be measured and celebrated. I recall a semi-fast-food restaurant where each step of the way was time-stamped and the staff was quota-driven for efficiency.  The clock started when you checked in with the hostess, and progress was measured from being seated, taking the order, delivering food, delivering the check, and completing the payment. If you wanted an efficient dining experience, it definitely fit the bill. The point is that this restaurant divided the value journey into micro steps and focused on each element of the experience.

There are similar micro steps in enterprise software deployment. Each step is an opportunity to measure and influence time to value, and drive efficiency into the process.  Remember, it is human nature to want instant gratification, so consider every delay as a disappointment. The faster a customer gets through all of the steps from the decision to buy, to ultimate production, the happier they will be.

Returning to the idea of expanding the definition of time to value, a typical approach is to measure only the implementation time from contract signing to initial launch. This is a vendor centric view, rather than a customer-centric view.  It drives implementation teams to focus on their own stats instead of the customer’s view of success.  Customers have a problem to solve, and in an enterprise setting, that usually involves deploying a platform for a range of constituents and departments.  Simply making the system work does not mean the problem has been solved or all of the potential users are satisfied.

Real customer value will not occur until there is a broad launch and the customer sees engagement and repeat usage of their new platform. “If a tree falls in the forest and nobody hears it, did it make a sound” is an apt analogy.  If we stand up a new system and only the project team is using it, did we really launch anything?  Did the customer get any value?  Should we expect them to be happy and renew?  The answers to these questions seem obvious. Engagement and usage are the measures of success, not completion of tasks and delivery of features.  Therefore, we need to expand the concept of time to value beyond simple implementation, and consider the entire journey from determining need to full deployment and broad engagement.

Command and Control or Collaborate

A few years ago, I had the opportunity to attend a management training program at West Point (thank you Edison Partners).  I always thought the Army was a command and control environment where the command hierarchy made every decision and the soldiers just followed orders.  I was surprised to learn that the management principles they taught were quite different.  Instead of micro-management, they taught a version of Objectives and Key Results (OKRs).  The generals determine the battle strategy and big goals - “we need to take that ridge…” The goals and strategy are communicated down the line, but the lower ranking officers and service people are given a surprising level of autonomy to decide ‘how’ to achieve the objectives. I think of it as leveraging the brain power and creativity of everyone, instead of forcing the narrow top-down ideas of a few and stifling initiative.

I also had the opportunity to hear David Marquet speak a few years ago (also, thank you Edison Partners).  David is a retired navy submarine captain who broke a lot of Navy norms and created a management model that led to extraordinary success.  His book ‘Turn the Ship Around’ had a profound impact on me and changed everything about my leadership style.  It is probably my favorite business book, and I have purchased numerous copies and given them to aspiring, as well as experienced leaders. I highly recommend reading it.  A key learning from the book aligns with what I saw at West Point, but goes further toward empowerment and collaboration as opposed to command and control.

We each have to develop our leadership style and decide if we are going to try to lead by being the ‘smartest person in the room,’ or as I refer to them ‘the spitter,’ or are we going to lead by fostering collaboration and leveraging collective brainpower.  The more autonomy we introduce into ‘how’ our team will achieve its objectives, the more freedom we provide for people to be creative, and the more they may surprise us with their brilliance.  I am a believer that just because someone has positional authority, they do not suddenly have a monopoly on knowledge, intelligence, or creativity.  The old saying ‘two heads are better than one’ is true, but think about how much better a collaborative organization can become.  When we do this well, we create an unstoppable machine!

Leaders have a clear role to play, and companies are generally not democracies.  Somebody is in charge, and the buck does stop somewhere.  The question is where on the continuum from command and control to anarchy will your leadership style land.  Delegating decision making authority can be scary, and requires confidence and trust that decisions will be made with full understanding of the alternatives and the consequences.  This level of understanding comes with experience, and trust is earned by demonstrating aptitude and competence.  Leaders cannot simply abdicate all responsibility for decisions, but they can open a space for their teams to grow and demonstrate their ability to take on greater responsibility.

Bold Innovation

I have been thinking a lot about innovation strategies.  I am reminded of two Albert Einstein quotes that seem appropriate:

"The same thinking that has led you to where you are is not going to lead you to where you want to go."

"Creativity is intelligence having fun."

The first quote has always been a favorite of mine.  I have usually relied upon it when people ask for career advice - if you want to advance your career, you have to go beyond what got you to this point.  However, when thinking about our innovation challenges, it really drives home the point that we can’t just think about small incremental improvements or product tweaks if we want to make dramatic changes in our business trajectory.  That would be relying on what got us here to define the innovation for what is next.  This is not to say we have to completely reinvent and start over - to use another quote, “Those who don't know history are doomed to repeat it.” (Edmund Burke).  I think about the innovation challenge as requiring us to be willing to break with the way things were done in the past, and focus on how they will - or could - operate in the future.  Instead of just improving how our customers do what they are doing today, think about how to lead them to a better way to achieve their goals.. “Play it safe and you will always end up with mediocrity” (Simon Sinek).  Taking bold actions can sometimes lead to failure, and sometimes lead to greatness.  It rarely leads to mediocrity.

Innovation requires creativity, experimentation, and a degree of risk taking.  It requires us to take bold steps, and maybe to tolerate some missteps. To be the  dominant force in our market, playing it safe is not a long-term strategy for success.  One of the guiding principles I have followed for years is “always question the status quo.”   Every time somebody says something like “that is the way it’s always done” or “this is how everybody does it,” I immediately question the premise.  Like a little child that just keeps asking ‘why,’ I want to know the root reason for the status quo, and usually that leads to an opportunity for innovation and change.  

At the turn of the 20th century, most transportation was by horse and carriage.  A few innovators created automobiles (or horseless carriages as they were originally called).  The first few cars were pretty inferior to the carriages, but early adopters shaped the industry and cars quickly displaced carriages.  Focusing our innovation on the ‘way things have always been done’ feels to me like focusing on making a better and better carriage.  If we want to innovate effectively, we have to move our industry and deliver different and better solutions. Let’s not become the best carriage maker in a time when the market is moving to autos.

That takes me to the second Einstein quote ‘Creativity is intelligence having fun.’  Every company has smart people with creative minds.  You may need to listen for them and strive to find them in your organization.  They may be hiding under the proverbial ‘rock’ of their current role.  Innovation will be fundamentally driven by creativity, find the creative souls and start having fun creating the next big thing.  Making a dent in our universe (Steve Jobs) is not going to be easy, so make the hard work fun. 

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.