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 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.
- 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.
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:
Like Loading...
Stephen Danelutti
