The Need For Speed

In the world of SaaS enterprise applications, starting a successful implementation project is all about the need for speed.  Customers have subscribed and are itching to work with the software.  Implementation partners want to quickly take that next step the change management process, which requires the customer getting familiar with the software.  

So setting your fledgling project on the road to success depends on getting an instance up quickly (among other things).  Call it "Conference Room Pilot 1" or a "sandbox" or "the staging instance" or whatever else you like, it's important to get an instance up as quickly as possible.  In all honesty, it does not need to be populated with customer data, customer configurations, nor customer business processes.  In fact, it is usually better to put up a very plain "vanilla" instance and encourage the customer to try out the business processes baked into the software in order to limit or eliminate customizations later in the project.

An important early step in the sprint from subscription to first valuable use...get an instance up as quickly as possible.   Embrace the need for speed.

You Get What You Test For

You get what you test for. - author unknown

When you move to the cloud, you leave much of the burden of on-premise applications behind.  But one thing you won't leave behind is testing.  It's a basic premise of configuration management:  when things change, you test.

In terms of testing, nothing changes when you move to the cloud.  Every version upgrade, every patch, every whatever-they-call-the-change-this-month, you test.  Functional unit test, integration test, system test, performance test, and so on...it's all still with us.

It's all still with us because, in most cases, patches and updates are built for a large number of customers.  And there may be variations across that set of customers.  Some of those variations will cause changes in results from one customer to another.

At the end of the day, each customer has the ultimate responsibility of making sure their cloud system works for their unique situation.  The same system with the same configuration will not work for all customers, any more than the Chevy Spark my wife drives for urban commuting will work for someone whose primary need is an off-roading vehicle.  So if Chevy were to make a suspension system change to all vehicles across the board, it may act differently for the off-roader than it does for my wife.  So...we test.

It's your system, regardless of whether it's in the cloud or not.  And you get what you test for.

I Can't Stand It

I can't stand it
You're fooling around, I can't stand it
You're running around, I can't stand it
You're fooling around with my heart
                     - From Eric Clapton's "I Can't Stand It"

I've taken leave of writing about Oracle products and services.  Since joining Oracle and "taking the King's shilling", I felt that I could no longer be an impartial voice.  But I just can't stand it anymore.

My energies and my passion for the world of tech is, to a huge degree, wrapped up in Oracle.  I see things happening.  I read the opinions of others.  I hear things.  And I feel the urge to jump into the mix.  Refraining from doing so has somewhat sapped that energy and passion.  So I'm jumping in again, here, on LinkedIn Pulse and on my Twitter feed.

As I do this, you need to know a few things:

1. I can't talk about products or services pre-release
2. I can't share information about release dates
3. There is a limit to my impartiality.  After all, Oracle puts the roof over my head and the food on my table.
4. All the opinions expressed by me anywhere are entirely my own and should not be construed in any way as opinions, comments or commitments on behalf of Oracle Corporation.

Yeah, I think that's about it.  I can't stand it no more.  Game on.

Self-Service vs No Service

Self-service is a huge trend in enterprise software.  The basic idea is that, rather than expending the service provider's resources on simple matters, simply enable your customers to handle the matter on their own.

The idea did not start in enterprise software.  Think of self-service gasoline stations, buffet-style dining, loading items into your shopping cart at Trader Joe's; all examples of self-service.

Done well, self-service raises customer satisfaction while decreasing provider costs.  I'm a long-term fan of Expensify - a product that optimizes the experience of self-service expense reports.  They are an example of self-service done well.  Done poorly, customer satisfaction plummets to the point that customer loyalty is vaporized in an explosion of frustration.  Think of the virtual receptionist used with most customer support telephone lines...one wonders whether the idea is for the customer to help themselves or simply keep them in a a vortex of navigation options until they simple give up and hang up.  That's done poorly.

There is simply no better or quickly way to destroy customer loyalty to a product or service than to route communications with that customer through a service hub with an automated attendant. It's a strong message to customers that a service or product  provider does not care about you, your issue, or your feelings regarding the experience of using the product or service. "Thanks for buying...hope all goes well, we're outta here"!  No service.  I'm always a little taken aback when I see it.  And I see it more frequently these days.

Some self-service is good. For example, I prefer to write my own trouble tickets - I can be much more precise about my issue when writing it up myself as opposed to explaining things to an analyst.  But the follow-up should be someone reaching out to work my issue.  When Step 2 consists of automated self-help suggestions, I know I'm in for a frustrating experience because we've crossed the line into the realm of no service.  (it's like taking my iPhone to the Genius Bar and hearing the phrase "As it turns out..." - it's a guaranteed sign that frustration will follow).

Customer service still matters.  Want to keep your customers...and even make those customers advocates for your product or service?  Take care of them after they buy.  But don't make that transition into no service...unless you're ready to shrink your customer base.

I Love It When A Plan Comes Together

I love it when a plan comes together.
                    - John "Hannibal" Smith

So I had a really cool conversation with a long-time friend over the weekend.  The friend is CFO at a Fortune 2000 company…I won’t call him out here for privacy’s sake, but you would recognize the company name.

Anyway, friend was telling me their story in going to SaaS.  It’s worked out very, very well based on some decisions made early in the process.  We burnt the midnight oil together working through some of those decisions, so it’s always gratifying to hear that they worked out.  I thought I’d share a few here in the hopes it might help somebody reading this…

