Tools › Milky Way Map › Step 3 of 3

Design your map for insight and joint decision-making

Turn the map into a daily work tool: different views on one shared geography, for different questions and audiences.

Previous: Chart your galaxy of enterprise elements | Back to: Milky Way Map

Up to now, we have focused on building the map around priority challenges and opportunities that matter to our audience: collecting elements, placing them in a geography that makes sense to map users, and aligning them with an evolving Core Story of our enterprise. This gives us a shared picture of what we do, what people (might) want from us, what we aim to achieve – and how these questions interrelate.

Once you have pioneered a working Milky Way map with Enterprise Elements a few times, with a few co-creators, it is time to use it more broadly and bring it into everyday work. It's no longer a static artefact to pitch and show in a presentation. It becomes a living workspace for exploring questions, testing ideas, and building shared understanding across many audiences.

As with maps of land and water, different challenges call for different map views. A map for planning urban development looks different from one showing a bike route, or one based on voting districts to display election results. Each shows (and hides) different elements and highlights different dynamics, but they all use the same base geography to visually encode and position what they depict.

The map as a daily work tool

The Milky Way map supports many audiences — executives, product teams, architects, marketers, HR, or external partners. It works because everyone starts from the same geography, while we depict different things in different ways. This way, people see more, faster. They understand each other more quickly, and they can do this again and again without re-explaining the basics each time. The geography becomes a common language.

Over time, you'll notice the map is never "done" in the sense of fixed and final: it grows with you. You'll develop a "base map" with a few basic views that show the geography and enable recognition, becoming more stable while still being updated for accuracy and completeness. You'll highlight different areas depending on what matters now. You'll switch between "as-is" and "to-be" views, explore blurry parts to fill them in (or decide to keep them blurry for now), and learn when to lower the resolution for the big picture, or add and highlight elements in focus for detail.

Your initial goal as a map maker is to make the map part of every conversation about key changes and related design decisions. But you'll also learn when to stop navigating and move on to other tools, because the map has already helped everyone find their way and deal with the mess.

Practical tips

Picture the enterprise, but keep unknown and blurry areas
It might be tempting to make Milky Way maps that zoom in on a particular area, team or project as "the enterprise". This will thwart your efforts to establish a shared geography that people recognise at a glance and can immediately relate to. Instead, display what you know about areas that are currently out of scope, or even largely out of sight. With continued use for more and more challenges, such gaps will close and hidden interdependencies will become visible, making the map more complete and useful.

Keep a challenge catalogue at hand
It's well established that whenever you want to navigate an area of our planet, a geographical map is a good idea. In the enterprise context, this has to be learned. The Milky Way map is versatile and applies to many challenges. Keeping track of current challenges and anticipating future navigation needs will help you keep thinking about ways to apply the map to various questions. It will also help you highlight links and dynamics between them.

Choose the right tool support or medium
Different map users are used to different tools and mapping styles. A Milky Way map can be created physically on a whiteboard, printed and exhibited, or built in digital collaboration or diagramming tools. It can resemble a sketch, a diagram or an illustrated story. It can stand alone, or come with annotations, explainer videos, or links to connected data sources, wiki pages or repository items. Consciously choosing the format that will enable understanding and continuous use by your audience will greatly help adoption.

Adjust your depiction to juggle as-is and to-be states
Unlike a plan or roadmap, a Milky Way map depicts snapshots of the enterprise: what is going on today, what might be going on tomorrow, or how to get there, all on the same geography. Establishing a visual vocabulary for these different map modes helps users recognise what they are looking at. Common practice is to use diagram or illustrated notations for the current state, and annotations, sticky notes or sketches for future states and gaps – and to state the map mode explicitly on the map.

Highlight and filter to reduce visual overload
No map view can or should depict everything going on in an enterprise. As with country or city maps, we have to decide consciously what to show at which level, and what to filter out completely, when building up the geography as a visual map. Depending on the question the map is meant to help answer, we then add specific instances of relevant elements and position them on the map – think of a route planner showing just one or two routes to a destination and highlighting specific points such as land borders.

