Connecting customer advocates to drive product strategy and customer success


Yammer Customers – From the Yammer Customer Love board on Pinterest

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.

You should avoid the feature / function trap of enterprise technology adoption. Make it about the strategic use of technology. Bring product teams closer to customer needs and pain points. You could cover use cases which are the currency of success. A meetup is the perfect environment in which to discover and share successful use cases.

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.

ideal meetup venue.png

The Ideal Meetup Venue

Guidelines for a successful meetup

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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.
  8. 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.
  9. 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.
  10. 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.
  11. 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.
  12. 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.


Customer Success from the customer and vendor’s point of view

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 :)


The feature / function trap of enterprise technology adoption


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.

It’s the the difference between deep work and shallow work that Cal Newport covers in his book Deep Work: Rules for Focused Success in a Distracted World.

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.

How to avoid the trap?

  1. Have a long term vision that you can look up to and that can steer you. It shouldn’t be immovable, indeed have an approach that allows for course correction like this one I created: Lean startup methodology applied to successful enterprise technology adoption. You’ll notice this approach starts with vision setting.
  2. 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.
  3. 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.
  4. 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.
  5. 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.


Lean startup methodology applied to successful enterprise technology adoption

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?


Click for larger view

That quote from Tim O’Reilly, CEO O’Reilly Media, 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

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 at left of this paragraph.

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

lean-success-planningThis 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.


  1. 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.
  2. Identify and plan use cases
    Enterprise 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.
  3. Stakeholder engagement and delivery /change program
    This 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.


  1. 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.
  2. 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.
  3. 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.
  4. Ensure ongoing support through dedicated channels
    The article mentioned under point three in the Envision section covers what I am referring to here.
  5. 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.


  1. 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 :)
  2. Evaluate against set KPIs and measures of success
    This is the practical task of studying the detail. Mapping the data against the expected outcomes.
  3. 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.
  4. 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

maturity-over-timeOver 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.


Click for larger view

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

Enterprise technology adoption – Use cases are the currency of success

use-case-mappingI 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)


  • 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


  • Key KPI’s / metrics can be identified
  • These can be measured through survey’s or analytics and tied to the use cases


  • 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:

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


Click for larger view

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.

Launch like a boss – bringing consumer startup practice to your enterprise technology platform

first-crucial-90-days-after-launchThe users of a technology platform inside an organisation are a peculiar, collective beast. They are very different to the masses of end users that are customers of a consumer product or service. They are also subject to very different forces than the free, open market subject’s consumers to. However, we can draw parallels and bring in comparisons and best practices from the consumer world and startups that launch successfully there. Launching a platform to enterprise users should be seen as no less important than launching on the open market.

In many cases the numbers of users will be vastly different. Inside the organisation the numbers will be on a much smaller scale for most but the very largest of organisations. Types of users also differ. For example, in the consumer world you have customers mixing with employees such as buyers and sellers on a shopping portal or travellers and hotel operators on a booking service, etc. In some cases enterprise platforms will be intended for use with end users or consumers but the platform will still have to be addressed and launched internally first which is what I focus on. Other platforms will be purely for internal use.

Also, their will be a difference between platforms intended for general use and collaboration or communication like intranets and those for specific purposes like HR or Sales software. The former will have the larger number of users generally. The latter will have a more focused niche of users with very specific motives.

Why emphasise the launch? Because its what you do in the first 90 days that matters. So if you are responsible for technology platforms inside your organisation or help those that are, hopefully these tips will be of use.

Its what you do in the first 90 days that matter most

I work as a customer success professional and have done for some time. In that capacity I’ve always been focused on the longer term strategic outlook for a customer’s use because I’ve always had an eye on the renewal date of the software. This generally tends to be at least a year down the line from the time the platform is first used. Most often these days though, its two to three years down the line with longer term contracts being signed.

In my job I advocate meaningful and strategic long-term considerations in the form of a good success plan. I’ve written about that in this primer on SlideShare. The launch phase is covered in the primer but only as part of the longer term approach. So I’m calling it out and expanding on it in this article specifically.

