TBM 310: Trees, Journeys, and Loops (and the Functional Model Trap)

After conducting hundreds of North Star workshops, I noticed a pattern. Teams (and functions) are often biased toward the capability view, journey view, or flywheel view, each with its pros and cons. By artfully using all these views—and embracing valuable variations—we can establish a much more resilient shared language across product, design, and engineering. This approach helps avoid the functional model silo trap.

Let's jump in.

Consider three model types: trees, flows/progressions, and loops/loop flywheels.

In cross-functional product development, these model types frequently manifest as capability trees, customer journeys, and growth loops. Each model has its strengths and weaknesses.

Capability Graphs/Trees

A capability is not a feature, design, opportunity, task, project, or product.  A capability describes the functional capacity or potential of a system, team, or organization to carry out a particular action or process—its "ability to _______." For example, "the ability" of a plant to thrive depends on, among many things, its ability to efficiently absorb water and nutrients, which depends on, among many things, its ability to regulate water absorption and retention. These relationships form "the tree" or graph.

By design, capability trees should endure. While we can notate today's way of solving or providing a capability, the core elements of the capability tree (ideally) last for a long time—this is almost inherent in their purpose. For instance, today, our method for providing expert support might involve connecting someone in need with a human expert, but tomorrow, we might use AI to address their customer support issue. The core capability remains the same.

For this reason, capability trees are useful for establishing a shared language that can endure over time. On the flip side, they are less effective for describing the present moment, such as your current projects, opportunities, or roadmap—although these elements can be added in certain ways (by combining a capability tree with an opportunity solution tree, for example). They also aren't necessarily very effective for understanding how customers and users traverse those capabilities to accomplish their goals, nor do they communicate capability evolution (where tools like Wardley Maps, which add a dimension of movement, can address that).

Note below how you can modify traditional capability graphs.

Journeys

Customer journey maps describe change and progression from your customer's perspective. Service blueprints, which also follow a left-to-right linear flow, describe how your customer interacts with various touchpoints in your company and the backstage services that enable those interactions. Event storming, a participatory activity rooted in domain-driven design, focuses on exploring the user's workflow to better understand domain boundaries, with the goal of architecting systems effectively.

A service blueprint:

https://www.emergeagency.com/insights/detail/service-design-blueprint-best-practices-examples/

An event storming activity:

https://medium.com/@springdo/a-facilitators-recipe-for-event-storming-941dcb38db0d

These methods have the advantage of grounding themselves in the customer (human) experience. While capability trees often become abstract and lack movement, a customer journey delves into the details of interaction by interaction, highlighting the complexity of that progression. A high-level journey, such as a standard marketing funnel, is marginally helpful but does not provide much value for making day-to-day decisions about improving the customer experience.

The key challenge with any left-to-right linear progression is that it risks oversimplification. People don't move in neat, orderly journeys. While you might indicate evolution using tools like user story mapping, where future iterations appear as rows beneath the "spine" of the journey, this adds another dimension.

Note how a user story map can have a Y axis indicating priority:

https://medium.com/i-want-to-be-a-product-manager-when-i-grow-up/user-story-mapping-dd7462ee78cf

Flywheels and Loops

Over the years, I've run numerous North Star workshops (I wrote a book about the framework). One thing I've noticed is that designers and engineers often end up with either 1) a capability tree, with the North Star indicating a capability higher up in the stack, or 2) a customer journey map, where North Star inputs align with key steps in the journey, and the North Star represents a critical step in the customer journey that signals the customer is deriving significant value from the product. 

However, something was often missing in these approaches—a fundamental premise for how the company would grow and a clear sense of the core "loop" that would retain customers, enable them to do more effective work and ultimately indicate sustainable, differentiated success for both the company and its customers.

Consider this flywheel from a grocery chain looking to modernize small businesses as part of an intricate flywheel to sell more groceries, waste less, enjoy network effects, etc.

In B2B software, you might be fine describing the jobs-to-be-done through a set of capabilities that reflect the underlying work of your customers. As your product grows more complex, you may need to consider customer journey as they evolve their skills and deepen their use of your product. However, none of these approaches fully capture the core hypothesis for a flywheel of success.

This is why it's important to also outline the flywheel hypothesis for your product—sometimes called the growth loop, customer success flywheel, or a similar concept.

For example, Miro might have a central hypothesis that early visual collaboration adopters will invite more people into workshops as they use their product. Over time, those users will deepen their engagement, encouraging even more people to join. Eventually, this creates a strong flywheel for visual collaboration, integrating with systems across the company and becoming mission-critical.

Stepping Back

Stepping back, we can see how these three model types and their potential variations can complement each other. Capabilities ground us in enduring, lasting language. The journey grounds us in the customer experience as they traverse the current iteration and solution for our capabilities, helping us plan improvements. A flywheel grounds us in a central hypothesis for how we'll grow sustainably to benefit our business, customers, and communities.

Each model shows relationships between things. Capability trees show how higher-level capabilities are enabled by or depend on lower-level capabilities. Journeys show how one step leads to another. Flywheels show how variables feed into each other, often in a loop.

The Functional Model Trap

If you think about these things in isolation, you run into trouble. I remember working with a "trio" of leaders:

• The Chief Architect had developed an incredibly complex capability graph for a domain. When I asked how customers actually experienced their model, they were confused—they hadn't considered that. They had a perfect model of the jobs to be done but hadn't really considered how any of it evolved or the customer experience.

• The design leader was heavily grounded in journeys and workflows. While they had an incredible sense of the customer experience, they lacked a deep awareness of the flywheel that would drive business success and hadn't really considered the core, enduring capabilities. The Chief Architect's model was unintelligible and didn't make sense.

• The product manager was well-versed in the flywheel hypothesis but hadn't considered the product's actual customer journey and experience. To them, growth was just a formula.

They had fallen into the functional model trap.

In solving the specific problem of their function, they had lost sight of the holistic forest through the trees. I've observed companies where the product or design org and the engineering org have their own core model. The models use completely different languages; they don't interact with each other, and no one speaks the same language. They do this because there's a lot of pressure on each org to produce something, and collaborating cross-functionally is difficult. Meanwhile, the business is searching for one simple model to rule them all, which doesn't really exist. As a result, without a viable alternative, the company uses metrics like revenue and NPS (a travesty of statistics and research).

This dynamic is why some of the variations mentioned above are so effective. For example, with event storming, we combine the customer journey or service blueprint with discussions that help architect systems. Or with Wardley Mapping, we layer in movement, evolution, and strategy on top of traditionally static capability trees (the kinds of trees that get turned into slides architects show that say everything but nothing simultaneously). You can also imagine a scenario where you layer flywheels on top of a service blueprint or add recursive lines or something similar to communicate the non-linear effects.

I think something like the North Star framework can unify these models to an extent. For example, you might use an input scheme that roughly maps the customer journey but has a North Star metric reflecting that the flywheel is working. Or, you could counterbalance inputs related to capabilities with those that reflect customer experience or a network effect.

That said, I always encourage teams to use as many helpful models as needed—just make sure the models use ubiquitous language and link to each other. 

Don't use frameworks mindlessly! 

Don't let one function run the show!

Avoid the functional trap!

Happy cross-functional model haping!