Let the map (and its users) grow and evolve
No map is perfect, but some are useful. Keep an open mind and adapt your map as people adopt and use it. You might meet eager fast learners, but also people sticking to their existing tools and initially rejecting an alternative way to depict the enterprise. Work with them to find out what's missing, what's hard to see or grasp, and what could be incorporated from their existing models and maps into the Milky Way. Adjust your depiction, zoom levels and resolution, and tool support, and revise your geography in iterations as you develop more views for specific questions.

Keep your map alive and in sync (not redundant)
Keeping the map relevant and up to date is hard work, and you will rely on other people's contributions to achieve it. As map users multiply, what the map shows for "their" sectors and elements will matter to them – engage people with such a vested interest as fellow map makers, using a collaborative tool. Clarify that the Milky Way map isn't designed to replace the models and maps they already use, but to show them in the context of the enterprise. Instead of replicating them on the map, display just enough detail to provide this context. Keep this information in sync, referring to other widely adopted models or sources for more specific views and more detail.

Reuse, share openly and widely, and run reality checks
When people see a new view of the Milky Way, they expect the familiar geography so they can quickly find their way. So build every new view on those already in use, and iterate the geography only carefully (unless a major gap has been revealed). Share your maps as widely as possible, in digital or physical spaces, communities and groups, endorsed by leaders. When people react with curiosity or scepticism, walk them through the map to validate what it shows and close any gaps with reality.

Know when to stop mapping and move on
Map making can become a passion. Keep in mind that the Milky Way map is primarily a navigation tool. Stick to "what do we need or want to know to take the next step with our challenge?" as the main question for the map to answer. Once the most significant areas, spots and dependencies are identified, potential future scenarios are mapped out, and the conversation moves elsewhere, stop adding detail and move on to take action.

The map for a new strategic ambition

This section outlines four exemplary ways to use a Milky Way map view to respond to a specific challenge, showing its use as a navigation aid for any enterprise challenge. More than guides or templates, they apply the mapping strategies from the previous step as use cases based on real-life projects and engagements. The examples follow Intersection Railways, which acquires a startup to enable a strategic shift to Night Train operations, aiming to disrupt low-cost airlines for major European cities:

Shift View: start from a new, bold and perhaps somewhat unclear ambition handed down by senior leadership, and visualise what needs to change to make it happen and achieve market impact (Sketch Style).
Customer View: step into the customer's perspective to see how our products fit into their journeys, and evaluate the customer impact of changes by tying together various delivery models (Diagram Style).
Overlay View: show organisational changes and associated metrics for a substantial merger or reorganisation, to highlight overlaps and synergies, evaluate trade-offs and redistribute accountability (Illustrated Style).
Path View: highlight a path to show how we deliver an innovative project, from the underlying purpose to serving customer tasks, focusing on capabilities for organisation and product design decisions (Illustrated Style).

Shift View

Starting point: Ambition-driven mapping strategy, focusing on a shift in Purpose

Context: Customer Journey and Tasks, Capability Gaps, Activities required for change

Highlights: Organisational Silos (today), Product Opportunities (tomorrow)

Scenario: The C-suite reveals a bold vision for the future of Intersection Railways

Question: Where are we today, and where do we go from here?

Use: A shared picture that gets everyone behind the same ambition

EDGY Depiction: Sketch Style

In the previous step, the ambition-driven mapping strategy showed how to put a network of interdependent purposes at the centre of a Milky Way map, then let capabilities, offers and experiences align around it. The focus was on "what we want to become", mapped into a shared picture.

This view fits when the enterprise faces a radical shift in ambition or purpose, usually to deal with a few major challenges. It relies on two advantages of a shared geography and visual language:

Familiar territory and depiction: anyone familiar with the geography will immediately find their way, or be able to guide others around a version of the familiar Core Story. Depending on the state of adoption, this includes anyone who took part in creating the initial map, or a wider audience.
Focus and context: the map focuses on the evolved purpose of the enterprise at a high level, giving direction but also a sense of where we start from. It adds the customer experience, operational capabilities and organisational teams as context for this shift.