1. They knew what they wanted going in…much more specifically than simply “transforming the business”.  The desired end states were: a) an improvement in the speed of responding to market-driven changes, and b) a substantial reduction in IT operating expenses.  That’s it.
2. Their approach throughout the project was a strict application of Occam’s Razor:  the solution requiring the fewest assumptions was the right one.  They were passionate about keeping things simple.
3. Another thing this company was very passionate about:  letting go.  Very little data was converted to the new SaaS system.  They started with opening financial balances and historical queryable flat files from their legacy system.  They took a similar approach with their HR records.  Saved huge amounts of money and time in switching to SaaS.
4. More on the letting go thing:  they let go of all their old business processes, opting to use those baked into their SaaS applications suite.  At their first Conference Room Pilot, they came out with an 80 percent fit.  With careful planning and tailoring, they increased that fit to 90 percent by CRP 2.  The last ten percent?  Some of it they decided they didn’t need and some of it wound up on a small, on-prem server integrated with their SaaS apps…mostly at the reporting/BI level.

So the end results?  

First, I should mention that it took this particular company four months to implement and cut over; it could have been quicker, but they invested about one-third of the project effort in “kicking the tires” before going live.  Brilliant...and definitely not my idea.  The testing effort turn out to be a huge help with user adoption within the company.  

Second, they have reduced their IT operating costs.  According to the CFO, IT operating expenses dropped by over 60 percent, mostly due to eliminating the need to maintain their in-house applications suite.  Although my friend also cynically notes that most of the savings from software licensing and support fees was consumed by SaaS subscription fees: “all the SaaS vendors had already worked the numbers on that part of the deal.  Even so, the savings realized through reductions in infrastructure and in-house support were a little more than we expected.”  

Third, are they responding to market changes more quickly?  “The jury is still out.  We just don’t have enough data over a significant period of time to know for sure.  But we have made a few changes based on reactions from our customers and we’re responding in days and weeks rather than months.  We hope that continues."

Are there speed bumps in this story?  Of course.  There's always a little manure involved with the prettiest flowers.  But overall, it's a pretty gratifying story.  By understanding their desired end states before starting the project, by treating simplicity as a discipline, and by letting go of the past to embrace new things, they have some pretty solid early returns.

So, real life.  Somebody got it right.  I love it when a plan comes together.  Don't you?

An Old Trick From An Old Dog

Old dogs look you in the eye, they hold your heart, they never lie,
They bark at planes up in the sky and wish that they were fliers.
Old dogs dream about the past when they frolicked fields of golden grass,
And chased the icy winter's blast, to lie by home fires burning.

Old dogs wander off alone but old dogs know the way back home,
The slightest scent, the buried bone, the hunter home returning.

                                                   - From "Old Dogs" by Bill Staines

I was recently asked how I evaluate different enterprise applications systems.  In all honesty, it's pretty simple:  I use a conceptual chart.  Yeah, really, a single chart.  This is it:

So I look at three different layers of components:  business value, development and deployment.  And I consider the components listed above in each of those three layers.  

I may dig a little deeper in some areas.  And I may even get into some classic system engineering analysis, with figures of merit and all that, but this is the upshot of it.  No sales hooey, no trendy buzz terminology, no nothing.  This is it.  I also use it for solution evaluation:  it's a great little framework for peeling back the layers of the onion and exposing solution risks.

Been using this framework for around seven or eight years now, so I guess that it qualifies as an old trick from an old dog.  But it still works.

An Old Trick From An Old Dog

Old dogs look you in the eye, they hold your heart, they never lie,
They bark at planes up in the sky and wish that they were fliers.
Old dogs dream about the past when they frolicked fields of golden grass,
And chased the icy winter's blast, to lie by home fires burning.

Old dogs wander off alone but old dogs know the way back home,
The slightest scent, the buried bone, the hunter home returning.

                                                   - From "Old Dogs" by Bill Staines

I was recently asked how I evaluate different enterprise applications systems.  In all honesty, it's pretty simple:  I use a conceptual chart.  Yeah, really, a single chart.  This is it:

So I look at three different layers of components:  business value, development and deployment.  And I consider the components listed above in each of those three layers.  

I may dig a little deeper in some areas.  And I may even get into some classic system engineering analysis, with figures of merit and all that, but this is the upshot of it.  No sales hooey, no trendy buzz terminology, no nothing.  This is it.  I also use it for solution evaluation:  it's a great little framework for peeling back the layers of the onion and exposing solution risks.

Been using this framework for around seven or eight years now, so I guess that it qualifies as an old trick from an old dog.  But it still works.

You Can't Do This Backwards

Having returned from a stay-cation invigorated with new thoughts...

There was a time in the world of enterprise software when one could snap up some cool, interesting technology and figure out a way to leverage the new, shiny stuff in a way that benefited the enterprise.  Those days are long gone, if for no other reason than the enterprise software vendors are cranking out new applications, tools and technology far too quickly for a technology-centric user to keep up.  My own employer, Oracle, releases Cloud products at a rate of several per month.  Think about that for a minute:  we're not talking patches or releases, but entirely new products.  That's mind boggling.

In the age of fast and furious enterprise software development, you have to think the business results out ahead to time - what are your desired results or end states?  Then acquire the tech you need to make those desires reality (keeping in mind that you can often use what you already have).  

You can't do this backwards anymore, because it's so easy to get lost in a sea awash in products.

SaaS - Some Food For Thought

Had an interesting conversation with a new SaaS customer this week.  Big enterprise customer, along with an implementation partner, is making the move from on-premise systems for all of their Sales applications and HCM applications to SaaS applications. And they're leaving their financial systems on-premise, hoping to integrate between the SaaS apps and the on-premise apps.  To make the mix spicier,  they've picked different platforms for the Sales apps and HCM apps...same vendor, but obviously different platforms for HCM and Financials.  The approach they're taking is "lift and shift" - we want all our existing processes and reporting to survive the transition.  And they want to go live with Sales and HCM simultaneously...aka "big bang."  Fortunately, it's all in the planning stages...no purchases of SaaS yet.  I got called in to provide some advice.

