Last week I talked about the opportunity for productising internal services within an organisation. I highlighted that productisation of services that business teams provide within their own organisation can produce several benefits in terms of speed, efficiency, measurement and adoption of automation. But how do you go about deciding what your product should look like and what features should be in and out?
First, you need to consider the key drivers that would merit an investment. These largely fall into two areas:
1. Internal benefits directly related to the transformation, such as productivity gains, cost reduction, speed of delivery, employee satisfaction or improved insight. These benefits accrue to internal teams, either the team that creates the product, or to their internal customers
2. External (customer) benefits of making a transformation and how they might address the customer challenge
Taking a balanced view
Any analysis of benefits of productisation MUST take both dimensions into account. It’s tempting to just think about the internal benefits where it’s often much easier to make decisions based on internal efforts, because we have access to complete internal data on things such as cost, delivery time and effort. Very often, the case for productising something can be made just off internal benefits alone – for example “This will raise team productivity by 30%” or “reduce processing costs by 15%”. It’s often it’s easy to justify investing in a new internal product just by attributing the benefits that will be realised within an individual team. However, if you only rationalise based on internal benefits, especially when you’re only looking within a single business team, there is a real risk of siloed thinking.
This can lead to unnecessary duplication with competing, or even contradictory efforts. For example, one business team is focused on internal cost reduction, while another team is focused on external customer experience. In their effort to reduce costs the first team may actively seek to reduce the things that can be requested by other internal teams, which in turn has a knock-on effect on what they can offer customers.
Meanwhile, the team focused on customer experience actively wants to increase the range of services available to customers. Both teams have a strong justification for creating a product that achieves their individual team goals, but they’re pulling in the opposite direction. This is not unusual, in well run businesses you want to have tension between objectives to achieve a balanced view, but at the end there needs to be a guiding principle of what you are aiming to achieve.
It's about customers
The guiding principle for this should always be shaped by the customer needs we are trying to satisfy. We should always be asking about what impact any change is going to have on the customer, and whether our product will improve our ability to solve their challenges, and whether it will affect their experience of doing so. This needs to be backed up with the benefits that will accrue back to the business. This isn’t always easy to quantify, what really is the bottom-line impact on customer preference, or loyalty, or propensity to cross sell in dollar terms? Despite this we should be cautious of weighing easy-to-quantify internal benefits against hard-to-quantify external benefits. At the end of the day, if you are proposing a change to an internal product, it needs to not negatively impact your end customer experience, or at the very least, there should be some mitigations in place
Managing the tools and capabilities
Alternatively, perhaps all the teams are aligned around delivering the same thing for customers, but unless there is management across teams, you can end up with divergence or overlaps in decisions around things like technology or user experience. For example, one team may choose one AI tool for automation, and another team may choose a different tool. There may be very good reasons to choose different tools, but equally, you want to be sure that you aren’t unnecessarily duplicating capabilities. You also want to be sure that there are clearly coordinated boundaries between teams and the products they are managing. It’s very easy for one team to add features that overlap another.
Portfolio Thinking
The answer to these challenges is to ensure there is overarching portfolio management across the different products, so everyone knows what lane they’re in, and what they’re responsible for and how it serves customers. Portfolio management takes a higher-level view than product management. It’s centred around customers and market needs, rather than just around products.
Portfolio management ensures that:
There is a clear definition of the role of each product, its purpose, and the needs it satisfies in each customer segment, and that there is no excessive overlap between products i.e. one team or product isn’t competing with the others to do the same thing
Where necessary, competitor offers are matched and they can’t exploit gaps in your offering (unless you have made a deliberate decision not to fulfil them)
The desired set of customer needs you are targeting are being met within the target market, across the whole customer lifecycle and there aren’t unwanted gaps between products
There is a customer journey across products where relevant, with a smooth transition between products as a customer moves between them.
Efficiency is being maximised to ensure capabilities are being reused as much as possible between products, without any unnecessary duplication, but still meeting customer needs.
May seem like a lot of overhead work, but it doesn’t have to be managed intensively from day to day. It requires a clear framework and upfront definition, followed by regular and clear communication between teams so that there’s good visibility of what’s happening across the portfolio. By having a portfolio view you can keep everyone pushing in the same direction, sharing their innovations, improving customer experience and growing total revenue.
Commentaires