In some organisations, the customer success manager (CSM) is lucky to play a role in the launch of a platform and can effect outcomes positively. In other cases, launch is managed by an implementation manager and the outcomes of a good or bad launch have to be dealt with by the CSM when he or she takes over after the initial implementation phase. If the latter and the CSM is lucky, the hand off will be on the back of a successful launch.

The fact is also that if you don’t tackle the beginning stages properly, tackling the longer term is hugely more difficult, if not impossible. There are major challenges and opportunities with tackling adoption and engagement in the early stages:

  • You only have one chance at making a good first impression. With so much competition for people’s attention, if you don’t make an impact at the beginning you may have lost before you’ve even properly started. These days in fact, not only do you have only one chance at making a first impression, it is severely limited in terms of the time it takes to make it. In many cases it’s decided in the first few seconds or minutes. This article makes the case brilliantly: First-Time Use: How To Reduce The Initial Friction Of App Usage
  • Tackling the long term with a solid base of users that have had a favourable experience in the early stages is vastly easier than otherwise. It’s difficult to claw back good will and enthusiasm when a users first experience is lacklustre. Both from an organisational support as well as product capability point of view.
  • Some may say that the enterprise is different and that these platforms, which might often be critical business systems, don’t need special attention. Besides this, a mandate to use them from the top, from senior execs, will take care of it. Mandating a platforms use is a strategy you could use in the enterprise and this might overcome some resistance and any competition in the early stages. However it is never guaranteed to work and should never be the only strategic lever.
  • Getting a mass sign-up at the outset can almost eliminate uncertainty about a platform’s prospects because it effectively builds critical scale into the platform’s network from day one. This might be more relevant to the mass scale general use platform than the niche one in the enterprise but still important in either case. Users find a platform compelling when there are people on the platform to talk to and learn from and it provides some kind of evidence of early value. Every platform starts out empty, making these worries particularly acute. Building a network or network capability into a product is not easy (good evidence here: ‘Come for the tool, stay for the network’ is wrong) which makes launch activities all the more important.

In the chart below I’ve tried to position where the launch phase would sit in the context of a longer term success plan and its key goals. Achieving the main aim of engaging users and ensuring they derive value from their use of platforms is made immeasurable easier when you launch successfully.


Steps to follow for a successful launch

Based on some excellent experiences from startups and my own with launching dozens of enterprise platforms I have distilled it down to these steps (in no order of sequence or priority):

  1. Communications or marketing. Arguably the most important element of the launch, for startups at least. For the enterprise this should be simple and educational and could include marketing mails pre, during and post the launch phase. Crucially, it should build anticipation ahead of the launch. Think like Steve Jobs – the master marketer at building anticipation for new product launches. Some great ideas that could be transferred from the consumer world can be gleaned from this colossal post by Jeff Bullas: 23 Ways to Build Colossal Pre-Launch Product Buzz. Key as he suggested is building buzz – just make sure the actual reveal is not a let down if you do. Also, make sure to capture the main reason and benefits for using the platform both from an organisational as well as end user point of view.
  2. Supportive collaboration platform and community. The former only be necessary outside of the platform if the one you are launching doesn’t have any conversational or social features included. The purpose would be to build and amplify network effects – as covered in the article shared earlier, a crucial piece of the startups arsenal. Yet the point here is not to focus on the technology but rather the community. The community is what builds stickiness for the platform and that is a positive end if done well, not necessarily the means. The community is primarily where users can leverage their connections to help each other (solving learning issues or any other issue for that matter and for the platform, or more importantly, for the business) as well as share positive outcomes. This latter point is where you can scale success from an early stage in a positive feedback loop of success with the platform and business use cases.
  3. Webinars, training and offline events. You can do many things online to help scale your success efforts (I wrote an article about that here: Scaling your customer success efforts online – a guide) but nothing succeeds like physical interaction face to face. A launch event is a really good idea if you can manage it. Good training (online or off) should be one one of the basic boxes you tick off in this area but that really is just the start. I’ve seen the case far too many times where some training has been delivered (badly for the most part and only focused on features and functions) with the expectation that this is all that is needed and from there users can be left to their own devices. Coming back to the community part, it would be right to think about how you can keep the building of a community in mind when you carry out these activities. For example, offline events are the best way to start seeding an online community and webinars are also a great way to supplement and sustain it.
  4. In app intro’s and help. A lot of support in the early stage can be automated but however you do it, this is a critical time for it. If users get stuck and cannot find a solution to progress their use, it may well end up stalling further use altogether. Setting up a help desk (temporarily or ideally for the long term) that supplements a vendor’s own platform is a good idea. From a platform point of view, users should be able to easily log issues and requests for help that get handled at speed, possibly even in real time. Ideally the platform also offers walk through’s of different features or help buttons that explain a feature. Rich media like video or perhaps gifs should also be adopted.
  5. Senior exec sponsorship. In the startup world this might be enthusiastic customers that have been on a beta version of your product or service and are happy to speak for it. In the enterprise we speak of sponsorship which is a better way of framing the importance of using a platform than mandating it. However, if the platform is business critical from the get go, the task of mandating its use is made easier. Doing either well means explaining clearly why its important to use and why its critical to the business. When senior execs participate and show their involvement by leading from the front that helps greatly too. Sponsorship is a far more participatory approach but actual participation from senior business leaders is critical for success.
  6. Champions. In the startup world this would mean bloggers and other thought leaders and potential brand advocates. Giving them special attention, sneak peeks and information upfront is key before launch. In the organisation, having a network of super users that you identify far in advance of launch day is critical. They should be predisposed to using the platform and supporting other users. Pre-train them to a very high level. These users will be the early adopters and advocates that help scale your adoption and engagement efforts and pull other users along. You should have an entire program dedicated to identifying, building, growing and rewarding this cohort of users. Incentives to be and for being a member of the program would go a long way to making it successful.