I'm sure you can imagine my muffled screaming while drowning my frustration in Dr. Pepper over the approach this particular customer has planned out.  No need to hash that out here.  But my advice actually turned into a set of questions...good questions actually, which is why I thought I'd share them here.  Here we go:

1.  Can you describe the desired outcomes you hope to achieve by moving from on-premise to SaaS for Sales and HCM?
2.  What synergies do you hope to achieve by transitioning Sales and HCM simultaneously versus taking a staging approach?
3.  Do you have an inventory of your current assets?  Especially the state of your data?  How much historical data to you plan to convert to the new system?  How about a list of current data model customizations and the reasons behind each customization?
4.  Have you considered and examined the business processes baked into the SaaS apps you're considering?  Could the baked in business processes work for you?  And, if not, why not?  Could the gaps be addressed within the functionality of the SaaS apps?
5.  Have you measured how often each of your current reports is used?
6.  What are the metrics that will help you know that you've achieved or fallen short of each of your desired outcomes?
7.  What do your stakeholders - especially your administrative specialists and first-line supervisors - think of this project?
8.  Has anyone attended any training for any of the SaaS apps you're planning to implement?  If so, what feedback do they have from the training?
9.  Who are the C-Level sponsors for this project?  What is the plan for keeping those sponsors engaged?
10.  On a scale of 1 to 10, how willingly and quickly is your enterprise willing to change?  Just gut feel, right now...what's the number?

I had a few more questions that are unique to this situation, but I started with these.  Any guesses on how the conversation went?  Bottom line is the customer is taking a step back to reconsider their approach and the partner is grateful for that (the partner execs had that look on their face that you see when they realized that loss hemorrhaging on a fixed-price contract is about to begin).

Now nothing special came from me here.  Just a few simple questions, most of which we've been kicking around for at least a decade now.  So save your project early...feed your stakeholders some food for thought.

If you've got more good food for thought questions relating to SaaS implementation, feel free to share in the comments.

Thoughts On Social Media

With the recent announcement that LinkedIn will be acquired by Microsoft, we're seeing quite a bit of chatter on the future of social media.  So I thought I'd share my thoughts on the matter.

When thinking about social media, I see two distinct categories:  public social media and media behind the enterprise firewall.  And I have distinct thoughts on both.

When I think of public social media, I think of the popular platforms out there:  LinkedIn, Twitter, Facebook, G+, and similar platforms (sorry, no Slack…I still haven’t figured out how to categorize Slack).  My point of view is that public social media has “jumped the shark”.  When it first came on the scene, public social media was about initiating conversations and exchanges of ideas.  Somewhere along the way, it turned into a set of platforms for people to simply shout out their messages on various subjects; the discussion aspect is shriveling on the vine.  And, again strictly from my point of view, the discussion is the big value of public social media.  Less discussion, less value.  And yes, I'm aware of the irony of using a public social media platform in sharing these thoughts...

Behind the enterprise firewall, we’ve barely scratched the service in realizing the benefits of social media.  The concept of value from the exchange of ideas also applies here.  But the big value add, from my perspective, is in mining that social media data to connect people in ways that would never occur if we simply relied on organization structures.  Who would know that Alice in Accounting had an interest and skill in color design theory if she didn’t mention it in a chat?  Or that Bob in marketing knows can read electrical schematics if we didn’t have a social network for team member hobbies?  As we break down organizational stovepipes, finding special skills within our enterprise teams and connecting those skills in new ways for important projects becomes a critical part…maybe the most critical part…of the HR mission.  And social media in the enterprise is just one way of doing that…especially when you add suppliers and customers (especially customer advocates) into the mix.

So you’re thinking “Floyd, does this mean you see a change afoot in the shape of social media?  Maybe a decline in the popularity and use of public social media at the same time  enterprise-based social media use grows and evolves?”  Answer:  yup.

Bet you have thoughts on this too.  Share them.  Take advantage of the Comments functionality on this particular public social media platform.

Stick To Your Knitting

In the States, "stick to your knitting" is an idiom for focusing on an already-familiar activity.  For SaaS vendors, better advice was never given.

The SaaS market space is young and still evolving.  As SaaS companies evolve and develop, there is a huge temptation to be all things to all customers.  After all, with 40 percent growth rates across the board, isn't it tempting for a SaaS HCM vendor to grab more revenue with a new financials suite?  Yeah, unless you're an Oracle or a Salesforce or an IBM...don't do it.

The most important key to success as a SaaS provider is staying in touch with your customers:  knowing their desired results and providing the best experience in achieving those results.  That requires serious knowledge of business processes in a specific area of expertise, such as supply chain or project management.  It's tough to build that expertise in-house.  Without naming names, we've all seen recent examples of successful SaaS vendors branching into new product areas only to get their heads handed to them on a platter.

The alternative?  Partner with other SaaS providers offering complimentary expertise.  Don't build up that new HCM Suite if your strength is in Sales software...team up with somebody already dominant in that market space.  If you focus on project management, find a partner with a solid financials offering.  Build win-win relationships that benefit you, your partner and your customers.  Doing so keeps you nimble, responsive, and best-in-class.

Stick to your knitting.  Your customers will love you for it.

About Phones and Mobility

We celebrate Memorial Day in the States every year at the end of May.  One of the things I like to do on the holiday is catch a baseball game with the local minor league team.  And I tend to watch people in addition to watching the game.

