In my last entry, I talked about how I used “Capability Maturity Models” to better make sense of interview results. In this entry, I’d like to explore how the Diffusion of Innovations helped us think about a direction for product strategy.
Moment.dev asked me to help define a clear product direction: the bases of the tool were in place, but how would we convert that into users? We felt that if we had a clear story about who would use Moment, we’d be more able to help focus the tool. In other words, a clear adoption strategy would shape product design.
There were many directions we could go. One strategy might seem good because it looked exciting to the first customer at a company; a different strategy might seem good because it could lead to very powerful usage patterns in the medium term. To decide how to move forward, we needed to juggle many factors: how did we picture it being adopted at a customer’s site? How quickly did we need users to see results?
We needed a way to keep these tradeoffs straight.
The Diffusion of Innovations
I’ve been a fan of the Diffusion of Innovations – both the book and the theory – since Barry Wellman introduced it to me in graduate school. The USDA had originally funded much of the Diffusion of Innovations line of research in the 1950s, trying to figure out how to help farmers modernize their methods. The book breaks down the attributes of innovations to help understand which ones are likely to be adopted, and the attributes of the people adopting them. You might recognize the book from the language about “early adopters” and “late majority,” which became popular from that research.
The other part of the book identifies five different attributes of an innovation:
Perceived advantage: can the user tell that the innovation works better than the status quo?
Complexity: how hard is the innovation to use?
Trialability: once I start using the innovation, can I turn back?
Compatibility: how much does the innovation require me to change about the way I work?
Observability: can other people see that I’m using the innovation?
“Observability” is the term used by Rogers; and is entirely distinct from the sense of Observability used in the distributed-systems monitoring community.
Using the Diffusion of Innovations at Moment.dev
How do we apply this to Moment? Moment.dev has an infrastructure combining text and apps. This means end-users can edit pages, adding interactions to them that can run as code. We saw in the last blog entry that Moment supports gradual automation, where subsequent users can improve documentation into automation.
Moment for Interactive Runbooks
What if we provided a tool to help make instructions for common internal tasks, such as runbooks for incident reviews or internal instructions for managing tasks. As ops teams dealt with incidents, they might choose to improve the pages that they used often. Teams might even be able to review which pages were being executed often to know what needs improvement and to better locate their internal pain.
We loved the idea that some of the runbooks would gradually improve into live notebooks. For example, if a step was “confirm that the deploy had completed”, that might be improved to a live indicator in the page that would show whether the deploy had in fact completed. If a second step required the user to find a process and restart it, that could be replaced with a button.
Perceived advantage is pretty good, once the runbook is established – our interviews showed that some users had some challenges with runbooks becoming obsolete. An automated runbook would attract use, and hopefully be kept up to date.
Complexity would be a challenge: users would need to learn the Moment way of creating live examples.
Trialability would also be a challenge: the default state of Moment was just documents, so users wouldn’t see the advantages of Moment quickly.
Compatibility would be fairly high: we could build an automatic upgrade that would help users get from their current runbooks to our system.
Observability was very good: users would see the runbook and be able to see any live examples that had been created.
Enhancing Runbooks - Kubernetes Upgrades
Knowing that these are the strengths – and weaknesses – what could we do to ease adoption? Are there any design enhancements we could make to runbooks to help them be more triable and to reduce complexity?
We thought about providing an out-of-the-box solution that would be easy to use from the first click. We want to find a task that we could prepare a runbook for – and that people could use with minimal configuration. Optimally, we’d find a task that:
Is annoying to carry out
Has some steps that can be automated.
Will help scaffold users to explore Moment and learn more about how to create their own automations
The idea is that these three steps would address the weaknesses. Having a packaged solution would help improve the perceived advantage; Trialability would be improved by helping customers get started rapidly; and complexity would be greatly reduced when users only had to do a moderate amount of configuration.
We began to consider some tasks that might fit well in that space. Upgrading Kubernetes clusters seems to be a candidate: we had a few reports that had talked about what it took to properly test a Kubernetes upgrade. They had reported the process required lots of tracking of progress through steps, including collaboration with other teams, and asking each of the teams to run through a set of testing and acceptance tests.
This begins to sound like a good task for Moment. If we could build a tool that made it reasonable to run a Kubernetes upgrade in Moment, then perhaps this could help with trialibility and complexity. We would have to carefully design the system to be ready to support this set of tasks.
A Design Path Forward
To be clear, we don’t want to build a version of Moment that can only do Kubernetes upgrades. Rather, we want to make sure that this starting scenario works well out of the box, so that users can start with this, and begin to support their other needs, too. We also need to consider whether there are features that would support not just this scenario, but others, too. For example, what features can we add to Moment to best support coordinating large projects like this?
This more specialized tool offers some great opportunities – but it comes with a trap. Users might decide that Moment is only a tool for Kubernetes upgrades. In gaining easier adoption, we might discourage users from being as creative as we want to allow them to be. It will be important to design the next steps to ensure users can grow and develop in the tool.
Harnessing the Power of Frameworks
The Diffusion of Innovations framework proved invaluable in organizing the complex questions facing our product strategy at Moment. It allowed us to compare strategies, understand trade-offs across multiple dimensions, and rapidly identify testable product directions. This approach can streamline decision-making and accelerate innovation within any organization.
If you're looking to enhance your product development process and make strategic decisions with greater clarity, I'd be delighted to explore how these frameworks could benefit your team. As a consultant, I bring expertise in applying these methodologies to real-world products and can help you unlock your product's full potential.
Let's connect and discuss how I can help your team achieve its goals.