What if you fail to launch successfully?

Then, as in Brian Chesky’s case (co-founder and CEO of Airbnb), don’t fret as you still have two more chances. At least that is, if you haven’t bungled the non communication aspects. This point only really applies if you launched and no one noticed. Maybe the timing was wrong and employees were too busy with other priorities or you simply bungled the communication and the messages didn’t resonate or make a big enough impact.

If on the other hand you have made the wrong choice of platform or the platform had terrible problems, bugs and issues, well then you have a harder task. Coming back from the latter is not going to be achieved simply by relaunching :)

#customer-success, #strategy

Scaling your customer success efforts online – a guide


I mentor startups that go through Microsoft Accelerator’s London program. Because of recent experience I focus on customer success management practices and enterprise software startups, but not exclusively. I recently joined a startup (again) and here too I’m helping with building out a customer success practice.

In all cases what often comes up is the importance of an online presence to deal with various elements of customer success. So I thought I would capture what I have recently been communicating as important and that is the purpose of this post. If you are not sure about what customer success is, I’ve written a simple primer on SlideShare.

To clarify what I mean by online presence, this doesn’t just mean a website with some documentation. This could be a basic starting point but there are many more considerations. I’ve broken these out into sections in this post, explained each and tried to give examples from companies who I know do it well.

The purpose of a good online presence would be to educate, support and add value to the way the customer uses products and services. As an extension of  a company’s support, service and customer success department it’s intended to scale those efforts. If done really well it will enhance the customer experience, build an army of customer advocates and ultimately drive loyalty.


success-online-eduThis goes a step beyond basic product information that would be well served by a good document library. Incorporating rich media like a video series and even going as far as incorporating a certification program could really enhance a learning program. Pixelmator does an awesome video tutorial series.

Education doesn’t just have to be delivered on the site itself. Offer a webinar series where customers can sign up and attend predetermined sessions with other customers. These would be delivered using screensharing, chat and audio/video software. This could be added to a formal training program as a way to top up and refresh learning.

A webinar series needs a team to run regular sessions that customers can get a calendar view of from a page on your site, sign up for and drop in to. If you have a global customer base, stagger the times to cover all time zones.


salesforce community.png

