It’s an unfortunate side effect of growth that when your enterprise software goes hyperscale in a growing market, you will need to accommodate an ever expanding set of customer demands for new functionality. Doing so fends of competition but adds complexity and friction to the user experience. It can even be counter-productive and lead to slowing growth or churn.
Continue reading “The hidden cost of complexity in enterprise software”
On the path to the cloud, just as in life (as the Buddha would have us understand), one must submit our most cherished assumptions to rigorous questioning. We would make better decisions if we were clearer about the foundations of our own thinking. Cloud technology is a vast subject and this post tackles just a few assumptions, in the spirit of the DharmaHacker.
Continue reading “Zen and the right view of cloud technologies”
I read this article the other day: 4 Reasons Why Salesforce Could Acquire Zuora. I’m writing this trend report: As a Service Trend. Two of the chapters I will be covering are Subscription Economics and Technology Ecosystems. Point 2 in the first article linked above gets to the heart of and intersection between these two chapters and this post is a way to explore the topics.
Continue reading “The engine of the subscription economy”
I’m trying to distil the essence in this doodle, often for my own sanity, to help me focus on the right activities in the work I do with customers.
Continue reading “Customer Success outcomes and their causes”
It’s been a while since my last update and there’s been lots going on so sit down, grab a ☕ and enjoy reading about a host of new announcements and articles capturing the trend.
Continue reading “Update on As A Service Trends”
I attended Pulse Europe (the 4th) on the 8-9th November, an event run by Gainsight, a Customer Success (CS) technology vendor. They run the larger, main event in the US and I had the pleasure of attending last year where I captured the State of Customer Success 2017. So this is a timely update with a local, regional flavour.
Below are some general observations, main takeaways and then I captured notes from the sessions I attended (including my spin on things).
Chatting to the GM of the European office of Gainsight, Dan Steinman, I concluded that not only were Gainsight in the CS technology business but also in education. He agreed.
By that we didn’t mean the services part of Gainsight where they do offer education in support of their technology (see Gainsight University). I mean the education of an industry, a nascent one that needs it. It’s in their interest of course, to grow the category and also the industry within which it operates, mostly Enterprise Software [as a Service].
We also discussed how other industries could benefit from learning about the CS business, like car manufactures which I have written about before: The connected car vision is missing a few connections
I digress, the point is Gainsight take a leading role in informal education and for helping grow and share learning between individuals, companies, for the category and beyond. In this respect they are very successful and the event achieved that aim too.
This was a theme driven not just by Gainsight on the back of their acquisition of Aptrinsic (more here). I’ve been seeing this more and more and driving it in my work and it is definitely a growing trend.
It encompasses two elements:
(1) greater collaboration between product and CS teams on high touch interactions with and insights from customers and,
(2) the built in onboarding, help and product adoption features in products that drive end user self service.
This trend is possibly the most evident but there is also the need, oft talked about, of greater alignment within customer service oriented teams and with sales and marketing teams.
I found at this event and on the whole that there are no real innovations being driven or presented other than in company products themselves (point above). I am writing an eBook / trend report about this and in the work I do mentoring startups and it is a main pillar I stress.
I think in an industry or category often struggling to find its way (see next point) we will have to do more to innovate and increase the impact of customer success activities. There is so much scope since the customer is at the forefront of everything and technology is changing so much and so fast. But innovation needs to come to business models, processes and people too.
The chart below was presented by Nick Mehta, CEO of Gainsight in one of his keynotes. Billed as a maturity chart, you could also easily see this as a hype cycle. I’ve been through the early curve twice in companies and seen it happen in others. I’ve also seen it happen with many technologies which the cycle most often refers to. I got an impression that as an industry we are in a trough of disillusionment.
Perhaps I’ve been in CS too long and lack the starry eyed optimism of a newbie but I’m saying this from the perspective of what I hear. I hear too much justification, disagreement on the function and its impact, arguments on who owns the customer, fights with other disciplines like customer experience, etc.
It just feels like the conversations are typically of the kind you find in the trough of disillusionment. It’s also a period characterised by lack of innovation as mentioned. That’s not a bad thing. If I’m right, I’m looking forward to the slope of enlightenment for the industry as a whole because on this, I’m a true believer 🦄 🚀
Day 1 – 8 November ’18
This is a list that Nick Mehta, CEO of Gainsight ran through:
This was presented by Travis Kaufman, VP Product Growth, Aptrinsic on the back of Gainsight’s acquisition of Aptrinsic. Ultimately its a reflection of the strategic direction Gainsight believes they need to take to grow the market and no doubt themselves. There are some compelling arguements.
A talk on why CS is the new growth mantra which is based on the main C-Suite challenge around delivering profitable growth. 500 executives were surveyed for the insights amongst 10 brands: Microsoft Azure/O365, Tableau, Symantec, Adobe, Salesforce, SAP, Cisco, Workday, Dell-EMC, Marketo.
By the author of The Three Value Conversations: How to Create, Elevate, and Capture Customer Value at Every Stage of the Long-Lead Sale. This presentation was about a messaging approach for customer renewals, price increases and upsells. It was part based on a quote referenced by Nick Mehta (see screenshot) that renewals are really resells. It also emphasised the need to tell a better story. Great example of Malcom Gladwell’s Tipping Point book success – he wasn’t the originator of the theory, Morton Grodzins was. But Gladwell popularised the theory through better story telling. Other points:
ResponseTap and Micro Focus went through some of their common approaches.
This applies mostly to the support function and was presented by someone from Insided.
Again this was presented by Travis Kaufman, VP Product Growth, Aptrinsic. I agree with this approach from a scale, tech touch point of view. The only problem I see with it is the potential over emphasis on features. This can be a distraction from the all important emphasis on business outcomes which should never be forgotten.
From the President and CEO of TSIA (Technology Services Industry Association) J.B. Wood, a great overview of the industry as a whole. Also touching on the broader opportunity with XaaS (Everything as a Service). The TSIA is an association that works with the top 400 tech companies to understand what they are doing and what impact that has.
A panel discussion between CEO’s of Futrli, Precursive and TaskRay facilitated by the CCO of Box, Jon Herstein. All had robust CS functions so naturally the input was mostly positive.
Day 2 – 9 November ’18
Rumination on the raison d’etre of the CS org and where and how in the organisation it works best based on Gainsight experience. All makes total sense and as it should be for now.
Sirius Decision are a research and advisory company focused on demand generation and performance measurement. They presented findings from various bits of research.
Alistair Wildman, Head of customer experience EMEA was interviewed on stage. This is what he shared after being there and in his position for 6 months.
I attended this session thinking I was going to get insights into the cutting edge practices adopted by Gainsight but it was more like a basic intro to data science. Here are my brief notes before I left the session.
Joyce Liu (Dawn Capital), Paul Morrisey (Battery Ventures) and Stephen Millard (Notion Capital) were interviewed by Igor Beckerman (CFO Gainsight).
Brain Cox came and spoke on astronomy and the result was 🤯 Some excellent perspective after two days of intense CS overloading.
The auto industry needs Customer Success managers. Geoffrey Moore, famed author of Crossing the Chasm and father of Moore’s law is writing a new book on Customer Success. This slide above comes from a talk where he is quoted applying the concept of customer success to manufacturing. I applied the same thinking in this blog post a while ago to a specific type of manufacturer – the automaker: The connected car vision is missing a few connections.
Be more SaaS
Customer success teams were put in place in technology SaaS and subscription companies to ensure that customers are successful in their use of the technology they invested in. They have become a core part of ensuring the customer derives long-term value and ultimately stays with the vendor (in other words renews the subscription).
But has the vendor and customer become too reliant on them?
I am a customer success manager. Far be it for me to be talking myself out of a job. But actually that is the point. If I could get to it (that point) I would have done my job I think.
Especially with technology products you would think that the technology itself would play a major role in helping users use it and get value out of it. And with the advent of AI, machine learning and automation, even more so.
Enterprise technology is quite a different beast though. The complexity of organisations means that technology use and adoption is not straightforward. It’s dependent on many environmental factors. Like culture, organisational complexity and maturity, etc.
Factors that technology is not good at dealing with but humans are. These have to be factored in, so to speak, in terms of how you ensure use and value creation of a technology in an organisational context. So I don’t see human effort going away anytime soon.
Still, lets look at how technology can and should help to alleviate burdensome tasks best left to machines.
In my mind, a lot of the help technology provides is ultimately geared towards the user being able to self help or serve. And its not just about the end user but also those responsible for end user adoption – the people customer success managers typically work with. I’ll call them adoption managers for sake of clarity. They are typically the ones served by Customer Success Managers most directly but as you will see in the next section, I certainly am driven to make them as self sufficient as possible too.
By this I mean two things:
The origins of the idea and also current manual efforts are documented in this post I shared on LinkedIn: Co-owning success with Office 365 customers
Validation has come from winning the hackathon awards (at the global level we won in a field of over 24 000 competitors and 5 000 entries). We also received solid validation from customers we are working with on the current manual efforts mentioned and all new customers we introduce it to.
So it seems there is appetite for this gap in the market. You can watch a very short demo of what we pitched and won with and answer 3 short questions in a follow up survey here if you like – it would help with further validation.
According to a study on Customer Service trends:
The future of customer service is about giving customers more control and better access to operations, so they can build their own experiences in real time. To do this, in addition to investing and moving customer service to cloud-based operations, they focus in on how to work better with automation.
I am totally in agreement with this as I wrote in this post: The Future of Customer Success is Not Human. Even though the context of the study above covers customer service trends which is very different to customer success, it is still broadly applicable. The domain is the same.
I think these activities are going to continue to expand in use and value, especially to alleviate customer success manager efforts where they are overloaded and too much is expected of them and where bureaucracy has crept in.
In the post where I wrote that the future of customer success is not human, I quoted a study on bureaucracy. It has customer service, in which again I would suggest customer success falls, at the top of the rankings of roles and fields where bureaucracy has crept in (list of rankings pasted again here). Being a practitioner I would concur with that and the point I made then and again now is that technology can help avoid this.
Of course a large portion of the problem stems from overzealous management ptractices which is not something technology can help with. But by and learge I see it as a valuable counterbalance.
Assuming that technology can take up a lot of slack and reduce bureaucracy, what does this leave the customer success manager and those responsible for adoption to do?
Well it will be to focus on those intractable problems that I mentioned earlier technology will not be able to help us with and will become increasingly needed. Thorny problems and challenges that can be overcome to improve the customer experience. Those that require and will take imagination, creativity and innovation and will focus on the challenging art of managing people.
I have two separate posts on these topics that elaborate on that if interested.
How many times in your role as a customer success manager working with customers, have you struggled with the solution you are trying to implement where it has not been sold right?
By solution I mean what is constituted in the solution selling process (products and services, solving problems or needs and/or delivering specific business outcomes).
By not being sold right I mean when a customer thinks they are buying and getting one thing and once the deal is done they discover it’s something else.
Sometimes this is a result of over promise to close a deal. Most often this is around what a product can or cannot do, a feature/function mis-sell.
The area I am concerned with and covering in this post is a result of ignorance of what it takes to make a customer successful with the use of a SaaS solution and where this leads to misunderstanding of the effort required or provided. Generally the lack of clarity arises in one or all of the following areas:
It makes implementing any solution really difficult when these expectations are not made clear up front. I have often had to get involved in “go back” motions which as the name suggests, requires going back to the customer to resell the solution right.
This is a monumental waste of both vendor and customers time. Not to speak of the messy job of clarifying misperceptions which is never a good thing.
As someone who needs to implement such solutions post sales, I am acutely aware of this so I’m sharing my experience and thoughts of what will hopefully avoid such situations.
SaaS sales are already complicated and your product has to be easier to buy than to use but use and what it takes to be successful with it, need to be a clear part of the solution you sell.
Whether you are in sales or customer success and ideally this is done together and before anything is sold, make sure the customer knows these things:
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.
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.
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
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 :)
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.
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.
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.
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.
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.
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.
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.
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.
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:
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.
Criteria used for selection (score 2/3 to be progressed or selected)
Relevant
Measurable
Deliverable
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.
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.
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.
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.