This year I made it to a game.  And while I was there enjoying the game with a hot dog and a soda, I noticed something very interesting.  I saw more people carrying mobile flip phones and other "unsmart" phones than smart phones (Note:  I do not live anywhere near Silicon Valley).  Smart phones seemed to be predominant in the over 40 crowd while "unsmart" phones appeared to be the choice over the under 40 people.  I was a bit stunned.

Now, keep in mind some qualifiers.  First, there were probably about 6,000 people at the game...I probably laid eyeballs on a 10th of those people at the most (I spent more time checking out people as the home team lost badly).  Second, my ability to judge age is not the best.

Still, my observations got me thinking.  Thinking enough that I actually talked to a few people about it.  All of the people carrying the "unsmart" phones made their choice because the cost of the monthly service was so much less.  And so long as their phone can text, check email, and function as a phone (in that order of priority), they were willing to live with the limitations and save the money.  Those people carrying smart phones?  In most cases, their employer subsidized part or all of the hardware and service costs.

Now here is the interesting thing to me.  We stress mobility in the enterprise for two reasons:  to increase the productivity of our workforce and to connect with our customers.  But if the smart phone tide for consumers is beginning to ebb due to increasing costs, doesn't that eventually disrupt the idea of using mobility to connect with our customers?  Is cost beginning to drive a new trend?

So that's how I spent my holiday...at the ballpark observing and pestering people about their mobile phone choices.  I'd be interested in hearing your thoughts and opinions.  Comments welcome.

Let Mikey Try It

Life Cereal came up with the perfect early adopter commercial back in the 70's:  Let Mikey try it.

It seems as though the providers that have mastered SaaS have a few things in common; one is leveraging an early adopter program.

The idea is that the provider shares new applications or new major releases with a small set of specific customers before making the new software generally available.  They do that because it allows them to learn from those customer experiences: catching software bugs and...just as important...perfecting the service component in the offering.  It's the latter component where an effective center of excellence comes into play.

By addressing service and service process issues based on learning acquired in the early adopter period, an effective center of excellence will have standardized processes and procedures for customers onboarding and starting with the new software by the time the product is generally available.  Which makes getting from onboarding start to valuable first use happen better, faster and cheaper.  And, in a SaaS world, that's the key to customer success.

It's a good model:  let Mikey try it.

A CoE for Customer Success?

So if the model we've put together in the past few posts is the key to the SaaS lifecycle, how does a Center of Excellence tie into all this?  Good question.  Let's take a look at it.

The CoE I work in, which seems typical for the industry, essentially divides the work into three categories:  Programs, Customers and Solutions.  The detail plays out in the following table:

BTW, don't thank me for this work breakdown.  It's the brainchild of Oracle's John Cafolla.  My particular role, which falls mostly into the "Solutions" category, is currently focused on building tools and technologies that improve the transition of our SaaS customers from "Start" to "First Valuable Use" - yup, another application of the "better, faster, cheaper" mantra.

Keep in mind that it's an evolving approach...note that "Escalation Support" (which we're previously defined as a negative-value activity in SaaS) is still such a substantial part of our workload as to hold a spot in the table.

It's also important to keep in mind that our particular CoE also deals with a huge base of customers coming to SaaS from legacy applications.  Due to the sheer volume, moving those customers forward is just as significant as helping customers who are new to us.

Finally, it's also worth noticing that the Solutions work focuses on the "Onboarding" stage of the SaaS Lifecycle...for the moment.  As our own journey as a SaaS provider moves forward, we'll eventually shift into an emphasis on tools and technologies to improve customer experiences in the "Nurturing" stage.  But that's a topic for another day.

So you asked how a Center of Excellence fits into the customer success - oriented SaaS lifecycle model?  Well, here ya go.

Comments encouraged.

Drivers

About the driving wheel
Want to know how it feels
To be taking time out, turn it all about
We're taking hold the driving' wheel
            - From Poco's "Drivin' Wheel"

If you can't measure it, you can't manage it
             - Peter Drucker

In my last post, I promised we would talk about influence drivers here.  So let's do that.

In any endeavor we undertake, we naturally want to achieve success...one or more positive outcomes.  But measuring the positive outcomes themselves give you after the fact information; puts us into reactive mode.  And, in customer success, we want to be proactive rather than reactive.  With that in mind, the idea is to measure drivers that influence positive outcomes...drivers that indicate how we're doing during the journey to our outcomes.

A really convenient point here:  most of our resulting outcomes are really determined during SaaS onboarding and nurturing...and most of the influence drivers we find relate to onboarding and nurturing.  Cool how that logic ties together, isn't it?

In a nutshell here, the idea is to measure influence drivers in a timely fashion (note that I'm avoiding the discussion of real-time, near real-time, and the related technical dogma - I'll only say that sooner is better).

So if it were me measuring customer success, I'd focus on something akin to the following:

Onboarding Drivers

• Time to Provision:  Measure in days the time from when the customer subscribes to when they have access to all the SaaS environments promised.  The smaller the number, the more positive the influence.
• Time to Value:  I'd measure this in days from the completion of the provisioning to the time of first value use or "go live" date.  The quicker the better.
• Initial Adoption:  What is the rate of use by the initial individual users at the time of first value?  I'd measure this by transaction numbers or usage (daily, monthly, and/or frequency).  We're simply setting a baseline here to measure growth or contraction during nurturing.
• Customer Satisfaction:  This comes down to a basic yes or no question:  would the initial set of users recommend your service at the time of go live.

Nurturing Drivers

