Working with some colleagues recently I was asked “Why aren’t we doing all the things to really be [desired state], we should pause and think about how we really want to restructure the company and the way we build software to do it right.”
My colleague has a great instinct and she isn’t wrong in seeing the gaps that we have in the product and how we produce software. But I think that its important to apply systems thinking to solving these problems. That requires us to understand where we can apply leverage to change the balancing feedback loops that are enabling and constraining our products.
Lets say that you are trying to migrate a software product from an on-prem focused delivery to cloud first. I had a hand in this both at Splunk and at Tanium so I’m familiar with at least some patterns in this space.
A balancing feedback loop consists of a current state, a desired state and flows that enable or limit the state change. In software their are many flows that divert people away from buying your software. It might cost to much, not solve their problems, be worse than a competitor, or not of sufficient quality.
In the context of a cloud migration, your most likely causes of customers not migrating into your cloud offering are capability gaps that either prevent your customers from adopting or your business from selling to them.
- You can’t talk to their on-prem data
- You don’t give customers the same administrative rights they have on-prem
- You don’t have certifications required (FedRAMP, SOC2, ISO, etc)
- Architectural decisions on-prem make it expensive to operate
- Operating costs make your price for cloud to high for customers
- etc
I think what my colleague is looking at is that we need to remove those balances on our conversion system, with a particular eye on how important our technical infrastructure is implemented. Unfortunately we cannot eat the elephant all at once. If we dig in and start doing our homework as product managers we see that there aren’t two balancing forces, there are dozens of smaller forces that we have to solve for more tactically. Picking the ones with the highest impact and the highest leverage as we go.
As we start to talk to more customers and operate the service with more customers we are going to be able to start to weight these priorities by their level of impact on our ability to convert. We might start by identifying that a particular administrative surface that we took away in cloud needs to be restored to unlock many potential conversions. So that becomes our number one priority.
Once we work diligently to solve that problem the system will evolve. Now that we have all of these new customers we realize that all of these customers have pushed up our operational costs, and we are losing our shirt on storage costs on our compute instances. So now we need to prioritize an improvement to our storage architecture that will allow us to have a responsible business model before we can go after the SOC2 attestation that will let us get even more customers (who would make the storage problem even worse).
So not only can we not solve all the problems at once, the very act of solving the problems will change the very problems themselves. As we add new customers our audience changes and has different expectations, the costs of delivering the service changes. Process that worked for operations when we had 100 medium sized businesses doesn’t work anymore when you have 1000 medium sized businesses and 100 large enterprises.
This can feel like you are just drifting from crisis to crisis and not building it right the first time. But in complex adaptive systems we the impact of the changes is mostly unknowable. So we can focus on the problems that are in front of us and adapt as we learn new things. As we change the system the strength of the flows will change and we will adjust our roadmap and plans appropriately.