It shows a highly aggregated view, deliberately reverting to a Sketch depiction to emphasise the map's nature as a draft that sparks thoughts, conversations and collaboration. It contrasts an assessment of today's state of affairs with a desirable vision of a potential future state, together with proposed actions to get there.

A high-level Milky Way Shift View of the enterprise, drawn in Sketch style

This example view for Intersection Railways shows two different depictions of the Milky Way geography: the scattered complexity of today (left) and the focused ambition of tomorrow (right), based on senior leaders' current perception of the company and their vision of a more purposeful future state. Both share the same base geography, but highlight different states:

Today: multiple, often conflicting purposes, the result of the company's history as a national public service venturing into various markets and sectors. The map reflects the lack of a single ambition.
Tomorrow: one clear ambition – sustainable travel that competes with airlines through green mobility. It also shows a boost in the company's ability to renew itself through innovation and transformation as the Core Story cycle repeats.

How to read

The Shift View is divided into three parts, read from left to right, focusing on the evolution of the Core Story in line with what was mapped in the previous step:

Today shows our current purpose as people see it now, revealed by eliciting the perceived "actual purpose" people pursue. It shows us as fragmented and siloed, legacy-driven and compliance-oriented.
The Gap in the middle highlights three initiatives that change the way we work: a customer experience project, the acquisition of a startup, and an internal transformation. They are designed to help us move towards a clearer and more focused purpose.
Tomorrow shows our evolved purpose as a sustainable alternative to air travel. These ambitions build on the ambition-driven mapping work; here we focus on how to fulfil them.

Icons or illustrations help show subtle shifts that are hard to capture in words. In this example: at 6 o'clock, in the gap between cycles, the move from bureaucracy to supporting people; or at 11 o'clock, the move from basic digital planning apps to a full view of people's journeys across Europe.

The map doesn't show every detail. Instead, it visualises and annotates the main messages we want to convey:

People: from generic customer segments and freight to a clear target group of eco-conscious business and vacation travellers across Europe.
Experience: from broken, incomplete and fragile to seamless, end-to-end, high-quality, reliable and resilient service, expressed in customer quotes – both those we hear today and those we'd like to hear.
Architecture: from many disjointed capabilities (counted from a more detailed source) that cause operational shortcomings, to a platform for green product creation and high-performing, resilient service delivery.

This example also highlights two specific elements placed on top of the map:

Today: organisational silos, marked as barriers between two teams to be overcome.
Tomorrow: product opportunities, depicted between customer-facing capabilities and journey steps.

Each Milky Way view needs a clear focus. In this example, the focus is on Purpose, but the same approach could apply to another dimension, such as Experience or Capabilities. The key is to keep the focus clear and not overload the view.

When to use

This view is useful in situations of major transformation or strategic repositioning. Typical triggers include:

external shifts such as new regulations, sustainability demands, or competitive disruption;
changes accelerated by acquisitions or new partnerships.

Use it with C-level leaders and their direct reports, strategy teams, corporate development, innovation and transformation leads – either as co-creators or as key input providers.

The view works in two ways:

Early on, to align on a shared understanding of today's challenges and a vision for tomorrow.
Later in the initiative, to bring more people on board and connect this vision to other Milky Way or complementary views that show how the change plays out across different facets.

How to make

Use A4 or A3 paper, or a digital equivalent.
Allocate space clearly to Today, Gap/Steps, and Tomorrow.
Sketch two Core Story cycles, with steps and customer journeys on top – this creates the geography. Leave space in the middle for the Gap between Today and Tomorrow. Add key people: by default customer segments, or key people such as partners, suppliers or investors. Describe the story steps:
- Today: capture the current shared perception.
- Tomorrow: inspire people with a future story.
Start with Today. Make it visually distinct from Tomorrow so the contrast is clear. Add customer quotes or insights at the top, and illustrate the issues in the current setup that require us to shift. This could include illustrating journeys, capabilities and processes, organisational dynamics or key assets.
Don't worry if the map feels vague, high-level, or needs explanation. That's fine as long as it helps people grasp the overall shift.
Use a sketch style to begin with. If sketching feels uncomfortable, involve a graphic facilitator, use icon libraries, or switch to a different EDGY style.
When the view is ready for wider communication, adapt it:
- choose a more accessible graphic style;
- follow your brand guidelines;
- consider diverging from the Milky Way format if it makes the message clearer.