• Adoption
• User Adoption: growth in usage - more transactions, more users
• Feature Adoption:  do we see new types of transactions?  We're looking for growth in use case solutions or in the use of additional features included in the applications.
• Capacity Utilization:  how many seats a customer is using relative to those they are paying for in the subscription?  the higher the ratio or percentage here, the better.
• Business Results:  measurable gains that relate to the outcomes desired by the SaaS customer.
• Escalations:  the number of open inbound requests, the number of closed requests, and the time to resolution for closed requests.  The smaller the numbers here, the more positive the influence.
• Customer Feedback:  The same deal here as with Customer Satisfaction, just a different point in the lifecycle.  This comes down to a basic yes or no question:  would the initial set of users recommend your service at the time of go live.

Not only would collect these for onboarding and nurturing metrics, but I would share the metrics for each customer with that customer.  Because influence drivers matter just as much for customers as they do for providers.

In addition to the metrics above, I would also measure these outcomes:

• Renewals:  both in terms of dollars and number of customers who extend their subscriptions
• Growth: both in terms of dollars and number of customers who subscribe to additional SaaS products
• Churn: both in terms of dollars and number of customers who cancel their subscriptions

Let me sum it up.  The mission of customer success is to add value for both customers and providers.  To add that value in the world of SaaS, you must be proactive rather than reactive.  And the best way to start being proactive is to measure influence drivers.

Last point for the day:  I'm stealing a huge portion of these ideas from Guy Nirpaz's book "Farm Don't Hunt: The Definitive Guide to Customer Success".  A very worthy read if you're into SaaS and customer success.

Comments welcome...

Customer Success - What It's Not

Sometimes it's easier to wrap your brain around an idea by first defining what it's not; kind of like picking the right answer on a multiple choice test by eliminating the bad choice first.  Sound like fun? Let's give it a go.  For your edification, some examples of what customer success is not:

• Pipeline Management:  The idea here is to follow the classic sales funnel (aka the image below) by driving the customers up for renewals in the next quarter through that process.  The problem?  Most customers decide whether or not to renew long before the SaaS provider starts this process.  So this approach?  Not customer success.

• Project Management:  A great model to follow while a new customer is on boarding or while an existing customer onboard new applications or functionality.  But the Project Manager approach fails to address the subsequent crucial nurturing cycle that takes place after Onboarding.  That's not customer success.
• Customer Support:  The support approach, in practice, deals mostly with resolving escalations: "the customer is unhappy", "the customer has threatened to cancel", you know...all the unhappy situations where providers jump through flaming hoops to make a disgruntled customer happy again.  Activity is triggered by the escalation, and that activity is usually expensive.  In customer success, the idea is to be proactive and make an impact before the customer goes down the path of disgruntlement.  So Customer Support does not equal Customer Success by any means.

Note here that our discussion of what customer success is not has been focused on outcomes: renewals, onboardng, escalation resolution.  None fit.  So what's my suggestion?  Focus on the drivers during the onboarding and nurturing stages that provide your desired outcomes by influence.  That's right, manage a portfolio of drivers in order to add value through a customer success approach.  What drivers?  

Well, kids, it's Friday as I write this.  And T-Bone Walker taught us all that "the eagle flies on Friday" (Google up a tune called "Stormy Monday" for more details on that).  My eagle is set to fly. The next post will be about drivers...probably on Monday.  Y'all have a good weekend.

Defining Customer Success

Since I've started this new blog, people have noticed that I've picked up a real focus on customer success.  Some have even implied that it's the only subject I'll be writing about.  Seems those folks don't know me very well...I'll be writing about a wide variety of topics relating to enterprise software.  It's just that I've been deeply involved lately in SaaS Customer Success matters and I've learned a ton.  That's what bloggers do: we learn about something that is new and exciting and useful, then we share that learning with others by writing about it.  That's what I'm doing here.

On to the second thread of feedback I've been hearing:  define this SaaS Customer Success thing.  We've all heard about it, we know it's important, but we struggle to clearly define it.  OK, let's tackle it right now.

I actually go with two different definitions.  Because your definition of customer success in the SaaS world depends on your perspective:  are you a SaaS customer or a SaaS provider?

In providing a definition from the customer perspective, I'm spinning off a definition provided by SaaS Customer Success guru Lincoln Murphy:  customer success is the achievement of your desired outcome(s) through interactions with your SaaS provider.

• Achievement of your desired outcome(s) - did you get what you expected to get? Are things better than when you started your SaaS journey?
• Interactions with your SaaS provider covers all the interaction touch points:  market and sales, onboarding, nurturing...did it all work together to make things better as quickly and inexpensively as possible?  

So, you may ask, what is Floyd thinking with this latter portion of the definition?  I'm thinking that when we talk about Software-as-a-Service, we place a huge emphasis on the service - if it was just about the software, we'd call it Software-as-a-Software...and that doesn't make any sense at all, now does it?

From a provider perspective, the definition is a bit more quantitative than the qualitative definition customers use.  It's all about maximizing customer lifetime value:  CLV=APA/Customer Churn Rate

• CLV = Customer Lifetime Value
• ARPA = Average Revenue Per Account (Monthly)
• Customer Churn Rate = The Monthly Percentage of Customers Cancelling or Failing to Renew

Think about this formula for a minute and you'll realize the huge influence of the "interactions" portion of the customer definition on CLV.  So both customers while emphasize the importance of service interactions, SaaS providers are incentivized to optimize those interactions.

So now that I'm up to my eyeballs in the work of a Center of Excellence for Customer Success, what's my personal bottom line?  It's in creating more value more quickly for both the customer and the provider.  That's a tough nut to crack.  We'll talk about it in a subsequent post.

Needless to say, your feedback is always welcome.  Get intimate with the comments.

SaaS - The High Road and The Low Road

