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:
An event storming activity:
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:
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!
Hi John, you touched a nerve here. I can probably add my two cents from the EventStorming perspective.
Especially in Big Picture, the tension between the linear left to right storytelling is real. While I ask participants to *try* placing all the events on a timeline, I also know that assuming left to right is a naive illusion. ...But *trying* to put all the events on a timeline is a fantastic conversation booster: the shortcoming of the linear journey mode become evident to everybody, and we invariably start rearranging the layout to accommodate for feedback loops. We still forbid arrows that tend to calcify the model, but we make returning customers, strategy adjustments and so on progressively more visible.
The underlying problem is more related to geometry than to the methodology: EventStorming goes a lot more in detail, in terms of granularity, but then we'd need a very oddly shaped room to have loops from the beginning. User Story Mapping is even more rigid because it's fixed horizontally and vertically.
I usually tend to start from EventStorming because it provides a stable detailed ground for further explorations, Wardely Maps, Ecosystem Maps, Causal Loop diagrams. One perspective can support, not replace the others.
And 🙌 on "ephemeral": some formats are designed to provide the insight, no to be long lasting blueprints.
The challenge in working with all three models is that more collaboration and coordination is needed. More meetings, more documents, more communication… more of the stuff that seems like a waste of time but is essential to moving forward. Ashby’s law at play.
Most PMs just want ship software.
The two ideas are not mutually exclusive, I am reflecting on the necessity of all this processes that you can’t rush just so you can successfully “ship software.” Sigh…