TL;DR – Rethinking org design with customer journey teams

Traditional org structures based on components often lead to coordination overload, unclear missions, and lack of ownership. This post argues for organizing product teams around customer journeys instead, enabling better alignment with real user needs and strategic business goals.

Key insights:

• Start with strategy: Business vision and customer journeys should define your org design—not tech artifacts.
• Focus on five principles: Business alignment, long-term team setup, clear KPIs, high autonomy, and strong collaboration.
• Component-based setups fall short: They struggle with mission clarity, KPI ownership, and user-centric thinking.
• Customer Journey Teams scale better: They enable end-to-end responsibility, reduce context switching, and foster strategic focus.
• Change requires buy-in: Involve tech teams early, expect a transition curve, and support the shift with shared goals and cross-functional formats.

Ultimately, org design must follow customer value—not internal logic. And yes, it’s a journey in itself.

What’s the deal with Customer Journey Teams?

In my article 4 Paths to Achieving Successful Product Leadership, I previously highlighted organisational development as a crucial skill for a Product Leader. The complexity lies in the challenge of Org Design, which should consider not only the product management function but also its implications on other areas.

Many expectations are placed on different forms of organisations, such as:

• the greatest possible autonomy for teams
• the best structure for career paths
• long-term stability combined with high flexibility
• clear ownership of technical artifacts

Everything is going well. Does that sound reasonable? No, it doesn’t. The most important part is missing, which is the customer for whom we are doing all this. The product management is responsible for identifying and solving customer and user problems across functions. An organisation is tasked with creating the best possible conditions for this.

I am not concerned with whether it offers my colleagues or me few, many, or even optimal career opportunities. Organisations are not built around individuals. People need to adapt to the organisational structure that best fits the demands of the market and customers.

Customer journey teams or not – 5 principles

Before I delve into my practical example, I would like to introduce the five most important principles for me when choosing the appropriate organisational structure:

1. The organisation follows the business:
   The product organisation must align everything it does with the business objectives. This applies not only to the content of the roadmap and strategy but also to the organizational structure. It is the responsibility of the product and tech leaders to ensure this alignment at all times within their respective business areas.
2. A long-term focus is essential:
   A team performs best when the following conditions are met: a) There is a clear mandate or a well-defined mission; b) The team setup remains stable over a longer period of time; c) The team focuses on a few high-priority topics and avoids frequent context switching.
3. A clearly defined and agreed-upon set of KPIs is needed:
   Derived from the mission and business goals, each team or department defines a set of KPIs (Key Performance Indicators) by which the success of their day-to-day work is measured. Creating a “KPI Tree” can help visualize interdependencies and cascading goals. A useful approach here is the North Star Metric Framework by Sean Ellis.
4. Maximum possible autonomy must be enabled:
   Teams work fastest when they have as few external dependencies as possible in order to accomplish their tasks. High autonomy is achieved through broad skill coverage. This goes beyond just Product, Tech, and UX—it may also include Business Development, Sales, Marketing, or Customer Service, depending on the size and nature of the domain.
5. Cross-functional and cross-team collaboration must be supported:
   While points 1–4 make logical sense, they also carry the risk of creating silos. Misunderstood autonomy can lead to conflicting goals and jeopardize a holistic view of customer needs. This is where leadership must step in—to provide the right conditions such as shared goals, rituals, and formats.

Case study – the customer doesn’t care about APIs.

The starting point

In a specific scenario, the product organisation was structured historically around technical components. For instance, one team handled the administration interface for professional sellers, while another team managed the technical interfaces (APIs) and integration of external tools. At first glance, this setup seems logical as it enables a clear allocation of artifacts.

On the flip side, we regularly faced the following challenges:

• High coordination effort:
  The teams constantly had to align their planning in order to roll out user use cases across both artifacts on time.
• Lack of mission:
  The teams were unable to define a mission or long-term mandate for themselves. One key reason was the lack of responsibility for end-to-end use cases from a user or customer perspective.
