Introduction
Back when I was an associate with a large consulting firm there was a running joke that senior leaders of the firm would often come to us and start a deliverable request with a seemingly ridiculous statement like "I don't know what I want for this presentation...but I will know it when I see it". We knew this meant that we'd better iterate on ideas and share them with the boss frequently for feedback. But we also snickered to each other that it seemed like a cop-out by the leader, putting almost the entire weight of the ideation and deliverable on us junior team members.
Later I realized that this is the core concept in Agile methodologies. That a situation which doesn't have a clearly defined, predictable outcome was best addressed by experimentation and frequent iteration. Hypothesis creation and testing, then prototyping effective ways to present the ideas visually, all applied to the consulting deliverables we were working on. And hence, an Agile/iterative approach made most sense. The consulting boss was not wrong. This core idea also applies to setting up customer success teams and operations. There are many motion, system requirement, and toolkit solutions where the right answer is only known in retrospect, and can change based on existing variables.
The Cynefin Model
The Agile Manifesto and methods comprise many ideas that are useful in setting up CS ops - team structures, backlog tracking, meeting setup, information radiators, etc. But here I want to focus on one aspect that can help you select where to apply Agile in CS - the Cynefin Model.
The Cynefin Model (pronounced cuh-NEV-in) was created by David Snowden and, among other uses, provides a good thought process for spotting solutions that can be assisted by Agile methods. It defines four quadrants of solution types.
Simple: The path to outcome steps are obvious to everybody up front. An example is following a cooking recipe. Most people will know how to execute this if given simple instructions. Complicated: The path to the desired outcome is well understood - but there are a lot of steps to get there. Like setting up an accounting or ERP system, building a bridge, or sending a satellite into orbit. Complex: The best outcome is only apparent in retrospect. This is the realm of Agile. To use a common example, setting up the features, look, and feel of an ecommerce website for a customer. Where subjective preferences, visual appeal, and perhaps conversion effectiveness are only known once examples are seen, tested, and iterated. Chaotic: Patterns can not be known in advance. Two good examples I've heard used here are emergency responders such as SWAT teams, or technical support center staff. Environments where a problem must be acted upon quickly but can not be known in advance. Here broad training provides solution providers with quick response options.
The following are some great resources for understanding and learning more about the Cynefin Model. I've included a bunch since each of these has an informative and unique perspective - but you can probably get the idea by scanning just one or two of them.
Cynefin Perspectives on the "Complex" Solution Space
Start with David Snowden's HBR article, and the classic Cynefin quadrant diagram below.
And this gentleman does a great job with his blog post.
And if you want to see the full landscape in a visual format, this post and image by CSL4D is great.
Cynefin and Agile in Customer Success
So where are the "Complex" solution spaces in CS teams and CS ops? Some examples follow.
Core CS Applications Don't fall into the "management reporting system trap" when setting up core CS systems. Staff an Agile team with representative stakeholders from CS, Ops, and leadership, then iterate. There was a classic CRM and SFA mistake sometimes made in the 1990's in which management stakeholders were overly represented in application requirement gathering. The result could be that the system design missed gathering requirements beneficial to the majority of users and was biased toward what management wanted in reporting. Hence user adoption suffered, sometimes resulting in complete failure of the implementation. Playbooks "Save" playbooks are a great example. The motions that CSMs follow when a customer declares they are leaving you. Iterate to find what works best in a variety of churn scenarios. Involve team members from CS, product, CS Ops, and IT Ops as possible to explore innovative alternatives. Health Scores Iterate to find the combo of categories and metrics that best predict short and long term customer health. Staff an Agile team that includes product representation if your solution telemetry is still in development. Value Analysis and Tracking Customer solution value may differ by use case, by industry, by customer, etc. And if you are interested in tracking "time-to-first-value", this may be trickier to define and track than you initially think. Great opportunity for a cross-team, Agile approach.
And that is just scratching the service! Keep the Cynefin Model and the idea of the "Complex" solution space in mind and I'm sure you will think of more that apply to your customer success environment.