This is the dark horse of a well delivered customer success presence. Not easy to deliver well, it takes serious and authentic effort. If achieved it can deliver substantial benefits:

  • Customer on customer support, scaling and reducing your own support efforts and costs
  • Building an army of customer advocates they scale your marketing efforts
  • Incorporating good collaborative and content features can really help drive the learning process for customers in the community.

Salesforce have done an amazing job with this incorporating their own community platform on the back of their success site.

On the risk side, you may have customers mounting an insurrection if things go wrong or they don’t quite appreciate a new product release. Having a good community management contingency plan in place is critical. The Community Roundtable has an excellent Community Manager Handbook if you want to develop this further.


success-online-supportThis is a fairly obvious area and the cornerstone of any attempt to help customers. Mostly a case of helping them with problems they are experiencing with your product or service, it’s often a question of turning a negative situation into a positive one. But that is a golden opportunity to enhance the customers experience if done well.

In an enterprise environment with a complex product or service that’s especially tricky. Support for the enterprise may have to take many different user types into consideration like the end-user, someone who acts on their behalf, an IT help desk for instance, etc.

A means to log issues and track responses would be table stakes but even this is not done well by many, if at all. In my view this is best done on a site (main site and/or a support or success site and also “in app” ideally) and personalised to the individual so he or she can track progress and responses, rather than via email. Other things to think about (and check out Code School who does a great job with many of its activities):

  • Do you offer a good FAQ (and good search) where users can find a solution without needing to raise a support ticket?
  • Is there a way to contact a human immediately in the event of a pressing problem, either by phone or by chat?
  • Can and should you go beyond problem resolution to feature requests, e.g. an area for users to submit and vote on ideas?
  • With all that is possible these days with AI and chatbots, can you automate the process?

chatbot customer support.png


success-online-docsAgain this is a really basic area that should be relatively easy to do well. Surprisingly many companies don’t.

You should at the very least have a well laid out and searchable or filterable document area on your site. The structure should be intuitive in relation to your product and service or offering. You could go further and structure the content for user type or proficiency level.

In addition to this there are some really basic things you can do to enhance the experience. For instance, you can incorporate rich media like video but if you want to keep that to a learning section, you could simply include gifs which are simple, animated images.

Percolate where I currently work does a really good job of this in my view.


Office 365 Roadmap.png


If you have decided to expose your thinking about the future direction of your product (this is something more specific to product features than service elements) you can make this a compelling part of your efforts. This is also most often a consideration with complex enterprise software products where future enhancements might impact on a customers operations. It’s of special interest to those responsible for the platforms use.

There are risks to doing this. Customers holding you to ideas that are in essence just ideas, not commitments to develop something. The risk is you add something to the roadmap and then for some reason or another it has to be removed or changed. Expectations that this created then have to be managed. If done well this can be an incredibly powerful way of engaging and ultimately committing customers to the future of your product and company by making them co-creators.

If you were to offer a feature request and/or ideas section on your site, this could even be incorporated into the approach. Submitted ideas that are incorporated into the product roadmap is an incredibly tangible way of showing customers that they are co-creators of your product.

Microsoft does this really well for Office 365 features and they took this approach from Yammer where I used to work until we were acquired by Microsoft and we then perfected the approach.

Other things to think about:

  • Positioning and branding
    Showing customers how committed you are to their success seems a natural strategy. You could make your customer success efforts a substantial part of the selling proposition by emphasising them boldly. Salesforce is probably the best example of this (link shared further up). Like them you might do it separately or on your main website, with pro’s and con’s to either. You could give them a specific identity that employees who focus on this and in general, as well as customers, can align with.
  • Customer success stories and use case library
    Use cases are the currency of a good customer success program. Both to show customers how they can use your product or service as well as to capture good use of it (thereby inspiring further use). If you turn the latter into well told stories that resonate then even better. Some way of capturing and categorising them for easy reference would be useful.
  • Customer success program
    Have one in the first place (I cover this in my primer shared at the beginning) and then lay it bare for customers to see. The benefit of this is that customers are shown you are serious and have a well laid out approach to making them successful. It should also show what resources you are putting behind this but also the commitment required on their side – because you cannot always outsource customer success.