Product-Alignment and Value
The phrase product-aligned, when describing an Operating Model, is a proxy for value. The essence of the Enterprise Product Operating Model is to organise technology functions to achieve a clear focus on customer value and optimise the delivery of that value. This white paper discusses what is meant by value in different contexts, and how to ensure teams are best aligned and organised to deliver that value.
Product-oriented Operating Models are becoming the norm within organisations that strive for excellence. Teams, whether delivering customer-facing products, underpinning services, or platforms, need new ways of working to deliver value iteratively and with agility, whilst maintaining control and efficiency across the enterprise.
A product-oriented operating model is centred on teams delivering value for their customers, be those internal or external, whilst balancing the demands of the enterprise for strategic alignment.
The key considerations when transitioning to Enterprise Product to achieve a clear focus on value are:
Understanding what value means to different areas of your business. Product alignment is
relatively straightforward where the “product” is clearly focused on external customers, but what about other areas of the business?
- The shape of product teams. Where possible, teams should comprise all of the roles necessary to own and complete the total work.
- Defining the units of work to enable incremental delivery and flow. The delivery approach should facilitate feedback and learning, supporting business agility, and enabling a focus on value.
- Intent-based leadership. Teams are clear on (accountable) WHAT value they are aiming to deliver, with leadership that empowers them to deliver.
These are discussed below.
Organising for Value
Product-oriented operating models began to emerge in the mid-2010s. Probably the best-known pioneer in the space was Spotify, where, of course, there was a clear correlation between its products and customer value. If the Spotify player meets and exceeds its customers’ expectations, the company will (probably) succeed. And it did.
In other organisations, this link is less clear. Mercedes Benz needs to meet its customers’ needs through the provision of high-quality cars. These cars are delivered through a complex supply chain and the ERP system is critical to the manufacturing process. However, the end customer has no direct need for that particular process or set of technologies and has no interaction with it. The relationship between the value of the ERP solution and the value to the end customer is not linear.
Similarly, even within the most customer-focused Digital organisations there will still be areas of the business where the value delivered by “product” teams is less tangible and has no direct link to the ultimate end customer. This does not mean that teams should not be product-aligned and cannot focus on their customers’ needs.
Organising for Value
Within Enterprise Product, product alignment is considered on the following three levels: Products, Component Services; and Platforms.
- Products, are aligned to value directly delivered to the internal end user or external customer. They are often aligned to elements of a value stream; defined as a set of actions that take place to add value to a customer.
- Component services, are underpinning applications, systems or delivery patterns that can be shared by different lines of business, departments and Products. Sharing of component services allows for their efficient reuse across the organisation. Component services are recommended for use in Products but are not mandatory.
- Platforms, are common and essential technology foundation that allow any business to operate. Consumed by any user, Service or Product, platforms are more of a commodity and do not directly provide a competitive advantage.
The value ratio of the pyramid is inverted: Products are the things that ultimately provide competitive differentiation and deliver value to the customer. They typically represent 10% of the cost but deliver most of the company value. The customers of the Component Services are the product teams, and they usually account for 20% of the cost, delivering a similar level of direct value. Platforms are the infrastructure, networks and applications that are used across the enterprise, and should be standardised. Platforms are the foundation and are mandatory. They account for 70% of the cost.
The aim is to push everything down through this pyramid where possible – if 90% of the value can be achieved through 10% of the investment, the organisation will naturally become agile. Similarly, if the greater costs are in commoditised platforms there is a significant opportunity to reduce costs and realise greater value.
Service Teams
Service teams can be considered similar to common, foundational capabilities. This may sound paradoxical, but the service they provide is their product and will have clearly identified customers and therefore value. Identifying these teams, and organising them accordingly, should reap significant rewards.
For example, overwhelming anecdotal evidence demonstrates that service teams organised to focus on the value delivered to their customers will not only deliver an immediate improvement in service but will also drive significant optimisations in processes. In the context of Service Management, this typically includes the process, tooling and governance required to “shift-left” and enable product teams to have greater independence.
Team Organisation and Shape
The aim of Enterprise Product is that teams own the total work, in that the dependencies on other teams are removed (as far as possible). Insofar as this can be achieved through multi- disciplinary teams with “comb” shape skill profiles, teams can be organised to deliver value, and optimised to deliver value; removing hand-offs and bottlenecks and enabling flow.
Importantly, if teams own the total work, they can be responsible not only for the delivery of value but for the ongoing optimisation of the approach to achieving this value.
For example, in a traditional functionally-aligned model a test team would be responsible for ensuring that features delivered meet quality requirements, in a Product world, testers work within the product teams and have collective responsibility not only for quality, but that the features deliver value, and that the team continues to optimise – testing should no longer be a bottleneck or gateway to live, but a smooth part of the continual flow to value.
Similarly, the product approach provides persistence to build a deep knowledge of the domain and enable the right solution to the problem.
Team Shape
A Product Team is a group of 6 – 10 people, collaborating and self-organising to deliver value. Each Product Team typically comprises three job families:
- Product management: Ensuring the solution is valuable and viable. Their responsibility is to represent the customer and maximise the value delivered through prioritisation. Typically fulfilled by the Product Owner role
- Delivery Management: Making the team as productive as possible. The main responsibilities are to Support the Product Owner to identify value and prioritise effectively; support the Team through facilitating collaboration and removing blockers; serve the Organisation through continuous improvement and coaching; protect the team from noise. Typically fulfilled by the TDM or Scrum Master role
There are similarities in terms of ‘outcomes’ to the Project Management job family but differences in mindset and approach. Project Managers can successfully transition to this role with training and ongoing coaching.
- Engineering and architecture: Create and support the Product. The specific roles required in any given team will vary depending on the nature of the Product.
Although the aim is to provide teams with every capability required for total work this is rarely possible. The aim should therefore be to organise to optimise flow, drawing on external capability (e.g. legal) such that it does not drive bottlenecks.
Incremental Delivery
Wherever a solution is proposed to meet a goal (value driver), there is an assumption that the value will be realised i.e. the solution will meet the customer need. The bigger the solution, the bigger the assumption, the longer the lead time before that assumption is tested, and the greater investment before any value return.
To support flow and enable “Learn Fast” feedback loops and refinement, the value should be delivered in small increments. Teams should continually strive to understand the customer needs through user research and analytics and develop and deploy new features to increase customer value. If something works, do more of it; if it fails, try something else. Importantly, don’t waste time and investment on big things that might not work.
This is the essence of Agile delivery and DevOps and is critical to the success of Enterprise Product.
Small Batch Delivery
Delivering incrementally in small batches requires a focus on the journey to the solution over the solution itself: break down the problem into smaller steps; look at how those steps fit together and in what order; quantify the value of each; and understand the dependencies, how to remove them, and when they could be safely addressed.
It is essential there is an appreciation that there are no wrong answers in the pursuit of value, only new insights to gain. This sounds dangerous and expensive; but if the steps are small, then so is the risk and cost. It is, of course, counter to what we learned through our early experiences. Success in this area is therefore often reliant upon a cultural shift, with the full support of Executive leadership.
Where to Start
In theory, the idea of a journey to a solution may feel intuitive, but the reality is seldom simple at the outset. It is therefore essential to define what ultimate success looks like, with a clear understanding of value.
Once in the iterative product cycle, it can be relatively straightforward to understand the value of a particular feature and release. But early in the Product lifecycle, this can be less intuitive.
The problem during early discovery is where to start and how much work is required before commencing implementation. Focusing on absolute value is difficult, as many of the questions that need to be answered don’t appear to directly correlate to value. “How do we improve customer service” is a little abstract when the question at hand is focused on technology selection, architectural choices or other similar uncertainties.
One of the benefits of an agile approach is that it provides multiple options for uncertainty resolution beyond mere up-front analysis, options that encourage learning and feedback and shorten lead times.
Nevertheless, some key uncertainties must still be addressed at the start, even when delivering incrementally, before they become major issues. While it may be easy to refactor a method, it is unlikely to be as easy to make changes during delivery to the architecture or technology platform.
However, it is essential not to overanalyse, and using ‘design sprints’ should help. Each ‘investment’ in non-functional requirements should be focused on a specific value outcome in the same way that functional requirements are. Where necessary, these can further be subdivided to give greater focus e.g. technology performance, scalability, operational overhead, training needs, and so on.
Intent-Based Leadership
If teams are to be dynamic and nimble, they need the authority to make decisions quickly and implement them effectively. As they learn more about their customers and the relationship between their needs and the value provided by the product, teams must be able to react without seeking permission. Particularly if permission must be sought from individuals with less direct experience of the challenge at hand, introducing bottlenecks into the process.
Traditional, top-down, command and control does not work in a Product world.
Intent-Based Leadership
Intent-based leadership focuses on empowering employees to make decisions based on their experience and expertise, aligning work with the overall goals and mission of the organisation.
In intent-based leadership, leaders shift their focus from giving orders and micromanaging to setting a clear intent or direction and trusting their team to execute it. This approach requires leaders to create a culture of trust and psychological safety, where employees feel comfortable taking risks and making decisions, knowing that they have the support and trust of their leaders.
Intent-based leadership is essential for Enterprise Product to succeed.
How?
In contrast with traditional command-and-control leadership styles, where the leader is responsible for making all decisions and directing every aspect of their team’s work, leadership fosters a culture of trust, collaboration, and innovation, where teams are free to explore new ideas and take calculated risks without fear of punishment for failure (learning).
The approach is based on the recognition that employees who are closer to the customer are capable of making smart decisions and taking ownership of their work, and that leaders should create an environment that encourages this kind of behaviour. In this way, the leader acts as a coach and mentor, providing guidance and support as needed, but ultimately trusting their team to deliver results.
Of course, there need to be checks and balances. In return for this level of autonomy, whereby teams are provided with the purpose, intent and investment parameters; they need to communicate openly, allowing executive leadership to understand progress and manage risk. Nothing should be hidden.
Management must have the information available to make the right investment decisions, and to provide interventions where necessary. Not everything will go well, and they have ultimate responsibility for success (or failure).
What are you waiting for?
Focusing on value is the essence of Enterprise Product. Shaping your organisation and teams for value; delivering incrementally in small batches, which are prioritised based on customer need; and leading by intent, are transformational for organisations that are reliant on technology – all organisations.
Importantly, Enterprise Product creates environments in which the optimum culture can be fostered, which in turn increases colleague buy-in, engagement and output. It is only through the commitment of staff that organisations can excel.
A Value Focus Throughout the Operating Model
Enterprise Product works. It empowers employees to make decisions and take ownership of their work, which leads to increased engagement and motivation. When employees feel trusted and valued, they are more likely to be committed to their work and perform at their best.
When employees are given more responsibility for their work, they tend to take their roles more seriously and feel a greater sense of accountability. This can lead to better performance and a stronger sense of ownership over the organisation’s goals and outcomes.
By allowing employees to explore new ideas and take calculated risks, Product teams through intent-based leadership will drive greater innovation. When employees are free to think creatively and challenge the status quo, come up with new and better ways of doing things.
Enterprise Product is based on the idea of trust and mutual respect between leaders and employees. By creating a culture of trust, leaders can foster stronger relationships with their teams, which can lead to greater collaboration, open communication, and a shared commitment to success.
Get in touch with our team to learn more about our services, explore partnership opportunities or discuss how we can help with your challenges.