Menu

Customer Success

Many of the activities I have pursued in my life were conducted in this spirit. I’ve tried to capture them as portfolio projects. Some were not successful per se but the learning in every case was. Which I then took on to my next project.

Success Hacking can be applied to any pursuit. It can be organisationally or business focused. Or you can apply it at an individual level too as I do – my Dharma Hacker post post explains this. As Herbert Otto said,

“Change and growth take place when a person has risked himself and dares to become involved with experimenting with his own life.”

From an organisational and business point of view, the world around us has become very complex and is constantly in flux. The only constant is change and the only certainty is uncertainty.

Data is in abundance. In itself, it is only a contributor to complexity. Deriving meaning from it though purposeful experiments is where opportunity lies. These days, as software eats the world, the opportunity to build applications, services and experiences lie everywhere. So too the possibility to collect and understand the data behind them.

The success hacker learns by doing and observing outcomes (and reading the data “tea leaves”), progressing quickly with what works, discarding what doesn’t. They don’t believe in elaborate plans, seeing experimentation as the new planning.

The success hacker is the chief experimenter, sensemaker and intrapreneur in your organisation. Nurture them.

Organisations can and should attend to some basic needs but to succeed going forward they need to become engines of possibility. Creativity and innovation are excellent aspirations for the modern organisation to actualise around. Also for the Success Hacker. In other words, the outcomes we strive for should aim to create new possibilities, new innovations. More on that here: The Modern Organisation’s Hierarchy of Needs.

An obvious outlet for this type of approach is in my professional role as a customer success manager. Indeed they are deeply intertwined. I’m writing about Customer Success in a new eBook / trend report on this site: https://successteam.co

You will probably see this approach in everything I do but as linked to earlier, particularly in my portfolio projects.

Like this:

I attended Pulse 2017 in San Francisco a few weeks back, a three day event run by Gainsight, a vendor selling customer success software. A massive event for this nascent industry with over 4000 attendees. Gainsight is gaining traction and on the first day of the event they announced a new round of investment at $52M. The article explains how you could see Gainsight as a bellwether for the industry and also the practice to some degree.

My first day I joined the entire customer success team from my company Percolate in a training session that lasted a day. The entire trip was spent with the team and that was such an amazing part of the experience and highly recommended. On the 4th day we spent half a day in a team offsite and part of it was dedicated to bringing the learnings from Pulse into our organisation. Several projects have been spun off as a result so very worthwhile on so many levels, not least a great bonding opportunity – cue team selfie :)

The training was run by Success Hacker, a customer success training, recruiting and service consultancy. The theme for the training was Predictable Success = Predictable Revenue which I thought was pretty representative of the conference as a whole actually.

The training was intended to be a level-set for our team as well as all the attendees, to get us all on the same page. It was basic in nature, introductory level stuff. I understand why they took this approach but having been practicing customer success for at least 5 years this was rather too basic for me and many of my colleagues.

There were several trends or themes covered at the conference which I synthesise below but first let me recap on some of the best and new learning from the training (I skipped the non interesting/useful stuff). This may take a while so go grab something hot and steamy :)

Training Day

Success planning

A road trip analogy was used to intro this – the customer is the driver the CSM is the navigator – I liked that. Success planning was deemed mostly relevant for larger accounts – it’s not scalable for smaller accounts. There was talk of automating this but no real insights how. I had an idea that survey type forms could be useful for getting customer input – a good way to scale.

Challenges to success planning are typically that there is not enough time, info or value (seen in the planning) for it. Benefits and best practice are that it makes you proactive and it is best when plans are shared with customers (I would say co-created) and are kept updated.

They went through a very simplistic overview of what it contains starting with an exec summary. That was probably the most useful piece of advice. Instead though I would offer up the use of a Success Canvas – check mine out (pdf).

Metrics

We went through the meanings of some standard SaaS metric acronyms. They touched on business metrics that often went beyond customer success. This was inane. Any number of the excellent posts on a standard Google search would have done better. This was a total waste of time.

Just a few metrics or measures of performance very specific to customer success worth pointing out were:

Building a customer centric view in your org

That should probably have read “building a customer success centric view” because that’s where most of the work is required. Customer centricity is old hat (though still far from well served), customer success and its unique role in SaaS companies isn’t. Building a good undestanding of the role and its contribution to overall company success is key and something I have struggled with before. This actually stood out as a common theme and challenge at the conference. But on to what we covered – some useful nuggets there (with some creative interepretation by me):

Avoid inside out thinking. Think first and always from the customer’s perspectives not your internal processes and approaches.

Avoid solving for the average customer. Try and think in segments at least. Scale can be a challenge here.

Prospect preference. Avoid developing features for new customers ahead of existing.

Shiny thing syndrome. Think impact, not feature / function.

The solution isn’t a process its a mindset and needs to become habit.

Invite customers into “virtual” decision making – “What would the customer think” about an internal decision. “How would this impact the customer?”

How to change things:

Invite teams to customer visits

Invite customers to your office for lunch and learn sessions. I would go much further and suggest customer meetups which I have written about and worked on setting up at Percolate and they are now taking off.

Invite customers to internal all hands sessions to talk to all employees

Collect and share customer success stories. We have an awesome database built and maintained by our customer marketing team at Percolate.

Applying a consultative approach with customers

There’s consultative selling so why not consultative customer success. I like the thinking. Here’s the upshot.

Two types of approaches:

Boiler man – fixed, package solutions. Less time consuming and open ended and more scalable.

Wing man – help guide customers to the right solutions. A more custom and suitable fit to customer need but more intensive.

Try solve biggest the problems not the easiest.

Focus on selling a solution, not just a feature.

Key skills

Storytelling – effective way to convey by example.

Active listening – improves mutual understanding.

Strategies to manage accounts