• Missing KPIs:
  Due to the absence of ownership for clearly defined use cases, it was nearly impossible to establish product KPIs or link them meaningfully to business goals.
• Frequent context switching:
  Since the teams’ domains were not clearly defined from a user and/or business perspective, projects were often assigned arbitrarily or based on resource availability.

The idea

We knew we needed to devise a different approach for dividing the teams. With the expansion of the product portfolio, it was necessary to facilitate future scalability and avoid the need to determine the best-suited team for each new project every time.

The progression towards customer journey teams

First thing to do is business strategy

We introduced the concept of Customer Journey and Jobs to Be Done early on in the product organization to foster customer empathy and generate new ideas. As mentioned previously, any realignment must always start with a business vision and strategy. These then inform both the activities and plans, as well as the organizational structure of individual functions.

The business strategy was developed across functions and in multiple workshops under the leadership of the responsible business developer. One of the key elements involved defining the strategic areas that the department should focus on in the next five years. As the customer journey became increasingly central, we defined these areas based on the customer processes identified within it. This ensured consistency in decisions and activities within the business unit.

Teams, get ready to run!

In the product team, we all agreed that a new organisational structure should align more closely with the strategic business areas and, consequently, with the customer journey. This decision was made on the assumption that it would clarify the business context and enable teams to more easily take end-to-end responsibility for customer use cases.

When the idea was presented to the group of tech and team leads, a sense of disillusionment quickly spread. The proposal seemed forced, leading the discussion to ultimately revolve around responsibilities for the technical artifacts that would come with such a change.

Take a step back

The idea itself was not the issue. Everyone agreed that our organization needed to restructure in the future. Our mistake lay in not allowing the tech teams to explore their own alternatives and consider the impacts on technical responsibilities. Following consultation with IT management, we rectified this and, through several sessions, devised a plan on how to proceed cross-functionally and in which specific steps.

The addition of new staff accelerated the transformation further as teams had to reorganise due to the increased workforce. The classic J-Curve effect and Tuckman’s team-building stages (Forming, Storming, Norming, Performing) were clearly evident. Gradually, the initial challenges were addressed, significantly improving organisational development principles.

The limits of customer journey teams

Every organisational model comes with its own strengths and weaknesses. Prior to making any changes, you must address the following questions:

• What about native platforms?
  The classic debate. As always, it depends—on how mature your native apps are and how closely their use cases match the web. If they’re still early or intentionally differ from the web, a small, decoupled team can help move faster. Either way, close coordination is essential, especially for cross-platform tracking and consistent UX.
• What if the focus shifts?
  Consistency is key for team performance—and strategy helps provide it. But priorities change. Whether due to internal shifts or external factors, teams must be able to adapt fast. Cross-functional experience and broad skills make that transition smoother and less disruptive.
• How do we avoid silos?
  Silos aren’t always bad—they can drive autonomy and speed. But they risk losing the big picture. To prevent that: a) build agile guilds or Communities of Practice, b) define a shared North Star Metric, and c) create a strategy rooted in the full Customer Journey and real user needs.

Conclusion

Whether you pursue a journey, funnel, or audience approach with your product organization depends on various factors. It is crucial to always strive to think from the user’s or customer’s perspective when making any changes to team structures.

You should involve the teams in the new mindset right from the start, even if it means taking extra steps. Only by engaging all departments will you secure the vital support for the change processes.

Additional links

• https://www.mckinsey.com/industries/financial-services/our-insights/ings-agile-transformation
• https://dandypeople.com/blog/the-customer-journey-product-organization/
• https://www.infoq.com/articles/magic-customer-journeys/

Book recommendation

Click, buy, and enrich me – my literature recommendation on the subject and an enlightening read on agile frameworks using Spotify as an example: Successful with the Agile Spotify Framework: Squads, Tribes and Chapters – The Next Step After Scrum and Kanban?

Hero image: Rügen (Germany) by Martin Heckmann