Customer View

Starting point: Outside-in mapping strategy, focusing on customer journeys and tasks

Context: Capabilities delivering products, and the purposes that organise and enable them

Highlights: Product opportunities, overlaps between existing product teams

Scenario: Several teams run customer insight and service delivery work in parallel

Question: What are our customers trying to accomplish on their journeys, and where can we serve them best with what we already do (or can quickly build)?

Use: Spot opportunities for product discovery, trace them back to delivery challenges and strategic priorities, and find overlaps where different products rely on the same capabilities

EDGY Depiction: Diagram Style

This view builds on the outside-in mapping strategy, starting from the customer and looking at the enterprise through their eyes. In many enterprises, teams already map customer journeys and build service blueprints, but often in isolation and at product level.

Each map shows part of the picture. At Intersection Railways, this might include teams working on digital apps, onboard service, sales channels and loyalty programmes – but they rarely connect. The acquisition of a pioneering startup to integrate a promising Night Train product adds to this disconnected collection of insight and planning.

The Customer View combines the end-to-end customer tasks in one depiction, and maps them to our efforts as an enterprise to appear in the customer experience with valuable products and useful interactions. It uses the EDGY Diagram Style to emphasise the map's nature as a research and planning tool.

File:Milky Way Customer View.png

A Customer View on the Milky Way

The Milky Way brings these fragments together on one shared geography. It gives teams a shared view of customer journeys as a sequence of tasks, mapped along the Core Story and aligned with our enterprise capabilities and purposes as context. This link to the internal workings of the enterprise, including what happens before and after acquiring and serving customers, provides an overview where existing work can be placed side by side, linked and navigated. This makes it easier to trace connections, spot overlaps, and use insights across teams, while keeping everyone oriented in the same landscape.

It also lets you trace each product opportunity back to delivery challenges or priority purposes, moving beyond tactical fixes to broader design questions. This helps spot overlaps and synergies across products, not just gaps in single journeys.

How to read

Following the outside-in mapping strategy, the Customer View displays the passenger experience prominently, filtered to a key segment:

Long-distance traveller tasks appear along the top of the map, sequenced as a journey: from initial ideas, to planning, to actually travelling.
Tasks identified through customer research as Top Tasks – those that really matter to our (potential) customers – are marked with a yellow outline: planning trips with friends or colleagues, arranging local transportation, and dealing with delays when there's a train connection. They can make or break the customer experience and deserve particular attention in product discovery and design.

In the lower part of the map, you'll find a high-level view of the enterprise purposes and operational capabilities, reusing the output of the outside-in mapping from the previous step. This is a high-level view of the inner workings, filtered to elements directly relevant to the customer.

The Core Story cycle creates the map geography at the centre. This story is always evolving: this version is inspired by the vision outlined in the Shift View, but grounded in current reality.
Purposes form the inner layer, giving direction to how the capabilities required to pursue them are organised.
Capabilities are positioned in each sector of the map. Those newly acquired from integrating the Night Train startup are marked with a green outline. They focus on product development in partnership with other operators and complementary service providers, delivering high-quality customer service, and using data for innovation and development.

The edge between tasks and capabilities is where the customer experience and the operational cycle meet. Also inspired by the Shift View, the Customer View shows which products (might) appear in the customer journey, enabled by capabilities. It also shows which team currently covers which part of the customer journey.

Existing products are marked in purple, acquired ones with a green outline. These include existing train scheduling and ticketing apps, websites and vending machines, and specific apps and services provided by the Night Train startup.
Opportunities for potential new products are marked in white with a purple outline, such as trip recommendations, transfer to the final destination, or assistance with connections.
Below, organisational teams covering parts of the customer journey are shown in light blue. Sales, marketing, digital and customer service teams each run their own journey management and service design work, resulting in a fragmented picture of the end-to-end experience – while the startup covers almost the entire journey, focused on its existing product.