Help your customers support their customers better – think of the end customer. Cannot stress this often overlooked approach enough.

Make your customer contacts look good in front of their superiors. Another sure fire way to ingrain yourself in the business through key stakeholders.

The converse of this last point and this is my view not covered in training, is that you shouldn’t get single threaded in case that person leaves. So always broaden your stakeholder base beyond one.

Create internal subject matter experts and champions on your solution. Take a train the trainer approach – make them super users. I wrote about this here: Building user success managers.

Always try and set beatable expectations – like Amazon deliveries. Great idea and benchmark.

Keep up with whats happening in their industry and organisation – Google alerts.

Become a trusted advisor and act like a partner and not a vendor. What’s needed:

Domain knowledge (their domain)

Customer knowledge (organisational) – annual report a good source

Product expertise

Business acumen

Change management

This wasn’t separated out, I have here and felt it should have been in the training. It was glossed over. Although I emphasise innovation strategy over change (Innovation is the why, change is the how), at the very least successful technology adoption needs some change management element. Main take outs were:

Training is not enough. Nor is marketing and comms.

Internal leaders and stakeholders at a customer organisation need to be involved.

The best presentations that shone a light on the state of the industry

I saw some excellent, top quality presentations. Some I missed and since there were parallel tracks that was inevitable. Thankfully they have made every presentation and the audio from it available here. I need to go back over some of them but below are the take outs from me from the best I attended.

Top trends from past Pulse Conferences: 2015-2017

Before I go into my views though I should point out the trends the CEO of Gainsight (Nick Mehta) shared based on running the last 3 years of Pulse conferences (2015 – 2017). I’ve combined them conveniently side by side above but slides are here and audio here for more. Trends from 2017 are pasted below with a small comment from me.

Partner With IT. I tend to agree with this whereas once I would have said, whatever it takes to embed yourself in the business do it, including ignoring IT. But I’ve learned you can get much further partnering with them.

Extend To The Real World. This has a lot to do with the Internet of Things and customer success moving out of its traditional home in SaaS companies where they become custodians of the entire customer experience. This HBR article co-authored by Michael Porter, one of the world’s foremost experts on strategy and competition, covers it well How Smart, Connected Products Are Transforming Companies (see section covering customer success).

Scale Through Your Partners. I observed first hand how Microsoft, who already has a formidable partner network, tried to embed customer success and technology adoption through its partner network. Its a massive challenge for such a large organisation and network but they have serious intent and I’ve seen it work well with some early stage successes. Cisco was also held up as an example of this approach.

Invest In Your Community. A point was made by Nick Mehta that part of the funding they had just recived was going to be about building the community. He mentioned expanding on their PulseLocal efforts which they started on way back in 2014. I’m looking forward to joining their London chapter. I also see this as a focus area for specific company CS efforts – building a community of customers, partners and employees starting with customer meetups as I covered under point 2.

McKinsey’s Customer Success Benchmark study – main findings

This was a lunch and learn session where two of the study’s main authors went through their main findings. Definitely one of the highlights for me. The fact that McKinsey is putting so much effort into this says a lot in itself. Slides here and audio here. My take aways as follows:

Value of Customer Success is realised far better with an integrated approach, not in isolation (slide 3 – see above). That is, part of a broader customer experience journey and aligned with full business strategy, not just as a “go to market” strategy.

When setting KPI’s pick the right metric (churn, NPS, etc.) then the parts of the journey that are key to drive impact. Churn is the most prevalent KPI.

Most organizations do not allow enough time for real results. I’ve seen this time and again – many are too eager for results, too early on. True success takes time.

CS needs to have a seat at the product table and play a quarterback role. The CS and product teams presentation I cover further down expands on this.

Onboarding and product experience are by far the most important journeys, yet product teams are rarely involved in driving customer experience / customer success.

Centralised governance from the top down is key. Centralized accountability and governance drives a big lift in value according to respondents. A single “integrating leader” to track and manage end-to-end is required.

Guided journeys automated throughout the journey lead to insights for success plans

People are still key for success despite digital automation. Automation is definitely an important element going forward (see Hubspot presentation) but customer success is still predominantly about people and relationships.

Adobe – fostering a culture of innovation through customer success

This was one of the first presentations from organisations adopting customer success practices successfully (slides here and audio here). These are always best in my view. Just as with customer success, examples of success are the best way of learning from and perpetuating further success. Adobe was the first I saw but I’ve included the best from the others. Their key points:

Lots of experimentation – try something see if it works. You should make space for this and invest in it. Love this and my success planning approach is all about experimentation.

Best CS teams focus on specific and different aspects of customer lifecycle (team broken up into specialisms). Also don’t ask a non technical CSM to emphasise product, for example. Or no sales skill but needs to renew.

Ok to lose customers if you understand why – not if you don’t.

Fastrack at Microsoft Office 365

I worked at Microsoft on this approach with Mike Grafham who presented and has his own take of main learnings from Pulse 2017. So I had to attend this session to see how things had progressed since leaving Microsoft (slides here and audio here). I wasn’t dissapointed :) The main thing is that the focus on scale with such a large customer base continues to be the driver of activities.

What stood out for me was the approach to qualifying customers before they come into the CS pipeline. It’s the first lesson he shared – slide 3. I love this approach and funnel which again borrows from another discipline – the best sales practices.

Bessemer Ventures – state of the cloud (customer success edition)

This was a solid session on the overall state of the cloud (slides here and audio here). The relevant part started with the startling statistic linking improvement in churn with an increase in company valuation.

They also pointed out that of the multiple ways to be successful, upselling existing customers is the major driver.

Scaling Success Through Layered Communication – HubSpot

Essentially this presentation was about automation, a major theme of several presentations. This one by Derek Roberts, Director, Services Strategy and Operations at HubSpot was one of my favourite of all. Slides here and audio here. Highlights as follows:

One of the main thrusts of their view is that they see the customer application as an active participant in Customer Success. I couldn’t agree more – customer success should happen as much in app as it does outside, by and through people. So much can be automated and scaled this way as the user interacts with the product and in this context, is where CS activities are most powerful.

He showed such good examples of some of the simple ways in which they are automating activities. For example, they send data on usage via email – triggers to the right people for low or high usage. This can encourage further use.

Scaling happens at the process level. It’s so important to map your processes, dare I say customer journey map, and understand where you have an opportunity to automate and make life easier for yout CSM’s and customers alike. At the same time you can boost key outcomes. Below is a chart showing how Hubspot break it down.

Working with Your Product Team to Drive User Success

Becky Banasik of TrendKite, Katie Leighton and Nicole Salzman of Box were part of a panel discussion moderated by Todd Olson of Pendo. No slides but audio here and my notes below. In essence, cooperation between product and CS teams was seen as critical to customer success. Since I believe CS teams are the window to product for customers and vice versa, this was heartening.

I love that Box have built a tool to get customer success feedback to product teams. Before a feature is built, CS and sales are asked if they think customers would value it.

At TrendKite features are evaluated on the basis of potential impact on usage, revenue and retention. CS own NPS scores but account managers are responsible for outreach.

At Box product and CS teams both co-own NPS scores. No compensation is tied to NPS at Box but it is at TrendKite.

Based on product usage trends, both spoke about how triggers are sent to CS teams, e.g. when usage drops off or spikes in a specific area. This links to play books for CS to respond to customers. This tied in with what HubSpot does.

At Box, CS and product teams work on new feature releases to come up with a common strategy and comms to set up the release for success.

The panel chair asked whether either involved product teams in onboarding sessions to learn from the user experience. Neither Box or TrendKite do but great idea I thought.

How high trajectory startups manage CS

A panel session chaired by Jason Lemkin of SaaStr involved the founders of several startups: Sarah Nahm of Lever; Michelle Zatlyn of Cloudflare and Jennifer Tejada of PagerDuty. No slides but audio here.

NPS and retention rates are key measures they all used and NPS covered product, brand and company measures.

Use of industry benchmarks was made to judge success, not just improvements over time.

The whole company owns NPS but CS is seen as the cheerleader.

CSAT (customer satisfaction) was also used at Lever. And they try and give various team members (not just CS) specific targets that are actionable.

Role of marketing in CS was discussed. CSM’s feedback customer messaging to marketing to use in campaigns instead of generic and bland marketing messages. Head of customer marketing should sit within the CS org and a budget should go to it from marketing.

Phew, finally done. If you managed to get this far down I’d love to hear your thoughts in a comment.

I’m adding a few words to some of the headers in the diagram although I think they are pretty self explanatory.

If you think I got anything wrong or missed anything let me know in a comment. I’m doing this because I think it will be useful in the work I am doing for the company I currently work for, as well as the startups I mentor.

NOTE: This is generally applicable to a technology company in service of its customers. And while we can show the path to them (the customer), we cannot walk it for them. As I wrote in this post, you cannot outsource success.

1. Tracking progress

By this I mean progress against the strategy and execution plan. It will generally cover things like whether actions planned have been carried out. It typically happens in periodic sessions, like monthly and/or quarterly reviews.

2. Issue Escalation

A customer success manager (CSM) is not a support manager and a robust support service and team should be in place for that. When things are not resolved for the customer through this path, the customer can escalate to the CSM.

3. Product Development

Again, the CSM is not a product manager but provides a window to them for the customer and vice versa. The purpose is to take ideas and thinking for what the ideal product should be to either party. Things like product roadmap, new feature requests, etc. are covered.

5. Usage/adoption

This is really about one of the most important metrics to the CSM. Having a view on whether users are using the system and where (which features) as well as over time, is critical. Providing dashboards that provide these views is critical. If you can track success activities against usage (i.e. what activities you plan with the customer and how these impact on usage), then you have discovered the holy grail. If you can track against other parameters like value and satisfaction, so much the better.

6. Value

Maybe this is more important than usage. Although you have to have usage first before you can get to value since only when a platform is adopted and being used can you drive value. The fundamental point of everything a CSM does is geared towards driving and showing the value a technology provides in relation to investment or effort. This is arguably the hardest part of the CSM’s role.

7. Experience/satisfaction

One leads to the other. The CSM is not entirely responsible for either because experience for instance is made up of many factors outside of his or her control. The product plays a big part for instance. Other departments that touch the customer, starting with sales. And many other factors. But the CSM could be seen as the custodian of experience. If positive it leads to high satisfaction levels. This should be measured. Net Promoter Score is a popular means used by many but there are other ways.

8. Renewal

Also arguably one of the major outcomes a CSM is expected to influence, if not be responsible for. Making sure the customer is deriving value from their technology investment and satisfied with their experience leads them to renew their subscription when it comes time to. That is, as opposed to allowing it to lapse, or churn as it is known in the industry.

9. Expansion

I would argue that this is more important and possibly indicative of the highest satisfaction levels. If a customer is not only renewing their subscription but buying and spending more with a vendor, does this not mean that they are delighted with the product and service? This perhaps is the zenith of a CSM’s successful effort in his or her role :)

Like this:

One of a customer success managers (CSM) main tasks with customers he or she works with is to build user success managers (USM).

It’s not unlike the famous Intel Inside campaign that targeted end users of a technology component (microprocessors) through promotion of the PC in which it was used.

The hero was the PC. Sales of personal computers dramatically shifted to Intel-based PC’s after the campaign started.

The fact is Intel spent a lot of marketing dollars on behalf of the OEM’s (Original Equipment Manufacturers) that were the buyers of their components. Intel were competing with cheaper processor manufacturers. Intel benefited hugely because sales of their microprocessors shot through the roof.

I’ll stop the analogy for now but being an ex marketer and adman and in the marketing technology business at the moment, that was a fun excercise :)

A customer success managers first focus – the user success manager

This typically means the admin or project manager in the customer’s organisation. They have primary responsibility for the technology platform.

Sometimes it is just one person and they are not dedicated to the job full time. In complex organisations and with complex technologies you are lucky to have a full time team.

It’s important that these members are enabled and empowered to deliver successful outcomes to the organisation through users.

They should be educated. They should have resources and a network they can scale their efforts through – like a champions/advocate network. More on that later.

Resources should take the form of templates, documentation, training programs and generic succes stories they can take to the user community to drive usage and adoption.

Also hugely important is that the USM has insight into usage and adoption data. So either directly or via the CSM, there should be access to dashboards showing daily and monthly usage, by feature set, etc.

Ultimately, the CSM should turn the USM into a close approximation of his or her role. That would be deemed a major success.

The USM’s focus should be the end user. Of course they will have other key stakeholders to consider and prioritise but the end user community is one of the most important.

A customer success managers second focus – the user community

Never forget that the end users are the final arbiters of success. They are the ones that will adopt a platform and use it to drive value creation for the organsiation. Or not. They will have lots of competing priorities and technologies so it is a battle for their attention.

Mandating a platform or technology might go some way to ensuring end user adoption but its never a guarantee and should never be your only strategy.

While a USM is getting up to speed it might make sense for the CSM to focus on the end user. But this is temporary as the goal should always be to bring the USM up to speed as quickly as possible to do the job themselves.

It’s not scalable for a CSM to be spreading his or her focus too widely considering they are probably managing many customers in parallel.

Related to scale, this brings me again to a point about champions or advocates and they are so important, they deserve their own section.

Champions and how to scale success

Click to enlarge

The above explainer is from various programs I’ve helped to run at companies and combines the why, what and how of champion programs.

These are also sometimes referred to as advocate programs although this is often customer marketing terminology. In this case they are user and platform champions or advocates. I’ll keep it simple and refer to them as champions.

The first point in bold under why explains their core benefit around scale.

And just as a CSM is trying to create and scale his or her efforts by identifying and working with USM’s (a form of champion), so too should the latter.

The USM should try and identify champions as early as possible. The explainer provides some guidelines for doing that and more.

I am writing my next trend report on a related subject (post on that here) but am deeply embedded in the here and now. I work with some of the worlds largest companies and have been for many years trying to help them make sense of and drive value from their technology investments.

I am constantly thinking about technology in the here and now in making mine and my customer’s work world better? One thing I come across time and again is the misalignment of focus and priorities.

The technology and increasingly the data around its use is held in thrall. I’m not innocent of the many mistakes made. Here are some examples below of the kinds of ways in which I think we go wrong:

Growth in usage data is also driven without giving thought to the outcomes or value being attained

Technology is prioritised without giving thought to the humans and the behaviours around it – mindset, culture, etc.

I believe usable and useful technology that solves real problems is critical for driving adoption and deriving business value, especially in the more complex world of enterpise technology. But I believe you can get further when you address the mindset behind technology use and I am far from alone in this view. Ultimately tackling both in healthy doses is best.

A call to arms!

In addressing human factors, when it is done at all, are still often wrong. Organisations typically address it from a change management perspective. It’s become an industry in its own right.

Call me a cynic but most change management efforts I’ve been involved in or observed have often seemed shrewdly calculated to meet the ends of a chosen few. Not the user or a better way of working.

Often it’s simple humanity that is missing.

In the enterprise technology business we sometimes miss what I think Steve Jobs alluded to when he said “technology alone is not enough”.

To quote him in full he said:

“It is in Apple’s DNA that technology alone is not enough—it’s technology married with liberal arts, married with the humanities, that yields us the results that make our heart sing.”

As robots and super intelligence increasingly play a greater role I want to avoid becoming one (a robot :).

I want to celebrate my humanity and the difference I can bring. This goes beyond what Steve Jobs was referring to. I’m thinking of a real caring and nurturing that is authentic and deeply rooted in our collective wellbeing.

I see our innate creativity as an essential human expression of being, hence the subject of my new trend report.

Creativity is what drives us. It’s essential to all progress. Sometimes at the expense of what we leave behind (read disruption). We are always on the march to creating new possibilities. It’s the way we grow.

I want to embrace new technology because I’m a tech geek and I trust my techno lust but I still want my heart to sing.

There is thrill to be found in technology that works and enhances my productivity and the way I live my life. This is momentary though. It does not penetrate the deepest recesses of my being.

It is in the way that I am empowered as a fully alive human being, constantly evolving, that makes my heart sing.

Most of all it is when I create something of value and it is appreciated, in even a small way, that my spirits rise. Progress and all of humanity is founded on the principle of creation. Of ideas and new possibilities and setting out on adventures to achieve them.

Organisations can play a big part in nurturing this. Here leaders have the greatest responsibility. They can choose to nurture our humanity and provide the freedom for our greatest creative expression and output. Failing that organisations and people will wither I believe and die soulless or go off and find it elsewhere.

I’ve written a lot about ways to scale success efforts but the best is always face to face. Events like customer meetups are a perfect way to bring customers together. I’m running these in EMEA for the company I work for currently. The context is enterprise technology. This is what I’ve learned so far and I’ll update this post as I go along.

The ideal conversation at a customer meetup would be to discuss shared successes. We all know those are hardly going to be the only outcomes. Discussing failures and how to overcome challenges are also good topics.

Meetups in the context of customer success should not only be about technology. They can also be a means to building relationships with your strategic customers. They should build your customer advocacy base too. It is a rich means to nurturing customer advocates and a customer community.

