Drew Barontini

Product Builder

Issue #73 •
• 15m read

Product Landscape

Product roadmaps are important artifacts. They help you identify opportunities and directions you can move in; they summarize initiatives; they help you visualize who is working on what and when. Roadmaps are a sequencing mechanism. They help you plan against time, answering the most often-asked question in the product world:

When is it going to be done?

But there’s also a parallel domain where a different kind of planning takes place. A space where you consider orientation and location. Instead of the what, the why, and the when, you consider the where. Software exists in the digital realm, but what if it was a physical space instead? I like to think about a software product as a space to inhabit, to live in. You can imagine a product like a house. There are rooms and floors to separate distinct areas; and there are doorways, hallways, and steps to move throw the rooms and floors. You’re taking a two-dimensional object and representing it in three-dimensional space.

In the book Moonwalking with Einstein, Joshua Foer learns how to improve memory and compete in memory competitions. And the idea is rather simple: humans remember complex information best when it’s placed in a physical space you can mentally walk through.

Another term for this technique to improve memory recall is called the “Memory Palace.” It’s what the fictional character Sherlock Holmes does when he effortlessly recalls specific details from any point in time. He places information in a mental representation of a known physical space (what he refers to as a “Mind Palace”), which makes recall much easier. It’s like having a storage unit to safely house important information you need.

The roadmap is an abstract list. It’s static and fixed in a digital space. But conceptualizing a product in a physical environment? It’s dynamic and elicits a deeper connection, allowing you to conceptualize the product space in a new way. Mental models are wonderful tools for improving perspectives.

This idea is called the Product Landscape, which lives in the Clarity Codex of the Claritorium and Strategic Momentum of Equilio.

The Product Landscape is like a memory palace for your product strategy.

The three pillars are:

  1. Regions: The main areas of your product, like the rooms of your house.
  2. Zones: The more specific sections of each Region, like parts of a room.
  3. Context: The specific context expressed within Regions and Zones.

Regions

If the product is like a house, then the rooms are the Regions. They are significant spaces where complexity clusters.

Every product has unique and specific Regions, but there are also common ones, too:

If you imagine your product like a house, walk through it. What do you see? Really visualize the spaces users spend time. These are the core Regions of your product. And, like a house, some are more important than others because they are used more often. You probably spend more time in your kitchen than your garage. That’s natural. But it also informs how much time you spend maintaining and improving that area, too. Products are no different. Each Region of your product requires care, attention, and unique consideration.

We just remodeled our master bathroom. It was 15 years old, had mold in the shower, and a lot of outdated fixtures. My wife is a deep cleaner, and she kept it functioning as well as possible, but we knew it was time. So we decided to make the investment of time, money, and energy to upgrade it. When you work on a product, this happens, too. A part of the product is used regularly, but is constantly causing issues. Users report bugs and the engineers keep applying band-aid fixes. The team knows it’s only a matter of time before disaster strikes and it stops working. We were terrified the mold was behind the tile and spreading (it wasn’t; thanks to my wife’s diligent efforts to clean it). So you make a similar investment of time, money, and energy to rebuild part of your product. At times, you wish you could just rebuild the entire product, like demolishing your house and starting from scratch. But this isn’t always feasible; nor is it generally the best option.

Seeing and understanding Regions is how you visualize the Product Landscape.

Ultimately, you ask yourself:

What’s worth the investment of time, money, and energy right now?

When you think about the Regions of your product, you need:

  1. A steward to take care of it.
  2. An understanding of the priority.
  3. Knowledge of its use and current state.

Steward

Every Region needs someone who cares for its coherence over time. This isn’t an owner or a bottleneck—they’re someone who maintains the continuity and integrity of the Region. They watch how it evolves, notice when it’s under strain, and advocate for attention when it’s needed. For most Regions, this is the role I play. And you probably have (or are) a product person performing this role. The entire team should think about the product this way. You live in it, use it, and work as a cohesive unit to maintain the standard of quality.

Where you can, assign a member of the team to be the Steward of a Region. It’s a responsibility of attention, like a gardener caring for and nurturing the plants to maintain a healthy environment for them to flourish. And, as AI grants more power to Product Builders, being a gardener or architect becomes a realistic analogy. You’re watching and orchestrating efforts instead of getting your hands dirty in the soil or constructing the buildings. A Steward operates with intention, intuition, and integration.