A Milky Way map applying a Customer View gives an overview of what customers experience when interacting with the enterprise, and connects it to the products offered, accountability for delivery capabilities, supporting work, and the underlying purpose. Weak links, gaps and empty spaces, or overlapping responsibilities become visible and actionable for enterprise design decisions.

Tracing back from the start and end of the customer journey shows what happens before and after customer interactions, and what happens in the background – the backstage delivery the customer doesn't see but that makes the experience possible. This links product opportunities not only to tactical fixes, but to broader questions of operational delivery and business strategy.

When to use

This view is useful when customer insights, tasks and journeys are already being researched and mapped by different teams, but remain fragmented and disconnected. It brings them together in a single shared geography, so overlaps, gaps and handovers become clearly visible.

This helps product managers and service designers identify new opportunities at the edge between tasks and capabilities, and helps architects and strategists trace these opportunities back to delivery challenges and strategic purposes.

Individual product roadmaps or service blueprints often include a bottom section showing a single team's selective understanding of the operational and organisational reality, or an idealised version that supports the desired customer experience. A Milky Way map, especially one also used for operational planning and architecture, grounds this vision in a shared understanding of the enterprise, and helps visualise what needs to change to actually deliver.

Use the Customer View in particular when:

multiple teams run customer research, journey mapping or service blueprinting in parallel, and leadership needs one coherent picture connecting the dots;
prioritising product discovery opportunities and deciding where to invest first;
you want to move beyond isolated product development or tactical customer experience improvements, and link opportunities to broader enterprise design questions;
a merger or acquisition introduces new customer-facing products and services that you need to integrate.

How to make

Start with a clear customer segment, such as long-distance travellers. Collect tasks from research, journey maps and service blueprints.
Place customer tasks across the top of the Milky Way, sequenced as a customer journey along the customer-facing steps of your Core Story. If applicable, mark Top Tasks so they stand out.
Add purposes and capabilities below, filtered to those directly enabling the customer journey. Mark newly acquired ones to show how the combined enterprise extends its reach.
At the edge between tasks and capabilities, add products: existing, acquired and potential. Use tags or a visual cue to distinguish them. Highlight gaps and overlaps.
Add organisational teams below to show who covers which part of the journey. This makes fragmentation, duplication or missing ownership visible.
Keep the diagram layered and simple, but use annotations or icons to highlight product opportunities and connect them back to delivery challenges or strategic purposes.
Use EDGY's standard Diagram Style unless there's a reason to use the Sticky or Sketch styles, to link your map visually to other models such as Service Blueprints, Customer Journeys or Capability Maps. If a known notation is better adopted than standard EDGY, consider using it.

Overlay View

Starting point: Inside-out mapping strategy, focusing on capabilities and processes

Context: Purposes, customer tasks and journey

Highlights: Various overlays, such as organisational teams, metrics, assets or products

Scenario: An upcoming transformation requires a shared overview of the operational reality

Question: What is being done today to pursue our purpose, make our products and serve our customers?

Use: Discovering, designing and planning operational and organisational change

EDGY Depiction: Illustrated Style

Many maps in the enterprise show operations: process diagrams, organisational charts, IT landscapes, or service blueprints. Each has value, but taken alone they miss the bigger picture: how does everything work together to organise and automate work, make products and deliver them to customers?

Focusing on the inner workings of the enterprise, this view establishes the geography to navigate capabilities and their interplay. The Overlay View places various EDGY elements into the shared geography of the Milky Way, making it possible to trace connections and dependencies. By using overlays, it avoids overloading a single map with detail, while still showing how different perspectives come together.

At the heart of the Overlay View is a base map depicting the enterprise as a whole and "as it works today".

File:Milky Way Overlay Base Map.png

The Overlay View base map, in Illustrated Style

Using EDGY's Illustrated Style, with icons or simple visuals, makes this map more than a technical diagram: it becomes a clear, appealing and fun tool that people actually want to work with. This style encourages engagement and helps teams quickly recognise the parts of the enterprise they know, making it easier to have productive conversations about change.

Instead of drawing another process model, the Overlay View creates a base operational map and adds layers of information: teams, assets, metrics or projects. This lets users filter, compare and switch perspectives without losing orientation.

How to read

The Overlay View starts from a base map of the enterprise, depicted in Illustrated Style. In this example, operational capabilities appear across the map in blue, showing the capabilities that make processes and collaboration work: from scheduling and ticket sales to infrastructure management and energy distribution. For more detail and accuracy, the arrows also specify what each capability delivers and passes on to the next ones further along the Core Story cycle – for example, "Emergency Bus Scheduling" providing "Relief" to "Drive Train" in the case of an operational issue.

As context, customer tasks are shown at the top in red, sequenced as journeys from "trip ideas" to "arrival and feedback". At the centre, purposes are shown in green, giving direction to why these capabilities exist, such as seamless mobility, reliability and sustainability.

This base map provides a recognisable inside-out geography of the enterprise as a whole. It is detailed enough to show flows and dependencies between tasks and capabilities, but presented with icons and clear visuals so it remains engaging and easy to navigate. People from different backgrounds can quickly find their area of work and see how it connects to others.

In this example, some placement decisions from earlier maps were revised – for example, moving the Enterprise Design capability to the bottom gap at 6 o'clock, indicating that it is a shared capability supporting the entire cycle rather than sitting at the end of the story as in the previous view (which needs updating if also in use). Note that the right side of the map has fewer items, which suggests most work so far went into understanding and mapping the left side.

Once established, adopted and known – even before it is seen as complete – the geography makes it easy to convey specific messages as overlays.

File:Milky Way Overlay Budget.png

Budget overlay on the base map

Budget overlay (percentages): grey blocks with numbers show how much of the budget is allocated to specific clusters of capabilities.

This reveals where resources are concentrated today, for example in infrastructure, resource management or operational planning. Combined with the base map, it becomes clear how budget distribution aligns (or not) with customer tasks and enterprise purposes. This sparks questions like: are we investing in what matters most to customers, or in what aligns with our official priority purposes?

File:Milky Way Overlay Teams.png

Organisational teams overlay on the base map

Organisational teams overlay: light blue boxes highlight which teams or departments are accountable for parts of the enterprise, such as Sales, Digital, Operations or Customer Service. This overlay exposes overlaps where multiple teams cover the same area, and gaps where no one is clearly responsible – at least as far as the map makers know.

It shows how organisational boundaries cut across the operational flow, and where accountability may need to shift. It also reveals when teams appear in several locations on the map, or sit on the customer journey side, directly accountable for supporting customer tasks, while others work "far away" from the customer, behind the scenes.

This can inform conversations ranging from planning "who does what" all the way to organisation design and development.

File:Milky Way Overlay IT Process.png

IT systems and process overlay, next to a classic process model

IT systems and process overlay: this example shows only half of the base map, still recognisable and readable for anyone familiar with the geography. It presents two depictions of the same thing, side by side:

On the right, a classic process model from Planning to Track maintenance, along with the IT assets (software applications) used to run these process steps. A colour code shows whether they perform well or have minor or major issues, with some annotations.
On the left, the same information is displayed as an overlay on part of the Milky Way. Only the IT assets relevant to this process are shown, in EDGY Diagram depiction, with a metric showing the same status information, but positioned next to the corresponding capabilities.

This Milky Way view and overlay enhance rather than replace the process model, adding context:

Adjacent capabilities are still shown, just faded out, so additional dependencies are revealed – for example, "Talent Demand" also feeds into "Operational Planning": does this affect the process? Are there other processes or assets, before or after, that we need to look at?
Map readers familiar with the previous overlay will remember which teams might be affected by a change, such as "Procurement" when external partners are involved.
The purposes associated with this map sector, "Build trusted partnerships" and "Safety first", add context about our priorities, which might affect design decisions.

When to use

This view is most useful when transformation requires a clear, shared picture of how the enterprise currently works. Instead of these examples, other metrics, elements or ideas can be shown on top of the map. It is particularly relevant:

when evaluating the impact of change initiatives across teams, budgets and systems;
when preparing to consolidate or modernise IT landscapes and needing to link systems to business processes;
when making investment choices and needing to compare resource allocation against customer needs and strategic priorities;
when leaders need a single operational overview that combines different internal perspectives without losing the link to customers and purposes;
when planning a reorganisation, merger or integration and needing to see overlaps and redundancies.

For Intersection Railways, these overlays make it possible to ask sharper questions: Are we overspending in areas customers never notice? Which capabilities fall between teams? Which IT systems could we simplify after integrating the startup? How would a decision in one area or facet affect the others?

How to make

Choose a support big enough to show the necessary level of detail. Place customer tasks along the top, operational capabilities in the middle, and purposes at the centre.
Use the EDGY Illustrated Style with icons to make the map clear, recognisable and engaging – but consider other styles if this is difficult to achieve.
Use straight lines for the flows between elements to reduce visual clutter and make them easier to follow.
Show how processes connect and depend on each other to enable the customer journey. Keep the view high-level, but structured enough for teams to see where their work fits.
Layer additional perspectives on top of the base map, such as budget allocations, organisational teams or IT applications. Use visual groupings, highlights or labels to keep them distinct without losing orientation.
Explore overlays one by one to answer specific questions, or combine them to reveal cross-cutting insights.
Export the base map in various formats – as an image for digital collaboration tools, and as a print for workshops – to bring it into more and more conversations.
Update the map as the transformation progresses, and use it in workshops to compare perspectives and support operational and organisational design decisions.

Path View

Starting point: Inside-out mapping strategy, focusing on a path from purpose to product

Context: Other capabilities, customer experience

Highlights: Products, Brands and Organisations directly linked to the depicted path

Scenario: New product launch and business model, capability shift after an acquisition

Question: What needs to happen to launch a new product?

Use: To plan new products or business models in line with purpose, and to design the capability shifts, organisational involvement and resulting brand experience

EDGY Depiction: Illustrated Style

When launching new products, it is often unclear how a vision or purpose translates into day-to-day operations. Teams may focus on isolated aspects — product features, supply chains, or customer touchpoints — without seeing how everything fits together. The Path View addresses this by showing a concrete flow across the Milky Way capabilities, in the context of the other facets: from purposes at the centre, through a root capability and its connected processes, all the way to the products, brands and organisations that embody the result in the customer experience.

Unlike the Overlay View, which compares perspectives, the Path View highlights one end-to-end thread. Other parts of the map remain visible in the background for context, but the main path is emphasised. This makes it possible to ask: what does it take for this product to succeed, and who and what must come together?

File:Milky Way Path View.png

A Path View Milky Way map answering the question "How might we enable made-to-order breakfast on our Night Trains?"

The starting point is the same base map used for the Overlay View. Instead of overlaying elements or metrics, it highlights the path along the capabilities it touches, as well as the context elements involved:

customer tasks to be served,
purposes to be pursued.

The view then adds further instances to highlight, such as:

products or brands positioned to support customer tasks,
organisational teams that pursue these purposes and build up the capabilities,
key assets, channels or content to be developed,
people involved or affected.

How to read

The Path View begins by marking the purposes to be pursued along the path, placed around the Core Story at the centre of the map. These purposes act as orientation points: for the Night Train, they might include "Sustainable products" and "Build trusted partnerships". Other purposes are still relevant, but not in focus for this initiative.

The path starts with a root capability directly concerned with one or more of these purposes. In our example, the root is "Product Portfolio Management", accountable for launching a new product: "Made-to-order breakfast on our Night Trains".

From this starting point, the path is traced outward through the connected capabilities that enable the offer.

In the Night Train breakfast case, the line runs through "Resource Management Material" as a secondary root, on to "Operational Planning" and "Station Management", then via "Product Launch" and "Marketing" to reach "Passenger Information", "Prepare Train" and "Train Restaurant".
Each step along this route highlights the specific contributions that need to work together to make the product real, and indicates the processes implementing these capabilities.
Not shown in this example are the assets required for this path, such as materials, data or applications – these could be added if they come into focus.

