‘Introducing a Product Owner role as a consequence of introducing an agile way of working, does not make you a product oriented organisation’
PRODUCT THINKING
The last 10 years of my career I have been involved in the Agile transformation of a large and very dynamic multinational. I had the opportunity to experience the journey from the first bottom-up initiatives via a supported pilot, to a full-blown top-down Agile transformation. In this article I like to share my personal thoughts about Product Thinking. I experienced that it is easier said than done for a lot of organisations. I like to share my analysis why it is not easy and give some recommendations what you can do to help introducing Product Thinking in your organisation.
What is Product Thinking
With the introduction of Agile methodologies and frameworks in our organisations we also introduce new roles like ‘Product Owner’ (Scrum), ‘Product Management’ (SAFe). Also it has become common to talk about the ‘Product backlog’. However, most organisations use these roles and artefacts without fully comprehending what a product really means.
“In the Agile context, a product is not just a physical item but is a deliverable that provides value to a customer or end user. It goes beyond a tangible good and can encompass software, services, or a combination of both.”
In Agile methodologies, such as Scrum, a product is managed throughout its lifecycle by a cross-functional team that collaborates in short, iterative cycles called sprints. The product can evolve based on continuous feedback, allowing for adaptability and responsiveness to changing requirements. The focus is on delivering a minimum viable product (MVP) quickly and then iteratively improving it based on user feedback and changing priorities.
Often product thinking will be positioned opposite to project thinking. The risk of positioning it like this, is that it comes across as a choice between them and after choosing we will loose the benefits of one of them. I believe they can exist together. However, it is important to realise that it is easy to do projects in a product oriented organisation. Applying product thinking in a project oriented organisation is much more difficult. So I would introduce product thinking in the full organisation and keep projects as a tool in our toolbox to organize for specific changes that can not easily be done by the existing structures in your organisation.
Perhaps unnecessary to mention, product thinking, or project thinking is never a goal by itself. We are just looking for ways to organize ourselves such that we are able to optimally deliver value to our customers and end-users.
How did we introduce Product Thinking
As mentioned above, by adopting an Agile way of working and an Agile scaling framework we implicitly also choose for a product oriented organisation. However this was not recognised by everyone when we started the transformations. Below I explain the 4 most significant aspects of the transformation that were related to product orientation:
An Agile Team or 'Team of Teams' is responsible for the creation, change and support of a product.
Ownership and responsibilities is always a big discussion in large organisations. In our organisation we were used to capture those discussions in RACIs. The problem of these RACIs is that you can write down for an (often incomplete) set of tasks in detail which function is responsible, accountable etc, but often these models do not represent reality and are too complex to ignite the powerful intrinsic feeling of ownership.
Think about it, in a traditional IT organisation an IT service is operated and maintained by the Managed Service organisation, they are responsible for the flawless running of the IT service. However, at the same time temporary organisations called projects with their own stakeholders are changing these IT services, prioritised by portfolios that often only optimize the change versus budget.
Who should feel end-2-end ownership for the IT service and who decides the direction this IT service should develop?
In a product oriented organisation a Product Owner or Product Management is responsible for the product, every aspect of the product. The portfolio make choices for a portfolio of products, every aspect of the portfolio of products.
Portfolio Management had to change from a Project Portfolio to a Product Portfolio
As mentioned above, traditionally portfolios try to optimize the allocation of resources over the different projects and monitor if these projects deliver in line with the assumptions that have been used when this allocation was made.
The incentive for such an construct is to create the optimal allocation. However, we know from Agile that the optimal allocation does not result in the optimal flow of value.
So why not already focus on the flow of value in a portfolio and do this for a portfolio of products, while the stable teams, responsible for a subset of products, do this one level lower for their own products.
Funding (or budgets) were allocated to products not projects
When clear products are defined and stable teams have been assigned to take care of the full life cycle of these products these teams also need to be funded. This way you fund operational cost, maintenance, change but also the cost to maintain and improve the team. These cost are year over year not much different making the creation of next years annual budget much easier. The discussion you should have is;
“are we willing to pay the amount of money for the value this product brings to the organisation?”
This discusion can result for example in a request to the Product Owner to deliver more value for the same funding, or a request to the Product Owner to come with a proposal to reduce the budget with minimal impact on the delivered value.
Projects in a Product Organization
As already mentioned in the introduction I believe that a project is a valuable tool in case a problem or new demand can not be solved using the existing product oriented teams. In such a case a temporary team with a temporary governance is justified. Make sure this happens as an exception, since the maturity of the work should be covered in the product oriented organisation.
Challenges Faced
The organisation in which the transformation was done is a heavily project oriented organisation. Literal, everything is executed as a project. The organisation responsible for these projects are called programs, but were in fact fixed structures without begin or end. This organisation has been extremely successful over the past 30 years so it is possible they found the optimal way to design and build the most advanced machines mankind ever made. However, does this mean this is also the optimal way to create and maintain new data heavy products or IT services? For me this is a rhetoric question.
Below I described 4 of the major challenges we faced:
Hybrid between project and product organisation
The agile transformation was not a company wide initiative. It was initiated by the IT department and obviously touched the business, however, we were not in a position to transition the whole organisation to a product oriented organisation. Therefor a hybrid between project and product organisation had to be found. Note this is not what I meant with executing a project in a product oriented organisation. This hybrid is much unwanted but also unavoidable at the same time.
The compromise that was found is that the business organisation was still organised in projects and using project portfolios. The projects were responsible for business change and in case (and this is nowadays almost always the case) such a business change had impact on an IT product or needed a new IT product the demand was brought to the product oriented IT organisation. This way of working is far from optimal. It is like connecting two incompatible connectors with each other. There is a mismatch in mindset, terminology, methodology, metrics and unfortunately even the definition of value.
Lack of strong Product Ownership
I strongly believe in a product oriented organisation, but be aware that new roles like the Product Owner and Product Management are crucial in the success of such an organisation. Since the Product Owners and Product Management should have a very close relation with the business and understand how the business works and what is important for them we decided to allocate these roles to business staff. However, in the previous challenge I mentioned that this business organisation was not product oriented. This made it very difficult or maybe even impossible for these Product Owners to be successful. The exceptions had a good understanding of their new role in combination with a strong personality and credibility in the business organisation to keep acting as a Product Owner against all odds.
Clear definition of Products
An obvious constraint for a product oriented organisation is that you have a clear understanding of your products. For an IT organisation this can be the IT services they offer to the organisation. However, over the years the administration of the IT services have become messy. Often the result of a product that delivered some new or changed functionality was captured in a new IT service, resulting in many poorly defined, overlapping and sometimes even conflicting IT services. This kind of products can not be allocated to a teams or portfolios. Also defining a price tag to such a product is close to impossible.
So in order to become a product oriented organisation we had to redefine our IT services. Since this did not result in immediately business value this was never seen a priority.
Large top-down transformation
Next to these product thinking related challenges I also like to share a transformation related challenge I faced, since this transformation to product thinking was part of a large top-down transformation.
One of the significant challenges was the lack of management commitment to change their own role and way of working. I guess, when the management team gave their blessings to the transformation they assumed this transformation would only impact the levels below them.
For example; hierarchy was still considered much more important than an optimal network organisation. Although a Product Owner from business side would make a lot of sense with respect to his business knowledge, mandate to make priority calls and his/her vision on the product it felt very uncomfortable to have somebody in such an important position that is not in the reporting line of the “responsible” manager.
Even within the IT organisation this behavior was hampering us to assign people from one line manager to an ART another line manager felt “responsible” for.
You could reason, nice these line managers feel so much responsibility. According to me this “responsibility” is felt for the wrong reason ie. because business line management has the tendency to escalate everything to IT line management and is very sensitive for hierarchical levels.
This behavior was hampering us to setup the optimal teams regardless hierarchy.
Lessons Learned and Recommendations
- Introducing a Product Owner role as a consequence of introducing an agile way of working does not make you a product oriented organisation.
- To become a product oriented organisation when you come from a project oriented organisation you change on many aspects like portfolio management, funding etc.
- Go for an end-2-end product oriented organisation. Creating a hybrid between a project organisation and product organisation is probably costing more value than it will deliver value.
- The teams and the Product Owners embrace the ownership of a product and are enthusiastic about working in a product oriented organisation. By facilitating this way of working for them they are able to create more value for the organisation.
- Invest in good Product Owners and Product Management since they make or break a product oriented organisation.
- For a top-down transformation you need the support of the senior management, but make sure they are aware they are themselves also part of the transformation.
Conclusion
Becoming a true product oriented organisation is easier said that done. There is nothing wrong with introducing new agile methodologies and roles in your existing organisation. However, to fully benefit from this way of working in an end-2-end way drastic changes have to be made when coming from a project oriented organisation.
I believe it is certainly worth it and there is a lot of freedom during this journey to adjust it in a way that best matches your organisation. And keep in mind. We are not trying to optimize a model, methodology or resource allocation for that matter. We are trying to optimize the flow of value.
About the author
Raymond Althof has led the transformation of ASML, spanning over a decade. He loves to share his insights and lessons, so reach out to him on LinkedIn or visit his website: valuevisionary.nl.