Aspects outside technology can also be topics for exploration. How something like organisational culture impacts on technology adoption. How a well designed approach can aid your technology adoption efforts.

Yet you should also use customer meetups for your product team to meet customers. The purpose here would be to share insights about whats coming in the product roadmap. Customers also have the chance to provide nuanced feedback on what they want and need.

Above all, meetups should be learning environments. Settings where people can come together to share expertise and learning. They should also encourage new and different thinking. At best they bring people, tools and techniques together. They drive openness and foster creativity to help solve problems.

The ideal customer attendee is the advocate. They have an interest and passion for your product and the industry in which operates. They have deep knowledge and the willingness to share it. If they don’t have these attributes, the customer meetup is the forum to nurture them in.

From the vendor side (customer meetups are most often run by the vendor) there are ideal attendees too. Those passionate about making customers succesful are obvious choices. So bring the customer success team into the meetup. Product teams are the other obvious choice. Product managers and even hard core software engineers should attend.

If you can have senior executives attend, that is ideal too. It shows how serious you are about customers and the meetup format.

Don’t get sidetracked or become unfocused. The meetup is always about the customer and their needs. Its never about your cool product or your clever founders or your awesome people. They will shine through anyway if you make the customer shine first.

What to avoid

There is sometimes debate about inviting prospects. Some would treat the customer meetup like a demand generation event. To make it more impactful. They would have marketing more involved to drive attendance. Sales people involved to have customers convince prospects to buy. Don’t let them do it.

Strategic prospects that are well advanced in opportunity stage could attend. Screen them first. Make sure they have the right intent. Are they genuine in their passion and intent to learn or do they want to verify a decision. If the latter, there are better ways of doing that. Like a reference call.

Sales focused events are different. Attendees of these events know hard selling is a primary motive. You can market the crap out of those you attend or sponsor :)

Who owns and leads customer meetups also comes up. Customer success teams should in my view, not marketing. They are close to the customer and know their environment. The meetup can also be a forum to forge closer ties as well as drive further customer success work.

Which does not mean there is no place for marketing. They can help promote as well as scale efforts.

But if customers think the meetup is a vehicle for marketing or sales, you lose their trust. The potential to build a community of customer advocates is no longer there.

The ultimate goal of a series of customer meetups is to build a community of advocates. If that drives loyalty in your company and product as it should, that is a beautiful thing.

The Ideal Meetup Venue

Guidelines for a successful meetup

Location. Make the location as accesible to the majority of your customers as possible. This means transport links as well as general accesibility. If it means taking your event to the customers location, do it, e.g. a roadshow.

Venue. This is the more important factor and you should not underestimate it. A well lit, expansive yet informal and cozy environment is ideal. You want to inspire creativity and encourage openness. It would be better if the location was away from your regular work space unless you have an amazing space. Doing it away from a regular work space helps take your mind away from business as usual. These days in any major city, there are a plethora of options. And services like Breather can help.

Numbers. If possible keep it down to a manageable number. This depends a little on the size of the venue (don’t cramp people). But it’s more about interactions. Too many people and conversations will not be cohesive in the managed part of your agenda. Fifteen is ideal, twenty is manageable.

Time and frequency. Time of day is the first consideration. The options are early morning or evening. Morning is likely to eat into work time whereas the latter into personal time. Each has merits and challenges. You can experiment between meetups. I tend to choose mornings from 08.30 – 10.30. Two hours is a good duration and does not take too much work time out of the day. Quarterly is a good frequency.

Cost. This should not cost the earth. If you are fortunate to have a large budget you can go wild but it is not needed. Location hire and refreshments will be the main costs. I have catered for the finest coffees and a mix of pastries and healthy alternatives before. This included a personal barista with her own coffee machine – the real deal. We chose to emphasise coffee (tea was a side option) because of its history in London. Workshop Coffee was the supplier. Venue (see pic for example), breakfast, coffees and teas all came in at £700.

List. You need to manage a list and track attendance over time. There are so many tool alternatives I’m not even going to go into them. Most important is that it is shareable so you can get others involved to see who is attending or has in the past. This will aid further promotion. It’s also useful if the main organiser leaves or cannot manage a certain event.

Promotion and communication. You shouldn’t go overboard. If you have a history of meetups to draw from so much the better. You can explain previous events and successes. When starting out make clear the purpose of the meetup and set the tone. Consider your ideal audience and craft your message with them in mind. They can be executives, technical or business users. You could get fancy with a email marketing tool but it’s not necessary. Key is to be brief and impactful so you get a response.
I would start 2 months ahead of the event and target 3 follow-up mails after the initial mail. Follow-ups can provide more info and remind potential attendees to sign up. You can also encourage sharing with colleagues. Use of social media depends on how broad and public you want to make the event. I favour a managed attendance approach in private (not public and free for all). Social can, if you have the permission, be a good way of sharing activities on the day. That way you promote your brand and further attendance down the line.

Managing signups. I currently use Splash. It’s a landing page tool and then some. The obvious alternatives are Meetup and Eventbrite and there are many others too. Key is to have a branded and customisable means to attract and manage RSVP’s.

Agenda and facilitation. The agenda should be as light as possible and not be too overbearing. Start with time and space for attendees to connect and converse. They would do this while filling up with refreshments and food. I’d give this at least half an hour and it provides time for late arrivals. You could then have a brief intro for ten minutes covering the agenda. The core part of the meetup could impose a structure beforehand. Or attendees could determine the agenda on the day, like an unconference. Make it an interesting mix.
Remember the customer is the hero and his or her information needs are paramount. I find customers speaking is both demanded and more effective. If you mix that part with internal speakers, emphasise customer speakers. Give them more time. Have more than one speak. You could cover this in an hour and have three speakers talk for five minutes each. You could then open the floor to Q&A for ten minutes. Extra time is buffer. Company representatives can then have time to talk.
Cover subjects the customers should know about or have an interest in. End with a close recapping the sessions main outcomes or topics concluded on. You can also try and get input for the next event. You can have a combination of MC or facilitator/s. The former should not dominate and manage intro’s, time and the agenda. The MC could also play role of facilitator or if you have break out sessions you may need a few. Facilitators are only needed if you want to drive clear outcomes. I would be judicious in my use of this approach for customer meetups. These are more relevant for workshops.