O ye'll tak' the high road, and I'll tak' the low road,
And I'll be in Scotland afore ye
              - From "The Bonnie Banks of Loch Lomond"

So we just talked about the lifecycle in SaaS.  While we can see that it's more than a little different from what we've seen in the past, it's also a bit tough to match those lifecycle states to the types of activities SaaS service providers (both software vendors and partners) and customers.  One group  must 'take the high road while the other must 'tak the low road...two paths to the desired end results. With that challenge in mind, I offer up the following for your consideration:

Customer Activities play out like this:

• New:  A newly signed customer.  The important goal here is to gain user acceptance by winning hearts and minds.  The best tactic here is to get to "first valuable use" (aka "a big win") as quickly, easily and inexpensively as possible.
• Growing:  Customers want to be here most of the time.  If customers achieve their desired results, this is when it happens.  We're also looking for growth in value through an increase in engagement:  more users, more transactions, more use of features, subscription to additional products.
• Renewal:  A very short activity in which the customer (hopefully) opts to renew subscriptions and jump right back into the growth phases.
• Cancelled:  If the New or Growing phases have not been good experiences, customers will terminate subscriptions and move to another solution.  One of the benefits of SaaS for customers - doing this is easy in comparison to the historical effort of switching platforms, because there is no tech stack to transition.

In parallel to each phase of Customer Activities, Service Provider activities play out like this:

• Integrate Services:  This includes everything the Service Provider does to get a customer from "New" to that first valuable use.  Creating and provisioning instances, implementation, initial training, and whatever else is done to get the new customer's subscribed services up, running, and adding initial value.
• Tending:  Much like parenting a newborn child, the work does not end when the baby is delivered.  You tend to that child:  feeding, changing, socializing, managing health and development... It's much the same with SaaS customer.  You're continually working to develop value: new use cases, new capabilities, post-implementation training, and so on.  The quality and volume of the Tending effort here is directly related to whether customer accounts head to Realization or Churn.
• Harvesting:  This is when the Service Provider reaps the results of their efforts in Integrate Services and Tending.  If it went well, we'll see customers renew their subscriptions.  We'll also see opportunities to upsell (expansion to existing service subscriptions) and cross-sell (new services for existing customers).  But if Integrate Services and Tending did not meet expectations, we move into...
• Saving: Work done to address issues that may lead to customer cancellation.  This is always bad news, but the real bad news is this:  across the SaaS industry, we have yet to be able to consistently save projects that have gone off the rails during the Integrate Services or Tending phases.  To a very great degree, there is no saving the soup once it's turned bitter.

So the big takeaway here?  SaaS customers and service providers take different paths and engage in different activities to wind up together in the same happy Realization zone...it works better when each  knows how the other gets there.  And it's also important to realize (and this is a hint for the next post) that creating customer success is an exercise in portfolio management - it's not a traditional pipeline management effort.

Comments?  You know where we keep 'em.

Stealing Ideas

"It's not where you take things from - it's where you take them to."
                         - Jean-Luc Godard

In my role with Oracle's Cloud HCM Center of Excellence for Customer Success, I'll freely admit that I'm stealing things from others. One of my favorite sources of Customer Success ideas comes from Totango.  A pretty creative bunch of folks there...they worked through a model for SaaS customer success and then built SaaS applications based on that model.  Guy Nirpaz, the founder of Totango, recently released a book literally giving away the model and how it works - Farm Don't Hunt:  The Definitive Guide to Customer Success.  Great read for anyone in the SaaS business.  The following represents my own point of view on Mr. Nirpaz's ideas....credit where credit is due.

I've written recently about the calories I've burned on figuring out customer success.  Well, I'm still burning those calories...lately around figuring out the SaaS customer lifecycle from a customer success point of view.  I think it looks something like this:

Onboarding:  something is new.  New customer, new application, new feature(s), new users.  The key idea here is that SaaS customers/users have yet to derive value from the product or service.  The most important thing here is to get that customer to first use (or first value) as quickly and easily as possible.

Nurturing: all parties are attempting to develop the new thing in order to lay the foundation for growth.  Training, new use cases, advising, and whatever else you can think of here.  The idea is to promote acceptance and growth through engagement and adoption.

Realization:  when nurturing goes well, users see realize the value they hoped for when they subscribed and onboard.  Things for the customers/users are going better, faster, cheaper, or some combination thereof.  Partners see stronger relationships and additional work opportunities from those customers/users.  SaaS vendors see more use of subscribed seats by customers/users, higher levels of use for subscribed features, and customer user growth: more features, more user seats, additional applications.  Of course, all growth drives everyone through another cycle of on boarding, nurturing and realization.

Churn:  this is an ambiguous term for all the things we don't like to talk about:  escalations due to issues with the service or product, or *gasp* cancellation of subscriptions.  While we all try for saves when experiencing churn, industry statistics for SaaS indicate that we're not very good at it.  Prevention is the best means to dealing with churn.

Next up we'll talk a bit more about what all this means.  But at this point, we're just stealing ideas to establish a framework for talking about this stuff.  

Thoughts? You know what to do...

Customer Success - Three Little Birds

Rise up this mornin'

Smiled with the risin' sun
Three little birds
Pitch by my doorstep
Singin' sweet songs
Of melodies pure and true
Saying', ("This is my message to you")

Singing' "Don't worry 'bout a thing
'Cause every little thing gonna be alright."
Singing' "Don't worry (don't worry) 'bout a thing
'Cause every little thing gonna be alright!"

               - From Bob Marley's "Three Little Birds"

Having been at this enterprise software game for awhile now, I've gotten fairly good at looking at trends and describing what happened (I'm good at spotting developing trends as well, but my track record at predicting the timing of results is weak sauce at best).  Over the past decade, I've seen the shift in customer relationships.  Success for any enterprise software provider is no longer about making the sale...it's about customer relationships that lead to customer success.  Granted that sounds a bit like sales and marketing fluff, so let me share three little birds of change to drive home my point:

