Disrupting yourself
If someone is going to disrupt your company, it better be yourself.
Introduction
If there is one quote from the Nexthink CEO that I’m going to take with me forever, is the following one:
If someone is going to disrupt Nexthink, it is going to be Nexthink itself.
This phrase was the foundation for the (non easy and long) journey that had started in 2019, to provide a full web-browser, real-time, and multi-tenant DEX product.
At first, these words might sound very motivating for people, not fully aware of what it entails, but let me tell you that the journey is like building a plane while flying it. It’s exciting and scary at the same time.
Disruption in the context of reinventing yourself, is not comfortable. Most of the times is counterintuitive. It requires courage and, unless is the last resort, it is a leap of faith where some people may not agree with. However, the risk of not doing it is much bigger (something very well articulated in the book The Innovator’s Dilemma).
Let’s get ready to rumble!!!
I spoke in the previous post about the importance of showing results and progress towards the goal, this kind of endeavours require change. One of the most daunting words for a successful company.
If I had to chose the most impactful things we had to disrupt ourselves compare to what we had been doing up to the starting of our cloud journey I’d mention:
Changing the product (and data) mindset
3 to 1
In the on-premise world we had basically three different components that were delivered and provided the core use cases for EUC (End User Computing) teams and others
How do you combine all three components into one, while keeping the promise to the same users, adding more along the way through a better user experience?
We had to change the way we think completely. Although some of the capabilities can be similarly translated into the new platform, we had new components, a new query language, a different way of processing events, a different architecture, and a different experience.
We leveraged economies of scale to avoid building the same thing twice (even if we made that mistake at the beginning). Defining contracts among the teams was critical o use the services from other teams. Although the first reaction was to build a component X number of times, the TOC quickly became unmanageable.
Thinking in terms of flow (value stream) within the new product helped us to craft a better experience that was seamless. There were multiple teams working to address a specific user’s job, and ownership was crucial to know who is responsible for what. Furthermore, teams proactively asked for owning some components to facilitate and improve the user experience.
Cross-pollination among teams fostered new / adjacent use cases that could not be possible by thinking in silos. Because of the previous point, doing this without any synchronisation was paramount, to ensure the best configuration possible to deliver an outstanding experience. There were moments were some teams could feel the uncomfortableness of getting more on their plate and owning components that were not developed by them, but it was a tradeoff we agreed upfront.
Removing blinders
Who doesn’t want to have data at their finger-tips to understand usage, adoption, engagement, to inform decision-making?
Although we had built our own telemetry system for the on-premise product, we didn’t have the precision to know how our services were performing in real-time nor how customers were interacting with our product.
This felt like start drinking water from a firehose.
Delivering frequently
In the on-premise we used to deliver one every two months. Preparing the deliverables took time, and the testing was not automated for some components. This caused the time to deliver our solution time, and once you have done it, introducing a new change afterwards was not straightforward.
We had to learn and adjusts our processes and tools to allow us more flexibility in order to provide more value quickly.
Anyone would say that prefer to deliver software more often, but the implications are huge. Having the optionality to just deliver to a subset of customers, or customers on a particular region, helps you a lot with validation and testing.
This doesn’t mean you can deliver for the sake of delivering it. There must be a clear goal (problem to solve) and success criteria. Having this superpower requires deliberation and tremendous discipline:
Adapt the strategy, organisation, … and more
This is one of the things you always see written in articles and books, but if you don’t pay attention it goes completely overlooked.
I’m going to the refer to one of
articles Mission → Vision → Strategy → Goals → Roadmap → Task , because although it was implicit, is the way the work has been carried on and unfolded.
I’ve taken the liberty to add the Team Topology, to reflect the idea that is should be informed by the strategy and not the other way around.
I’ve seen teams going through this pyramid, but keeping teams untouchable, which ends up becoming something rigid and have tremendous consequences for the teams.
Manage expectations gracefully
For customers who are going to experience the brand-new product for the first time, and you have done your homework of clearly understanding their main reason they are hiring you, you can be somehow confident they will get a great experience (specially if you have PMF).
For those who were used to the previous product (on-premise) they already have a baseline FROM YOU to compare wittth. Therefore you must be extremely clear communicating:
Before vs Now: where we used to have dashboard, it is now call live dashboard
Benefits: live dashboards are a much better solution because (better way to address existing use cases)
Innovations: new and adjacent use cases customers will be able to address that couldn’t before or it was harder
Buried bodies (my favourite): things that they won’t find in the new solution. Be extremely cautious defining them, and justifying why customers and the business will benefit from it.
How to: show the journey from an existing customers, from the moment they start thinking about adopting the new solutions. Set them up for success and
Same thing for people in the field (account executives, solutions consultants, customer success). Sometimes they have a hard time facing questions and inquiry by customers, and they need to balance that with the reality of how the product will evolve.
What’s next?
On the next nugget, I’m going to be sharing the importance of getting the right people on the bus.