Speakers. This depends on your approach and does not need to happen at every event. Speakers could be a mix of internal or customer speakers as mentioned. The thing about speaking though is that you make it conversational. Try and avoid imposing the use of slides if you can. They can play a role and are necessary if you needs to demo products or examples. It is far better for speakers to engage in two way dialogue.

Follow-up. One email to thank attendees will generally do. I add a survey to my mail. This is useful to get feedback from the event to determine its success. You can also get input for your next event and as a way to identify topics to cover. Attendees can also suggest areas for improvement. If you do carry out a survey you could follow-up one more time with the results of the survey. Make clear what actions you will take as a result.

Connection between events. This is not for everyone. What I am referring to is a community or collaboration tool. Attendees can connect and carry on discussions between meetups. You can also discuss and agree topics before an event. This will need effort on your part – community management effort. You also need to think about the tool. It could be a public tool like LinkedIn, Facebook or G+ (which you can make private). Or it can be part of your online success portal which is what I recommend. Use this to enhance conversations and solidify your community.

I’ll keep updating this post with my learning. If I find good articles covering the same topic I’ll also add them. If you have any input please add a comment. I’ll add the best stuff to the post.

Like this:

Just a quick doodle to capture this thought I had and a note to accompany it.

Customer Success is the business I’m in. That is, the task of ensuring the customer of my technology platform (mostly this is what it concerns) is successful in the use of the platform.

We both have an interest in being successful but often come at it from different sides. So I plotted it on a graph.

We both have an interest in all of the elements, it’s just the focus that’s slightly different.

The vendor wants to drive usage and adoption. Adoption means the users are using the tool. If they are not satisfied with it they won’t use it. If they are not using it, come renewal time the customer won’t renew.

The customer wants to be happy that the product does what he or she wants it to do and gets the results targeted. NPS stands for Net Promoter Score in case you weren’t sure. It’s a good proxy for happiness :)

Like this:

Features and functions are easy to obsess over. They are tangible. You can click a button and it does something. Or not, at least not what you expect. And you can obsess about why not and what it should be doing.

I’ve been included in countless enterprise technology adoption programs and find this the most focused on area. This and plans. Plans are also easy to obsess over. You can move dates, tasks, people responsible, etc. Again this is a tangible area of activity, or seemingly so.

In my view the feature and function work and also the planning work is shallow work. Which is not to say it’s unnecessary. It must be done and is critical for success. But it plays a small part. Currently the majority of the effort sits here and accounts for a small part of success in my humble opinion. It should be the other way round.

Deep work is the human behaviour work. Thinking how to change it. The strategic work that takes you out of the shallows and the weeds. The creative, imaginative work that forces you to think about where you are going.

Its easy to see why the feature, function and plan work is the work that dominates. You can easily avoid confrontation on difficult people work when there is a plethora of functions to play with or talk about. You can spend endless hours discussing why something does or doesn’t do something or even playing with it.

Questioning why you are doing something that may not be working or taking responsibility and hard decisions for needed changes. Understanding misalignment to a broader purpose. This is impossible when your head is stuck in the nuts and bolts of features and functions.

Make specific time for the deep work, even put some rules in place so that you cannot digress into feature, function and planning work until it’s time to.

Show the trap. Paint a picture of it and share why you need to avoid it. If people are aware of behaviours and activities that are not leading to productive outcomes in the context of the bigger picture, they can avoid them.

Stop and reflect on where you are and what is important from time to time. It will allow you to see the wood from the trees. You could start meetings by reminding everyone of the purpose of your overall work and what to prioritise.

Be outcomes focused instead of things focused. Always think about what the result of something is and this will help you talk less about features/functions. This also requires a healthy focus on measurement and being data driven.

Like this:

The Lean Startup isn’t just about how to create a more successful entrepreneurial business. It’s about what we can learn from those businesses to improve virtually everything we do. I imagine Lean Startup principles applied to government programs, to healthcare, and to solving the world’s great problems. It’s ultimately an answer to the question ‘How can we learn more quickly what works, and discard what doesn’t?

What Tim O’Reilly, CEO O’Reilly Media, said above pretty much sums up what I am trying to do here: apply the methodology to a great challenge I face daily in my role in customer success – successful enterprise technology adoption. To find out more about the core methodology you can head on over to www.leanstartup.com.

The methodology has been highly successful in its application with startups but far more broadly now too as Tim O’Reilly suggests. I’ve been thinking about it a while and captured how I wanted to apply it very briefly and simply in a customer success management primer I put together on SlideShare. I’ve added the relevant bit as a diagram above.

It’s not unlike what the co-founder of Percolate where I currently work has suggested in this article: Noah Brier’s Three Rules For Leveraging New Technologies. There’s no specific reference to the lean startup methodology but you should see the similarities and they are based on the lean startup methodology’s heavy reliance on software engineering approaches which Noah Brier does reference.

I’ve been applying the approach loosely with the customer success planning and execution work I have been doing with customers and now felt it time to capture that in a little more detail. That is what this post is about. It’s also in the context of my most recent work which is marketing, as in Noah Brier’s post, but I believe it can be applied widely for most enterprise technology platforms. It also chimes with earlier thinking I’ve done which seemed to resonate at the time: Why leaders of digital initiatives inside organisations need to think like start-ups.