1. We've gone from a software licensing model to recurring revenue model baed on software subscriptions (SaaS, PaaS, DaaS, or whatever _aaS you like).  The seller does not get paid up front as in a software license deal, so the pattern of customer relationships has shifted from an all-out, one-off effort to score the big deal to one of more consistent investment in helping customers achieve desired outcomes - which, in turn, keeps the subscription revenue flowing.
2. Everything has a digital component supporting real time data streams.  This is the big promise of the "Internet of Things".  It's all about providing value via services while the customer uses the products.  And it's made possible because products are digitally tied together.  GM knows when my car has low tire pressure and sends an alert to my dashboard.  DaaS vendors know when my subscribed database hits 85 percent of storage capacity, so they can offer more storage before I hit the limit.  My neighbors know when their children wander out of a certain physical area because they get an alert on their cell phones...including the location of the child when the alert was sent.  Everything is connected or soon will be.
3. Customers expect more.  They've seen what highly-responsive consumer software can do: Google, Facebook, Snap Chat, Amazon, LinkedIn, Evernote.  And that's now the expectation of enterprise software products.  And to take it even further, cloud and SaaS enterprise applications make it easier than ever to simply click in order to try the next thing.

Faced with the combined impact of these three changes, enterprise software vendors can no longer focus on the one-time license sale by emphasizing a technical platform, or breadth of features, or even ease of use.  To win and keep a customer's business, we have to focus on helping that customer achieve and maintain desired outcomes.  That's the upshot of customer success.  And customer success is the gist of succeeding in enterprise software.

One last thought.  Customer success is a relatively new thing.  Vendors and customers alike are still learning how it works and how to use it.  And that's why you need a Center of Excellence for customer success.  More on this later, but comments are welcome now.

Testing - Make Sure It's Right

We've seen lots of brain power expended over the past several decades on the subject of software testing. Static, dynamic, white box, black box, gray box, API, code coverage, fault injection, mutation (yeah, really...you can't make this stuff up!), equivalence partitioning, value analysis, fuzz testing (my personal favorite, as I keep hoping that working with fuzz will resurrect my hairline), use case, unit, integration, system, acceptance.  Not nearly an all-inclusive list, but you get the point.

As for me, my approach to testing is really, really simple:  does product and/or service work the way we expect it to work?

Despite my simplistic approach, I'm also a big believer in testing.  You absolutely, positively have to do it and do it well.  Make sure, beyond any shadow of a doubt, that software works as expected before sharing it with your users.  May I offer a somewhat related experience here?  Granted, my experience consists of first-world problems.  But if you can look past that, you'll see why this relates.

Last week, while I was out of town, the dishwasher began to act up.  At the same, we were having some problems with a back flow regulator for the sprinkling system in our front yard.  My wife called in a plumber for the dishwasher, who assured her he could handle the back flow regulator too.  Killing two birds with one stone seemed pretty efficient, so she went with that.  Said plumber was wrapping off just as I returned home from the trip.

A few hours after the plumber's departure, I fired up the dishwasher.  Didn't work.  Some relatively embarrassing language flew out of my mouth.  And I hunkered down with the assistance of talented son Brian to fix the dishwasher.  Long story made short, Mr. Plumber failed to turn on the water feed to the dishwasher after completing his work.  In addition, Mr. Plumber failed to reset the electronic controls for the dishwasher after interrupting electrical power to the dishwasher (SIDE NOTE:  each and every dishwasher in the US has the service manual in a plastic bag just behind the interior faceplate on the front door...including all the reset codes, of which there are usually three).  The bottom line is that Mr. Plumber did not check his work or conduct any testing after completing his work.

Given the dishwasher fiasco, I immediately became curious about the back flow regulator.  So I walked outside to turn on the watering system.  Sure enough, water shooting straight up into the air.  Mr. Plumber failed to open one of the plug valves in the regulator after completing his work.  Painfully obvious he did not check his work.

After a rather vigorous three-party discussion between my credit card company, Mr. Plumber and me, you can rest assured that Mr. Plumber has not been paid, has lost a customer, and has really bad reviews on social media (including the Better Business Bureau) intended to save others from this experience and chip away at Mr. Plumber's business reputation.

Mr. Plumber expended time and materials, but did not get paid.  In addition, Mr. Plumber lost a customer.  Even worse, Mr. Plumber's reputation has taken serious damage.  Why?  Because Mr. Plumber failed to test.  Don't be like Mr. Plumber.  Make sure your product and/or service (enterprise software) works the way you expect it to work.  Test - make sure it's right.

First Use - Get It Right Or Go Home

First time use is my ultimate go/no-go test for a mobile app.  And I admittedly have a low tolerance for issue or failures:  zero tolerance.

The first time I try a mobile app on my phone I expect it to install quickly, load quickly, be easy for me to use, and work as advertised.  Zero tolerance for speed bumps, poor UI, failure to meet expectations, etc.  I immediately delete any app that fails to meet these standards right off the bat.

I recently tried the Bizzcard iPhone app.  Seemed pretty cool...it only does one thing, which is to send a digital copy of your business card.  The app claims the ability to import a pic of your business card for use.  I tried it:  the image size taken by my iPhone camera is too big for the Bizzcard app.  Gone.  Deleted.  Might be a workaround or a fix.  Don't care.  It didn't may the cut at first use.  Don't have the time or the willpower to fuss with it.

