Creating a new organization from an old one is a lot about detangling and understanding what belongs where. If you have done it before, you might be able to see patterns that are helpful. Using visualization and working in a structured way, step by step, and involving the people in it are some helpful ways of working.
Just as always in the complex domain, you are better off not using good practices (the same solution as others). By going by it in an experimental way, step by step, you can more safely find good solutions based on design principles and patterns.
When thinking of it you might realize that it actually is pretty similar to building great products that customers love – based on a legacy system. So why not use similar ways of working?
When are starting out we need to see what we currently have, and even that is a complex endeavor. To get that shared picture of the current organization you can use different techniques, and usually, a good mix is needed. In this post, we will look into how you can map up current teams, products, and customer journey, and the state of the systems and start to see what teams might take ownership over what is a step-by-step approach.
Products and Services
As a start, you can start together to map up the products that your customers pay for. Those are what we commonly call products in an Agile organization. This is where some money is exchanged, and if it is on a monthly basis, it might then be a service.
Below you see an example of the overall products and services mapped out, for both B2B and B2C. There is no need to make this any fancier than this. If you might understand later that you actually have some more products, you can easily add them then if you create a scalable system.
The Customer Journey
Then for many organizations there is also a customer journey that the user travels through. Why is the customer journey important when designing the organization you might ask? This has to do with the customer experience. As a user travels through many different touchpoints and might use several of your products it is critical that the overall customer experience is aligned, and that is difficult to do if you don’t have focus on this when designing the organization. If we don’t take this in as an important parameter we might end up designing the organization based on our internal preferences and not for the best customer experience – and that would not be a product organization.
Above you see a customer journey mapped during a workshop when we mapped all the products and services in small groups. Done in just a few hours, and then digitized in one common view.
Combined customer journey and product view
As you see the customer journey is combined with all the products on the left side, which gives a great shared understanding of what the user is doing in each part of the customer journey and how it is aligned with the products.
Once this is done we can start also mapping out the system capabilities and what type of teams we might need.
Mapping teams to the mix
The goal should be to enable alignment through autonomy, and the customer journey is a great way to enable more of both. In this mapping, we might add two more perspectives.
On the left side, you see a scale from the top, visible, to bottom, invisible. This is in the context of how visible it is to the user. The user uses the stuff closest to the customer journey.
At the bottom you see a legend showing three states for It/digital systems that might be valuable to consider. These three are:
Uncertain, rare, constantly in change – The question mark
These systems/components are mostly new. Here we often need to build, measure, and learn more to be able to learn what works or not. Making big upfront plans on these is not valid and would cause high risk. Having one team working on this is often a good plan.
Known and stable – The box
These systems/components are known and stable over time. Not many surprises occur and we can plan more long term. Here it might be ok to have several teams working since we can build the expertise over time in more teams.
Outdated – The exclamation mark
These systems/components are getting out of date and need to be replaced. It is usually a great thing if the team that owns an outdated component/system also replaces it. If it can be done step by step you are usually much safer and you can benefit from the new parts much quicker than if you would run it as a big bang delivery.
Who takes ownership of what?
When defining who should take ownership of what it has to be the people working in the teams are involved in discovering what should go where, but without the overview that you have created as described above it might not be that easy. Whit this mapping it often goes a bit easier, but it is never an easy thing. Having a “Good enough for now and safe enough to try” mindset is key. You will make bad decisions, and there must be a way to do it in a safe way, and for the teams to be able to re-iterate and adapt over time. If you adopt an Agile mindset and Agile Management practices you can do this together.
Defining valuable principles for how to think when dividing and finding what belongs where and what type of teams you might need helps a lot too.
Some helpful principles might be:
- The team who build something also own maintenance – and replaces it
- All teams should be able to work in any other teams components (but you need to find safe ways to do so)
- Responsibility equals mandate
- Teams working to support customer journey or product teams always have their needs as their prio one to enable flow
- Teams who need to collaborate work in the same cadence
- Teams who need to collaborate work write team collaboration agreements
- Teams who need to collaborate work in the same cadence
- Teams should be able to handle all customer touchpoints within that area
- Teams have all capabilities to handle both discovery and delivery
- The long term customer experience is always more important than internal short term needs
- Everything belongs to but one team, both humans as well as technology and user interface
What type of teams do you need?
Here we have defined 4 different types of teams that might be valuable to consider. All these teams (except the service teams) should be what we call Product Teams, having all capabilities to work end to end doing both discovery and delivery, and optimizing the product/service. This is to create the highest performing, autonomous, and easily aligned organization.
Customer Journey Teams
Delivers on strategies connected to the customer journey, such as Increasing numbers of New Customers, Life Time Value, or Increased Usage.
Product Teams
Delivers on strategies connected to specific products & maintain the platform for long term high quality & speed.
Plattform Teams
Platform Teams delivers functionality in the platform to support needs from the Customer Journey – & Product Teams.
Service Teams
Service Teams act to deliver self-service for all other teams. Could also coach, train, mentor, and support in alignment and strategic input.
Want to learn more?
This content is part of our self paced online training Agile Product Development Process and Organization In a Nutshell Training and Toolbox in our Digital Academy.
Agile Online Trainings at your own pace, in a fun, brain-friendly and engaging interactive format. Get access now!