Along the way, intersection elements become visible:

Products are configured, such as the Night Train breakfast meal offer to be made available in the "Night Train" "Planning App" product still to be developed.
Brands are expressed, positioning the "NightXpress" brand as a sustainable, premium experience at the beginning of the customer journey.
Organisations are implicated, with our "Digital Team" and "Customer Experience Team" jointly responsible for the digital experience.

What might have been seen as "just" a catering option now appears as an end-to-end flow that cuts across the enterprise.

The Path View also makes clear how this product manifests in the passenger experience. It shows the link from operational capabilities in the background — sourcing local ingredients, arranging logistics, developing the ordering app — to what the customer actually sees and values: a custom breakfast, available on their journey, with the promise of quality and sustainability, highlighting the tasks served. It also lets you ask questions in sequence:

How do we source the food from local partners at each destination?
Who manages the logistics? Can our existing capability handle food items?
How is ordering integrated into the digital channels?
Who packages and prepares the food in the stations? Who serves it on board?
How do we capture and learn from customer feedback?

By following this highlighted path through the Milky Way, dependencies and potential weak links become visible. The root capability may rely on IT systems, supplier networks or service teams that are under strain, or still organised differently after the acquisition.

These issues, which could block the realisation of the product vision, can be surfaced and addressed. At the same time, the path reveals opportunities to reuse elements, such as "Logistics" or "Billing and Booking", for other parts of the business. It also lets us ask and discuss what's missing:

Do we need a dedicated capability for local partnerships and procurement to source the produce?
How do we trace emissions and environmental impact along the supply chain – is the "Customer and Market Analytics" capability sufficient for this?

A Path View thus presents not just a customer-facing idea, but the full operational thread that makes it possible. It is both a design tool for exploring new offers and a diagnostic tool for understanding what it takes to deliver them.

When to use

The Path View is most useful when an enterprise needs to make something new real — launching a product or innovation, testing a business model, or integrating newly built or acquired capabilities. Unlike views that show broad overviews, the Path View narrows in on one concrete flow and highlights everything it takes to bring it to life.

This makes it particularly relevant when launching a new product or service and needing to understand the path from strategic purposes, through capabilities, to what the customer experiences. For Intersection Railways, the Night Train food and beverage offer shows how something that looks simple to the passenger (a custom breakfast) draws on a chain of interconnected capabilities, from procurement and logistics to digital ordering and onboard service.

Other use cases include:

integrating an acquisition and seeing how new capabilities connect with existing ones;
exploring a business model shift, such as sustainable catering, and understanding its impact across the enterprise;
clarifying organisational involvement, showing which teams and partners are directly responsible along the path;
spotting gaps or weak links in the chain that might block delivery or dilute the customer experience.

In short, the Path View is best used when the question is not simply "what do we offer?" but "what does it take to make this offer real?"

How to make

Use the Illustrated Style to select colours, icons or labels that distinguish products, brands and organisations along the path – but consider alternative styles if this is too much effort.
Mark purposes: identify the purposes to be pursued around the Core Story.
Select 1–3 root capabilities: choose where your path starts, selecting capabilities directly linked to the selected purposes.
Trace the experience impact: mark the tasks to be served directly by the products to be delivered.
Trace the path: follow the connected capabilities on the inside-out base map that enable the product or service, and validate or iterate what is passed from one capability to the next.
Highlight the flow: fade out other elements on the base map to emphasise the chosen path and highlighted elements, keeping the rest of the map muted.
Add highlighted elements: show the products, brands and organisations that emerge along the path or as context, and position them on the map. Consider adding people, assets, content or channels if relevant to the challenge.
Note shifts and gaps: compare with the Overlay View to reveal where capabilities, teams or systems must change for the path to succeed.
Start with a small, concrete example (like a single product feature) before attempting an entire business model.
Keep paths simple and readable, and avoid mapping every dependency at once.
Compare multiple paths side by side to see where they share or compete for the same capabilities.
Sync this map with other related maps, such as a business model canvas, product roadmap or service blueprint.

Previous: Chart your galaxy of enterprise elements | Back to: Milky Way Map