Ditto for Photoshop for the iPhone.  The process for linking my existing Adobe Creative Suite account to the iPhone app was too hard.  Too much manual input.  The mobile app wouldn't accept the login info from the web account.  Gone.  Deleted.  Fail.

I don't think I'm alone in this...the Low Tolerance club membership has been growing over the past few years.  And I don't think it only applies to mobile apps.

I had a recent discussion with a customer who just killed a SaaS project and went back to their legacy ERP applications.  You'll love this.  Their provisioning went well, their partner brought up a conference room pilot in days, and set down the customers team of super users in front of the app.  Question 1:  "How does this work?"  Answer:  "We'll conduct a half-day class to teach you navigation."  The questioner immediately got up and left the meeting without another word...walked by to her office and called the company lawyers:  "Terminate the subscription and partner contract - today.  We're done."  She is VP of Finance.  Her reasoning:  "A four-hour training class on basic navigation tells me the app isn't ready for our culture of zero patience for unnecessary difficulty.  They can come back and try again when they're ready.  In the meantime, we don't have time for that nonsense."  Well-known company, good mid-size SaaS vendor, strong partner.  Gone. Deleted.  Card-carrying member of the Low Tolerance Club.

BTW, this particular story?  Not an isolated incident by any stretch of the imagination.  In today's marketplace, software users have high expectations and low tolerances when it comes to the first use experience.  Get it right and you have a customer; blow it and you're irrevocably out the door...recovery not likely.  

First use...it's the key to customer adoption.  How do you handle it?  Feel free to share with the class if you have something that works...

The Center of Excellence Discussion

Lately, I've had lots of conversations like the following:

"How is the new job?"

"Love it!"

"What is it you're doing?"

"Working in the HCM Cloud Center of Excellence."

"What's that?"

"We help customers have great experiences with HCM Cloud Applications."

"How do you do that?"

"We solve the challenges nobody else can solve."

"So you're a customer support group?"

"More than that.  We also provide tools, white papers and best practices."

"Still sounds like support to me."

"We're more proactive; not just reactive with challenges as they arise, but also anticipating before the challenges arise."

"Oh, so like proactive support?"

"Sigh.  Different from support...as much as I admire the work those people do, this is different.  Let me try again..."

What I do is sometimes a tough thing to put into words.  In fact, I've had trouble wrapping my own brain around what a Center of Excellence does.  There are elements of work typically done by a development organization, a program management office, a customer support organization, a consulting organization, an engineering design organization, an account management organization, and a sales organization...all rolled up into one big ball of wax.

But I think I've worked it out.  Our particular Center of Excellence focuses on the journey of customers subscribing to HCM Cloud applications (i.e., HCM SaaS applications).  Now, before you say "journey of customers...just another swell catch phrase...pure fluff", let me lay it out.

In our Center of Excellence, we focus on the touch points and interactions with customers that come after the point of sale.  That includes working with those customers as they actually configure, use, and get help with our product offering...and in the world of SaaS, that service includes both the software and the services associated with that software.  And doing so requires a pretty wide breadth of expertise:  functional, technical, business process, reporting and BI, UI Design, etc.  We could be trouble-shooting, guiding customers and partners through various features or processes (including the processes involved in working with Oracle).  We can also be involved with strategic, proactive, and reactive challenges.

To boil it all down into it's simplest terms:  we focus on making the post-sale customer journey better for HCM Cloud customers in any way we can.  That's my quick definition of what we do.  And I'm sticking with it until I hear something better...like maybe from you in the comments.

Adopting SaaS

The working model I'm currently using for the SaaS Customer Adoption Lifecycle looks something like this:

Frankly, I saw this somewhere online and played with it for a bit.  Seems to work pretty well, so I'm using it with gratitude to the unrecalled author.

Note that most of the risk in this model appears early in the game.  Also note that there is no recovery path once the customer's SaaS experience goes off the rails.  The lack of any recovery path is one of the reasons why account churn (customers dumping one SaaS vendor for another) is so prevalent


So my thinking is that SaaS vendors should be focusing on making the transition from "Start" (which is really the moment a customer decides to subscribe) to "First Use" (the first use by customer users...not people on the implementation team) as quick and easy as possible.

That's really a critical component for success with SaaS, whether you are a vendor, implementation partner, or customer:  make that path from "Start" to "First Use" in fastest and cheapest manner possible, while still providing users with the best possible overall experience at the time of "First Use."  Fast, inexpensive and high quality...that's a tough balance to strike.  How are you doing it?  Share in the comments.

Pickin' Up The Pieces

Well, there's just a little bit of magic
In the country music we're singin', so let's begin
We're bringin' you back down home where the folks are happy
Sittin' pickin' and grinnin', casually, you and me
We'll pick up the pieces, uh-huh
                       - From Poco's "Pickin' Up The Pieces"

So here we go, kicking off a new blog.  My hope here is to drive discussions exploring the various pieces of enterprise software and how they fit together to complete the enterprise software puzzle.  This blog will be a bit like it's predecessor, ORCLville, but won't be so focused on specific products or platforms.  We'll dealing with issues and ideas across a wider base.


The Enterprise Software puzzle has a pretty wide range when it comes to types of pieces we'll be pickin' up:  applications, Anything_as_a_Service, mobile, business processes, user experience design, practice standards, user acceptance, project management, enterprise industry software observations...all fair game here.

And for those of you who want more Oracle-centric thoughts to chew on, I plan to make regular contributions to the Oracle Fusion HCM Center of Excellence blog...much like what we all used to discuss on ORCLville.

OK, enough of the introduction.  Time to write something somebody will care enough to read...and maybe even comment about.  You'll get the idea as things evolve.