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.

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.

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.

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.

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...