Contrasting approaches between enterprise technology then and now

This approach I am taking is in direct contrast to previous approaches to technology adoption. Enterprise technology platforms used to be highly configurable and customisable and were often planned and prepared for launch far in advance of launch dates. They would exist in this form for years afterwards until a new version was ready for re-launch. This was tied in, to a large degree, to a vendor’s approach who would plan new features and functions years in advance before releasing a new version. Now with SaaS (Software as a Service) that has all changed.

Customers no longer get to change the platform to the degree they used to and vendors have vastly reduced development cycles to ship new features more frequently, sometimes as often as weekly. However, most often these are tested with a handful of BETA customers and then shipped when ready on a quarterly basis.

With new features coming this frequently and with the lack of customisation and configurability, it doesn’t make sense to plan too far in advance. A far more iterative and experimental approach is called for.

The model in summary

This approach supports customer and end user success with the use of their enterprise technology platform. So those chiefly responsible for the platform’s success as well the users of it. It combines what has worked well with many global customers in my experience and incorporates lean startup methodology. It’s based on the view that success cannot be achieved by chance but needs a good design which is measurable, executable and iterative.

It targets key outcomes including measures of success (KPI’s), plans the necessary activities and resources required to succeed and reviews progress periodically that allows for course correction or continuation of successful activities. I simplified the steps from the Lean Startup methodology for my purposes to three.

Note that this model is narrowly focused on planning and execution activities and does not take into consideration some critical supporting activities. Things like a champion network, an online support environment, etc. I’ve written about all of these to some degree or other under the customer-success tag so follow the link to find out more.

Where the cycle starts in relation to implementation/onboarding

Generally there is a phase of work prior to the success management cycle starting that includes getting the platform ready for launch. This would include things like configuration of the system, setting up workflows and permissions/ roles, access and security settings, provisioning of users, etc. These technology, governance, authentication, legal, support and security considerations have to be mapped out and delivered in accordance with the organisations policies, most often managed through IT. This would ideally be followed by a successful launch of the platform which I’ve written about here: Launch like a boss – bringing consumer startup practice to your enterprise technology platform

The success management cycle would ideally have been been planned ahead of launch as part of the implementation planning, e.g. the initial uses cases and workflows you launch with form part of a longer term success vision and planning cycle.

In some cases, a customer will have launched and have been using the platform for many months, even years, without a robust success methodology in place. In this case you would have to take stock of where successful (or not) platform usage is and work from there. It may require a platform relaunch. At best, there are some successful uses of the system in place already and you want to take these to the next level.

Envision

Set vision, objectives and broad measures of success
On overarching vision is a good thing. Some of the best work I’ve seen done articulating the work needed here is in this article: Strategic Communication: How to Develop Strategic Messaging and Positioning. This drives the overall program of activities and provides focus for the use cases that will deliver against the vision and objectives. Generally I would suggest planning in yearly cycles as this will be made up of 4 quarters of iterating use case delivery.

Identify and plan use casesEnterprise technology adoption – Use cases are the currency of success – go to this post I wrote to find out more about uses cases. As mentioned above a set of uses cases should be iterated for at least three months of active use – this is probably the minimum amount of time needed to properly use and test use against set outcomes. These uses cases should broadly align with the vision and high level objectives you have set for the year.

Stakeholder engagement and delivery /change programThis is essentially the execution plan. It should at least incorporate time, task and responsibility elements that you can tick off as you go along. Many of the supporting elements that I cover in my primer referred to earlier should also be considered: a champion program, training, a governance model involving main stakeholders, etc. I’d also call out a collaborative community and online support elements in particular – covered in a post here: Scaling your customer success efforts online – a guide.

Execute

Launch platform and use cases
I’ve already linked to the post I wrote about the importance of launching well – see further up this post.

Governance / monitoring
Ongoing monitoring, especially in the early stages, should include key stakeholders and regular check-ins. You could set up a steering committee and meet monthly for instance. If the platform was critical to your business, why wouldn’t you do something like this and have the most senior of stakeholders involved.

Champion check-in
This is called out specifically because champions are crucial to success. Champions help to reduce the strain on the resources of the core project team and help drive engagement throughout the community, especially in early stages.

Ensure ongoing support through dedicated channels
The article mentioned under point three in the Envision section covers what I am referring to here.

Gather data
You should have set the key metrics you want to measure as well as how you are going to measure them in the use case definition phase. Don’t leave it as an afterthought and whether its qualitative or quantitative, gathered through survey responses or as output of system use, collect data as you go.

Evaluate

Evaluate progress holistically against vision, objectives
Check points could occur monthly, even weekly in the early stages, but at the very least should be quarterly. Whenever you check in though, make sure you are looking directly in front of you as well as in the distance, i.e. are the activities in the immediate past still leading you to where you want to get to in the long term. The best way to explain is through analogy. If you are walking looking at a map, if you don’t look up from time to time you might walk into a lamp post :)

Evaluate against set KPIs and measures of success
This is the practical task of studying the detail. Mapping the data against the expected outcomes.

Revise plan as necessary
Adopt the way of the minimalist, remove until it breaks. If the data doesn’t support the hypotheses you set out to validate, then check where you are going wrong. The measures, the tools or the hypotheses could all be wrong. If you cannot correct, you may need to discard.

Rinse and repeat with following initiatives
You need to repeat the cycle above at least 4 times in a year as mentioned and hopefully at the end you get to a level of use and maturity that you can then progress on from for the next year. See maturity point below.

NOTE: When starting with your first success cycle, be aware of any preceding activities like an implementation or onboarding phase with all that it set out to achieve. This can be used as a baseline for the use cases and measures in your initial success cycle.

Maturity over time and an approach to driving it

Over time, with successive quarters and years of use, you would expect an organisation to become more and more proficient in its use of a technology platform and that value outcomes will also increase over time – see diagram.

