Service design is defined as organising people, infrastructure and communication in sequences that improve the quality of interaction between a product or service, and its prospects and customers. When analysing the arrangement of people specifically, my experience suggests that bad interactions stem from different parts of an organisation optimising systems to solve operational problems, not customer ones.
Traditionally, organisations—large and small—have similar divisions, roles and responsibilities which see them broken up by function; sales, marketing, product, customer service, etc. This setup ensures operating proficiencies and procedures across different disciplines and channels. For digital products specifically, this breakdown can be problematic because functions become isolated contributors across phases of a customer journey that have more overlap than non-digital services.
For a digital-native or digitally-transformed organisation, I propose anchoring org charts around the target customer types, rather than functions. This enables customer journeys—and the interactions within—to be considered in their entirety. It also ensures functional contributors are working toward a common strategic goal and individuals aren't inadvertently incentivised to make decisions that are not in the interest of customers.
Shipping the org chart
The notion of passing prospects and customers through distinct departmental verticals is often referred to as 'shipping the org chart'. It forces them to begrudgingly navigate an organisations inner-workings in order to purchase products, make adjustments or resolve issues.
"Shipping an org chart is one of the greatest forces one must work against in any team of more than 100,"
says Steven Sinofsky in this X (Twitter) thread. He goes on to add, "It is incredibly clear that everyone at Apple puts strategy requirements above anything 'local'. When you wonder why there isn't more new in Notes or why Mail is missing stuff it's because supporting a multi-year strategy trumps individual teams and that's a good thing."
Shipping the org chart makes for bad outcomes:
- For customers: the seams of a vertically distributed system become visible through inconsistent—or contradictory—messaging, hindering their ability to consider, purchase or receive support.
- For businesses: it leads to departmental optimisation; a loss of connection between individual "local" targets and desired strategic outcomes.
- For leaders: it results in continuous tweaking of incentive structures in attempts to re-align functions toward strategic objectives.
Overcoming this means creating conditions which encourage subject matter experts to lean in and not shirk responsibility for things outside their functional purview. In essence, they become Service Designers who approach customer experiences wholistically. For Product Designers, it means going beyond use, to cite an example.
Leaning in can be difficult in traditional org structures because stepping through functional thresholds invariably creates tension. Welcoming it, however, is vital, specifically for digital services because they don't exist within single touch-points or isolated mediums with distinct separation.
The digital product lifecycle
To demonstrate how departmental fracturing impacts digital services specifically, let's start with a (simplified) traditional product journey breakdown:
In this model, a prospect is made aware of a product—say, a television—and they consider it. An in-store demo or YouTube review video may help convince them to purchase it and they do so from a retailer, not necessarily the one that introduced them to the product.
When the prospect purchases the television, they become a customer of the retailer, and the brand who manufactures it. The customer has crossed a clearly defined threshold between the purchase and the on-boarding process. On-boarding could mean reading an instruction manual, plugging in the devices or making adjustments to the settings before actually watching a show. Some support may also be required and it may come from the manufacturer. This support may involve calling someone over the phone, or having someone come out to their home. Finally, if they are satisfied with the results the product delivers, they might even recommend it next time they are at a family barbecue.
The distinct physical locations across the journey, and different players involved in the supply-chain offer some acceptable degree of tolerance on behalf of the customers.
Now, let's imagine the product lifecycle for a digital subscription streaming service instead, it might look more like this:
All the same stages appear in this model, but the sequence is jumbled and is handled completely by the same brand, there is no distinction between wholesaler and retailer. A prospect still transitions from awareness to consideration, but probably receives access to, and starts using the service before they actually purchase it. They can set up their profile, connect other services and adjust properties. They may even receive support and recommend the service before they've made a payment.
The trial period is good for them because they can get a real sense of whether the service suits them, and its good for the service provider because it lowers purchase friction. Of course, try-before-you-buy is not exclusive to digital products, but it is more widespread.
What these distinct models show is that there is much more overlap in a customer's contexts within a digital landscape. I posit, therefore, that organisations should, indeed, ship the org chart—just a different one.
A closer look at org charts
An org chart is a simple schematic detailing the reporting lines between disciplines and the nominated executive who oversees it, like so:
These charts aren't meant to indicate how functions run, or how customer experiences are actually created. For that, there is usually another way to view the organisation.
In tech-native or digitally-transformed companies, we find squads arranged something like this:
These squad structures offer limited cross-functionality, and don't create ideal conditions for service design. On the contrary, these teams usually end up delivering features specific to a particular function. One squad—focused on growth—might be delivering something related to customer acquisition and receiving requirements from Sales and Marketing via a Product Manager. Another team, working independently on the mobile app, or what they refer to as "the product", may or may not be across the other teams' work. This means impactful crossover opportunities are often missed.
As indicated in the diagram, representatives from all functions aren't committed to these squads; they are busy doing their day jobs. Any form of cross-functional collaboration afforded by this setup is a luxury, not a priority. Ultimately, this is just another way to ship the org chart while presenting the illusion of collaboration.
So, is there another way? I say, yes.
Charting an organisation around customer experiences
To offer seamless experiences across a digital customer journey where delineation between stages is difficult, cross-functional peers must work harmoniously. Nurturing this harmony requires specific conditions.
Foundationally, it requires drilling down from purpose, vision and mission to articulate specific desired outcomes, and describing the impact those outcomes will have. Armed with these goals, the organisation can divide itself by their customer or user segments.
To offer an example, a ride-share service, for instance, could be divided into a driver experience stream and a passenger experience stream. Each stream, equipped with individuals with requisite skills and resources in the relevant disciplines can focus on wholistic customer journeys to deliver strategic objectives.
Managed by a product/service manager who has broad knowledge of every functional aspect, and a deep knowledge of the domain, the stream team tackles strategically aligned initiatives.
This approach removes;
- the tension between functional duties and cross-functional ones
- the tendency for departments to leverage whichever system they control to solve every problem
- the functional metrics which don't effectively contribute to a strategic goal, and the bad incentives which drive them.
Work distributed this way would make an org chart look more like this:
The specific functions, number of functional resources and any other inputs required would depend on the nature of the company and industry. All that matters is that the make-up of the team enables alignment and necessary change to relevant systems and processes needed to meet customer needs and business objectives.
The initiatives that stream teams work on might start as ideas or strategic notions from executives, or emerge from the team itself. The team is empowered to decide what to pursue, and what not to, based on its perceived effectiveness to contribute to overarching objectives.
Designing an end-to-end service
Effective service design requires understanding who customers are, what they need, and what motivates them. Once the team has decided to go after something, they can begin the initiative cycle consisting of; discovery, definition, delivery and running.
1. Discovery
During discovery, a problem is identified and the team decides if it's worth solving. Outputs from discovery include problem statements, principles and policies guided by the insights gained during research and analysis.
The articulation of a problem should not infer a solution, for example, "People need an app so they can book a Taxi." Rather, they should be framed in a way that allows the solution to be explored more broadly, like so;
"Changes to taxi rank regulations in inner cities is making it hard for cab services to operate, resulting in difficulties for people who seek efficient travel from their current location to their destination when they need on-demand, private transport at short notice."
2. Definition
Definition includes ideating, refining and detailing all the new features or changes required for the service to be delivered whilst adhering to the guiding principles and policies.
An exercise I am fond of during solution definition is to map an end-to-end journey the customer goes on to consume the service. This asset explores the journey across touch-points and helps unearth things that have been overlooked, such as; where context may be lost, where potential questions have not been answered and what options need to be provided in order to meet customer needs and drive desired behaviours.
Customer journey mapping in this context starts as a simple storyboard which evolves to include high-level concepts for the messages or interfaces that users will consume. It illustrates specifically how you expect prospects will find the product, what drove them to seek it out, and how they will purchase it, be on-boarded, use the product or seek assistance. Something like:
The map becomes a living document which expresses the interactions between customer and the service. It should evolve as the definition phase continues, helping to pressure test ideas and start to adapt to inputs which emerge from solution orientated research, such as desirability, feasibility or viability studies.
It serves to paint a concise picture of what needs to be delivered for the customer experience to be effective, and inform functional representatives how to plan their delivery work.
3. Delivery
Delivery is where the plan is executed. Systems are changed, new things are built, and processes are updated. Delivery encompasses all the changes across all parts of the organisation required to realise the intended customer experience. This may include training sales team members, updating marketing collateral, adding new features in the app or fixing bugs in a back-end system.
4. Running
With a new customer experience in motion, the team should monitor its effectiveness and make adjustments. It is said that no plan survives the battlefield, so feedback (both qualitative and quantitative) should be analysed and acted upon.
In regard to measurement, the strategic objectives or initiative goals should be the only metrics used to measure success. Functional targets can be used to monitor the performance towards an objective, but when used as a reward mechanism for individual contributors, they can lead to misalignment within teams.
Conclusion
Changing organisational structures which impede positive interactions between customers and service providers can be daunting. One's position within the organisation can limit what influence they can yield to make the sort of changes proposed. Strategic notions, culture and ways of working are ultimately driven downward, but you can work middle out, or bottom up to influence change, even if only a little.
The emergence of the Product Marketer role embedded in product teams indicates a shift towards more appropriate org structures is happening. So, while the change requires executive support, individual responsibility also plays a part, and individuals should be open to working cross-functionally. As a designer, for instance, I can't claim to be "human-centred", and then just operate as if humans will magically appear on the home screen of the app I'm designing. I should be curious enough to understand what drove them there, why, and how it can be influenced.
0 Responses
