Breaking down silos to create products with real customer value
After being acquired by Visma with a long-term perspective, a couple of years ago, we have made significant changes to how we work with product development and create transparency throughout the organization.
Blog post by Business Developer & Analyst, Dennis Nilsson
Admincontrol was owned by private equity firms in its scale-up phase, going from a thousand to several thousand subscribers.
Such a growth path requires rigorous focus on getting to a sufficient product parity level with competitors early, and puts a strain on many important facets of the technology side of the organization.
At an early stage for software companies, it is the new features and products that create business opportunities, good internal processes, architecture and platform scalability are not weighted as high.
Since becoming a part of the Visma family, we have focused heavily on creating a new way of developing valuable products which, in the future, will allow us to deliver greater value to customers, much faster than just a couple of years ago.
We have found that working in cross-functional teams, outside of business as usual, and in intense collaboration, creates a much-needed transparency and creative setting that we were previously lacking.
Keep reading to learn more on how we manage to align on what software to build, and how to build it.
How we used to work with product development
Up until a couple of years ago, prioritization on what to build, and detailing of those tasks was done in a very traditional way. Managers or stakeholders from the business side of the organization decided on what to build, based on the most urgent or pressing needs that would result in increased business opportunities.
A project was identified based on the needs of the market and the project was then handed over to a Product Owner, who was responsible for detailing the project together with the developers, and ensure we deliver on the market needs as fast as possible.
From the point of the project being requested from the business side of the organization until it was completed, the business side was very little involved in what was created by the development team. This means that there was not sufficient transparency or communication between business and development from the request phase to the delivery phase of the project.
It was obvious that this type of silo-based working method did not provide sufficient transparency across all departments. We were missing business opportunities that we could have won.
In comes Inception
We needed to do something different and were inspired by our new Chief Technology Officer who had tried a workshop method used to conceive new software products, called Inception.
The workshop is run as a five day long, intense, collaborative session, where we gather all resources involved in the project physically, in the same room. This way, we can ensure collaboration and alignment from all parties, both technical, management, and business resources close to the market.
Taking a lot of smart people out of business as usual and allowing them to focus on just one thing for a period of five days really unlocks creativity and allows us to create a great, and detailed plan that everyone can stick to for a three-month period of product development.Dennis Nilsson
Two people were appointed as facilitators and tasked with learning about Inception, starting out with attending a Lean Inception training course hosted by the creator of the Inception method, Paulo Caroli. I was one of these facilitators.
At this point, we were a bit familiar with a workshop method called user story mapping by Jeff Patton as a tool to align stakeholders and agree on what to build. A user story mapping workshop would normally take us two to three hours, so facilitating for a weeklong workshop was a whole other ballgame.
Adapting the method rather than adapting to the method
About a year ago we ran our first Inception workshop, and from that point, we never considered going back to our old way of working. After the workshop, the organization was buzzing and everyone was intrigued, wondering how it was, what we did, and were eager to hear about the experience.
Everyone participating in the first workshop agreed that this was a method of working to move forward with, even though the output was far from perfect. The outcome was, however, perfect.
Output and outcome are two very different things, where output is something you can work with and change retrospectively. Outcome is something else completely and cannot be changed.The outcome was a well-organized, thorough plan for what projects we were to deliver during the coming three-month development period.
This plan was created with stakeholders aligning naturally, in intense collaboration, using creative and fun techniques to ideate and detail the projects.
Very soon after our first experience with Inception workshops, we started planning for the second one. We made a lot of changes to ensure we got the output needed, while still making sure to frame the outcome in a positive way. This workshop too, was a successful one, allowing us to save more time and deliver value faster.
Recently with corona-related restrictions we have had to make significant changes to our way of working, both when it comes to businesses as usual and doing these types of workshops. It has been a great journey of learning and adapting to a new normal and we have only come out stronger on the other side.
We had good digital habits in place before the new situation but have changed our physical workshop method to a digital one. Doing it digitally is different in more ways than just the physical factor and we saw several valuable benefits in moving our workshop from a physical form to a digital one. I have shared our learnings and reflections on this in this article.
We are all aligned that we have come very far and that we have a better-structured method of working with product development today than some years ago. But too much structure is not a good thing either.
That is why we are looking into and experimenting with other ways of working than the Inception workshop.
The promise of the next phase is even higher quality output, efficiency, more transparency, better communication, and that all projects, small and large, will get handled through collaborative workshop activities.
Our vision is not for Inception to become this large, institutionalized thing, but that it is something living, dynamic, which is owned by everyone doing it and that it evolves with us and our culture.
We think the traditional five-day Inception workshop can be split into smaller blocks of activities that can be handled individually, and for these activities to be more integrated with business as usual.
We would also like to equip anyone working with product development with the tools they need to facilitate workshop activities themselves.
We will share more about this as it evolves, but for now, I want to say thanks for reading.
If you found this read interesting, you might also want to read this article.