And if you expect that all users will be equal in their stages of maturity well you are likely to be disappointed which is why you might want to break maturity levels up between your users and segments of users – see next diagram.

Also, there is likely never to be an end to the overall maturity path as new features are added to the platform and new users come and go.

An approach to managing maturity levels between different users and /or segments of users is not critical to the success methodology. But if you are dealing with a great many users in a large organisation with many different geographical or vertical segments, you may want to consider it.

The diagram above is pretty self explanatory and hopefully its clear how you might be able to work with something like this. You really want to keep it as simple as possible because you don’t want to add complexity especially where the organisation or technology already is.

Which leads me neatly to a final point. This whole methodology, like the lean startup approach, is very simple and experimental. That is the beauty of it and the reason for its effectiveness. Good luck using it and if you have feedback about what works or doesn’t or any improvements, please do let me know in a comment.

Like this:

I work in customer success in the enterprise technology space and have written several posts on the activities required for the role – find them under the customer-success tag. This one is about the use case which I see as the currency of customer success management.

A use case is a set of interactions between a user and a system to attain a particular result or function and is often represented by a process or work flow. Use cases should ultimately be geared towards delivering a business solution.

A solution is designed to integrate multiple facets of a company’s business through interchange of info and processes and should produce outcomes that achieve business goals.

The use case is the input, and the solution is the output.

Use cases / solutions can be captured to show the value a platform is providing to the business. It can also be used to share amongst users to support further use and value creation across different parts of the business. See more on this at the end of the post.

Each use case should have its own measure of success and can be broken down into 4 parts which could easily be captured in a single page or slide document template:

Challenges and objectives / expected outcomes.

Workflow and/or functions breakdown to focus on.

Success criteria (KPI’s).

Additional factors for success (change management, training, etc.).

Managing use cases

As far as possible have a method that is simple, quantifiable and results should be taken as representative. You could start with a simple spreadsheet for collecting and managing a use case pipeline. Apply a selection criteria that will allow for quick shortlisting. From a shortlist you could (but don’t have to) use an online survey to get feedback on priority and demonstrable value.

Example criteria for shortlisting use cases

Criteria used for selection (score 2/3 to be progressed or selected)

Relevant

How important is this for internal stakeholders. Case studies that touch core business operations carry more value.

Financial: How does it impact on the bottom line

Customer: How does it impact on how our customers perceive us

Internal Process: How does it improve productivity

Learning & Development: How do we improve and create value

Measurable

Key KPI’s / metrics can be identified

These can be measured through survey’s or analytics and tied to the use cases

Deliverable

Delivery of business value can be quantified in some way.

Resources to manage are available (people, budget, time)

Key stakeholders identified and involved

They suit the organisations level of maturity in use of the specific technology

There are two types of use case that generally need managing:

Pre-existing. Function / activity already being used or carried out to good effect (good outcomes) and can be captured for purpose of sharing good practice and perpetuate further use.

Planned. Function / activity that the organisation would like to see being used or carried out. Idea would be to propose a workflow or process, train users on it and then monitor to see if intended outcomes are achieved. Share if it worked well or iterate further if needed.

Click for larger view

Pre-existing use cases will only need to be captured and tracked so you have a record of them and so that you can share them. The management ends there until you get to the point of sharing or communicating them. Clearly these types of use case will only exist where the platform has been used for some time. When you are launching a platform for the first time, all uses cases will need to be planned and executed.

In the case of a new platform launch, ask the vendor if they have any from other customers that can be used as a baseline. When a platform has been around for a while but you are only starting the work of managing use cases at a late stage, ideally you are able to identify as many pre-existing use cases as possible.

Pre-existing use cases (I call them serendipitous use cases :) have come about spontaneously and hopefully reflect a natural use of the platform. They are unforced or not mandated and as such they are the purest form of a use case. These type of use case are like gold. When I manage business value workshops with customers in which identifying uses cases is big part (see diagram), I dedicate a separate session for these.

Readying planned use cases for execution

Analyse responses from surveys if you have used them or manually evaluate each use case and select the ones that have scored highest in terms of priority. Next identify a person who will help drive their development. Progress with the development of the top 3 or 4 use cases. Finalise the use case format/template mentioned at the beginning, ready for distribution and work closely with use case leaders and users. On this last point, the more complex the technology, use case or organisation, the more you will likely need an owner and team of people supporting it.

Executing the use case

This should be done over a short period of time but that also depends on the complexity of the organisation, technology and/or use case. I suggest roughly a three month period. In this time users should be trained on the use case and supported in getting up and running where needed. Progress should be followed pretty closely and ongoing support provided where possible. At the end, determine where the goals for the use case have been achieved. If it does perfectly then you could adopt this in future uses as is. If not you may need to tweak and iterate further on the use case in a second, quarterly cycle. You may, at worst, need to discard it. If the former case, you can then go on to share it.

Sharing successful use cases – perpetuating the success

A critical aspect of achieving success (and ultimately in my business that means driving adoption of a technology platform) is capturing the essence of the value it delivered in an easy to understand, simple and ideally visual way and then sharing or communicating it. This is also fundamentally important for those responsible for the platform in the business and who have paid for it and must ultimately justify its value and ROI.

It is by capturing successes through use cases and sharing them that you perpetuate success. Users in the organisation not using the system yet see how others who are using it and are inspired to use it in similar or even better ways. It becomes a self fulfilling and virtuous circle of success.

The diagram you see here could be a simple way of capturing the outcomes of a successful use case delivered over a period of time. It is fairly self explanatory. The key thing about it is that the easier you make it to share the better. An image file is likely to be the best way to do that. You could even go so far as to share a template with use case owners or the general population of users so they can capture their own unplanned or serendipitous use cases and then go on to share them.