Priority

Every product has a set of core areas. And there are also supporting and peripheral areas, too. Just like you spend more time in parts of your house, your product Regions are used differently in terms of frequency.

There are three priority levels of Regions:

  1. Core Regions are the key areas of your product. They’re where you focus most of your resources, and they garner the most use and attention from users.
  2. Supporting Regions are still critical, but play a supporting role in your product.
  3. Periphery Regions are areas of the product where less-used features reside.

The same is true in a house. Our master bathroom is a Core Region, which is why we invested resources to improve it. But there’s also a lot of little problems on one of our patios. Given this is a Periphery Region, the priority is much lower.

Let’s not think about that until after we deal with the bathroom.

We said this countless times. When a Core Region is under duress, you can’t expend any resources on other, lower priorities.

When you make decisions about your product roadmap, knowing the priority of the product guides you in making the right trade-offs.

Load

Knowing the priority of a Region is one thing. You also need to understand the current state, which is what I call the Load. It tells you how much it’s being used, its behavior, and what pressure it’s under at the present moment. It fluctuates over time and with usage. Our bathroom had a problem with mold while using it every day. That increased the mold and the time required to keep it at bay. The increase in pressure of the Region is where the Load increases. It’s a delicate balance to manage the tension and maintain the equilibrium of your product (or house).

For a product, Load can mean a lot of things:

Priority expresses how important a Region is, but Load expresses how stressed it is.

There are four levels of Load:

  1. Low Load = stable and quiet
  2. Moderate Load = active but manageable
  3. High Load = sustained pressure
  4. Critical Load = strained or overwhelmed

And for each one, there’s a set of attributes to assess the state of the Region:

  1. Issue Volume: The amount of friction accumulating in a Region over time.
  2. Change Frequency: How often a Region is being modified or touched.
  3. Cognitive Complexity: How difficult a Region is to understand, reason about, and change safely.

Low Load

A calm, stable Region. Healthy, but easy to overlook, especially for Core Regions.

Moderate Load

A healthy, active Region under control.

High Load

A Region under sustained strain.

Critical Load

A Region requiring intervention, not iteration.

Zones

The master bedroom is a Region, but the bathroom is actually a Zone within. Zones are focused sub-areas within a Region. They tell you where work and complexity actually live inside a Region. We didn’t have any other problems in our bedroom other than the bathroom. It was isolated. The pressure accumulated in the bedroom (Region), but the bathroom (Zone) told us where the pressure came from. Regions and Zones are not features. They are where features live.

Zones have three components:

  1. Function: The role the Zone plays.
  2. Complexity: The mechanics of the Zone.
  3. Dynamics: How it changes over time.

Function

The function of a Zone is its job. Each Zone needs a clear intention—the reason it exists and stands out within a Region.

The key question is:

What role does the Zone play inside the Region?

The bathroom plays an obvious and important role in a bedroom. For a product, an example Zone would be data storage within the Infrastructure Region. Its job is to store information as part of the infrastructure of the product. Keeping data safe is essential.

Let’s say there’s a Critical Load in your Infrastructure Region. Your product is slow, causing timeouts and reliability problems. You can’t address the problem without isolating the root cause. Where does the problem live? It could be anywhere in the Region. Knowing your Zones and their function is how you focus your resources in the right direction.

Complexity

Like the Cognitive Complexity of a Region Load, the complexity of a Zone tells you why the work needs to be isolated. What are the edge cases, dependencies, and coordination costs required to change the Zone? If there’s no real complexity, it probably doesn’t need to be a Zone. Be mindful of where you draw the lines within a Region.

The key question is:

Why is this part of the Region hard to work on?

An example Infrastructure Region might have the following Zones:

Zero in on areas within a Region where complexity emerges. Those are Zones.

Dynamics

The dynamics describe how the Zone tends to change over time. Some Zones are volatile and change constantly; others are more stable and require limited changes. Understanding dynamics is how you effectively plan, resource, and iterate on the Zones.

The key question is:

How does this Zone tend to evolve?

Taking the Data Storage Zone as an example, what are the dynamics at play? The Zone doesn’t change much, but when it does, it requires focused intention because it has a massive impact on the product. If there are data storage issues or downtime, you’re in a very bad spot. We just migrated to a new database, which took a lot of planning, research, and careful orchestration to complete without negative side-effects. And, even with all that planning, we still needed to fix a handful of issues after. The same was true when we changed another part of the Infrastructure Region. Such is software.

Zone Dynamics describe the cost of change over time. We can place them in one of the following categories:

  1. Cumulative: Changes stack over time and are difficult to undo.
  2. Volatile: Small changes can produce outsized or unintended effects.
  3. Spiky: Long periods of stability punctuated by sudden stress, load, or failure.
  4. Fragile: Mistakes are costly, and the recovery is painful.
  5. Stabilizing: Changes reduce future complexity and risk.

And here are some examples of each:

Context

About 20% of our traffic comes in through mobile. The product is responsive, but I wouldn’t call it mobile-optimized. So when I started to see a lot of issues on mobile, I took a deeper look at priorities.

Mobile is an example of Context, which describes the conditions under which a Region or Zone is experienced. They don’t define where the work lives like Regions and Zones. They define when, how, and for whom that work behaves differently. This is the final piece to enable precise language for your product.

There are three types of Context:

  1. Surface: The interface or medium through which the product is accessed. It answers where is this being experienced? Examples include web, mobile, and API.
  2. State: The condition of the user or system at the time of interaction. It answers who is experiencing this, and under what conditions? Examples include anonymous users, trial vs. paid, and new vs. returning.
  3. Mode: The user’s intent or posture while interacting with the product. It answers why is the user here right now? Examples include exploration, execution, and evaluation.

Context imbues meaning. It enriches the dialogue with your team. I was talking to a colleague about a core experience. They used the product as an anonymous user on their phone, and called out several friction points in the experience.

Pause here. What’s the landscape?

The Anonymous Mobile Assistant Response is a clear, specific, intentional definition. Saying it this way communicates structure in language.

Using the language of the Product Landscape helped identify the focus. Through the discussion, we realized it wasn’t just about Mobile, so we generalized it to the Anonymous Assistant Response on mobile and desktop.

Context is the precursor of clarity.

Principles

You know I love principles. Simple, evergreen heuristics reduce rigidity and expand understanding. So what are the principles of the Product Landscape?

  1. Start small and expand. You don’t need dozens of Regions, Zones, and Contexts immediately. Start small and expand as the product and your knowledge grow.
  2. Mind the signals. Once you tune into the landscape, you see more signals pointing at Regions, Zones, and Contexts. Pay attention to sense them.
  3. Progress, not perfection. The landscape can and should evolve. Regions expand and collapse; Zones emerge; Contexts change over time. Nothing is static.

Practices

These practices are examples of tactics I’ve deployed to integrate the Product Landscape in my standard process. They’re expressions of the foundational principles.

  1. Issue Taxonomy: In Linear, I created label groups for Regions, Zones, and Contexts. Then I applied them to every issue in the system. Now there’s a detailed taxonomy we can filter, visualize, and measure the flow of work in the landscape.
  2. Roadmap Classifications: I created the same structure in the product roadmap spreadsheet. Every bet (project) ties to a Region, Zone, and/or Context. Doing so helps visualize work beyond time, but at the level above the issues.
  3. Product Walkthroughs: Once the landscape is in place, you can meet and walk through parts of the product. Use the language you’ve defined to call out issues, fragility, and opportunities for making the product better. Think of it like walking through a physical space. What areas need attention?

The Throughline

Understanding the landscape of your product creates a new perspective, a new dimension to think about what you work on, when, and what sort of investment you should make. More than that, you create a language to improve your team’s dialogue. When someone uses intentional terminology—and the team shares in the understanding—communication improves and signals emerge. The work takes on clearer meaning when you think about the space the work inhabits, not just the sequencing of projects on a timeline.

Regions tell you where to look.

Zones tell you where to focus.

Contexts give them meaning.

A product roadmap is a strategic output.

The Product Landscape is a strategic input.

Better inputs create better outputs. And context unifies the whole.

Now, go forth and discover your Product Landscape.

Clarity Codex Strategic Momentum

Enjoying this issue? Sign up to get weekly insights in your inbox: