Thinking at Every Scale

The Anatomy of Product Thinking, Part 2: Seeing the system in parts and wholes

In our last issue, we worked on demystifying what it means to have good “product sense.” In summary, product sense is an intuition for making judgments founded on experience, careful attention, and the process of accumulating observations into useful, reusable patterns. Product sense isn’t magic; you develop and refine it through practice.

In this piece we’ll discuss the second quality of product thinking: the ability to move between scales — to see a product as both a collection of discrete parts and as an integrated whole.

In this series we’re exploring the Anatomy of Product Thinking in four parts:

• Part I: Developing Product Sense – how observation, experience, and reflection generate pattern recognition we often call intuition

• Part II: Thinking at Every Scale – how product thinkers work at different scales, hold details and the wider product system in view simultaneously, and trace the causal relationships between parts

• Part III: Setting Boundaries, Making Tradeoffs – how to draw boundaries around problems, make tradeoffs, and find powerful points of leverage

• Part IV: Creating Sustaining Loops – how they turn solutions into self-sustaining, complementary advantages for both customer and the business, where customer and business value reinforce one another

A product is more than a collection of features. Between its individual elements are data flows, feedback loops, incentives, business consequences. The relationships between parts stitch them together into a working system.

Seeing the parts clearly is necessary. But if you’re not seeing how they fit together to form larger subsystems, you’re missing the forest for its individual, isolated trees.

---

Product thinking is systems thinking

Donella Meadows offers a useful starting point. In her book Thinking in Systems: A Primer, she defines a system as:

“an interconnected set of elements that is coherently organized in a way that achieves something.”

Every system consists of “elements, interconnections, and a function or purpose.” Systems thinking, then, means looking beyond individual parts to understand how their relationships and purpose produce the system’s behavior over time.

A product can be understood the same way. Its features are the visible elements. But its behavior comes from how those elements are connected — through workflows, permissions, data flows, and incentives — and from the outcomes the product is organized to produce.

For product teams, this creates a constant tension between the ground-level problem in front of us and the larger system producing it.

Suppose customers repeatedly ask you for the ability to share reports with coworkers. At ground level, the request seems straightforward: add a Share button.

But the observed request may be only the visible edge of a larger problem. Perhaps managers cannot access the product (or don’t want to log into another tool). Perhaps customers export reports and send them as attachments. Perhaps review and approval happen through email because the product supports individual work well, but not cross-org coordination.

Solving the immediate problem well is valuable, but product thinking asks what produced the problem, what else it touches, and whether fixing it will change the outcome we care about.

Someone thinking only at ground level might ask:

Where should the Share button go? What should it look like? Who will build it? How long will it take?

Those are necessary questions, but they are incomplete. Pulling up a level produces a different set:

Who creates the report, and who receives it? What happens after it’s shared? Can the recipient act on it? Does sharing bring more people into the product, or move the work elsewhere? What customer or business outcome are we trying to create?

In my definition, product thinking is about holding multiple contexts in your mind simultaneously; you observe problems on the ground, but must go abstract and zoom out to look for threads, causal chains, decision trees that connect to the observed problem.

Adept product thinkers are systems thinkers, able to see wholes in addition to parts, and how those parts interact to form larger systems. They can navigate between the mechanics of a particular interaction to the workflows surrounding it, and from those workflows to customer outcomes and the strategic Big Picture. And importantly, they can follow the causal chain in both directions.

Three altitudes

We can look at systems at three scales, or altitudes:

• Micro — the individual controls, screens, messages, interactions, moments of friction

• Meso — the workflows, roles, rules, permissions, defaults, and data flows through which individual actions become coordinated activity

• Macro — the customer outcomes, product strategy, market position, business economics the system produces over time

Consider the report-sharing example at each altitude:

At the micro level, we see a Share button, recipient field, access controls, notification settings, and the UX of opening a link.

At the meso level, we see a review process. One person creates a report, another receives it. Someone requests a change, another person approves the final version. Permissions, account boundaries, policies, and alerts determine whether and how that process can actually happen.

At the macro level, we see reviews happening faster, with less manual re-entry and less confusion over which version is current. The product becoming a part of the org’s operating rhythm. More people have the chance to realize its value. Work and organizational knowledge accumulate inside it. The account becomes more likely to stick around and expand.

Product thinking requires fluency at each level. Different roles rightly focus attention on different altitudes. Engineers zero in on technical integrity and implementation details. Execs care about direction, positioning, economic outcome. Designers, salespeople, and support reps each encounter a different portion of the system.

The product thinker’s job isn’t to replace those perspectives, but to connect and reinforce them.

The missing middle

Teams often jump from an ambitious strategic objective straight down into a list of features.

Make the product collaborative.

Great idea! From there, it’s easy to generate individual parts: sharing, comments, mentions, notifications, feeds.

But these features do not guarantee “collaborative.” The stated strategy connects to the product’s interface through the meso layer: the roles, relationships, and workflows that determine how the collaboration actually works.

• Who creates the report, and who receives it?

• Is the recipient already a user?

• How do they get access securely?

• Will policy allow them access?

• Is the shared report a static copy or a living object?

• Can the recipient interact with it?

• Does the sender get any feedback?

• What brings everyone back after using it the first time?

Each question ties to implementation details, but together they describe the operating structure through which collaboration generates value. If that structure works, customers can coordinate more easily. And those gains can compound for both the customer and business.

A Share button alone does not make a product collaborative. But a securely accessible, always-current report that lets recipients respond without setup friction might create a recurring review workflow. That workflow can bring additional people into the product, make it part of the organization’s routine, and ultimately increase retention and expansion.

Micro decisions rarely produce macro outcomes directly. They do by way of the workflows, behaviors, and relationships at the meso level.

Keeping the arrows intact

Our goal is not simply to be more comfortable in leadership strategy sessions, or more conversant in the engineering design meeting. Product thinkers need to be able to trace causal links between contexts.

Real business impact comes from well-made, coherent wholes, not disjointed individual features, or from strategic vision concepts — wholes without specifically-outlined components that make them work.

Yet comfort with each scale is not enough. A person can discuss interface details in one meeting and retention strategy in another without knowing whether one has any meaningful connection to the other. Product thinking means keeping the arrows between those scales intact. Without the ability to follow the arrows, we have no way of knowing what intervention moves the right needle.

We should be able to trace a proposed intervention upward:

Share control → accessible report → recurring review workflow → faster decisions with less rework → product embedded in account → retention and expansion

And, conversely, we should be able to reason downward:

Increase account expansion → spread value to more stakeholders → create a recurring collaborative workflow → support sharing, access, response, and notification

Tracing the links upward prevents narrow, isolated feature thinking, while downward prevents strategy from remaining a vague theoretical.

Each arrow represents a hypothesis.

Will easier sharing actually produce a review workflow? Will recipients participate without becoming full users? Will that participation bring work back into the product? Does greater account participation really improve retention?

A causal chain can sound plausible without being true, or even possible for that matter. Strong product thinking investigates these assumptions between levels, through questioning, testing, refining.

This also shows why the exact shape of a feature matters. A static PDF doc may technically allow sharing while moving the collaboration into email. Requiring a paid seat may stop recipients from opening the report. Missing notifications may prevent a response loop from forming. Weak permissions may make regulated customers unwilling to share anything at all.

The macro outcome depends on a half-dozen seemingly small decisions working together. The functional whole emerges from the relationships among the parts.

“Feature thinking” asks what needs to be built. “Strategic thinking” establishes the outcome we want. Product thinking finds (and tests) how we connect the two.

Keeper of the context

Different functions involved in making a product each have legitimate but partial views of the system:

• Engineering: technical integrity, constraints

• Design: quality user interaction

• Sales: buyer demand, competitive pressure

• Support: recurring customer pain

• Finance: sustainability, cost

None of these perspectives is wrong, but each presents an incomplete picture. We get problems when information crosses boundaries between them, and suffers from context rot along the way. You sometimes end up with mistranslations, missing emphasis, poor explanation.

Imagine that a customer tells a support rep:

“I export the report, email it to my manager, and then manually copy her changes back into the system.”

Support notes that customers want editable reports. Then sales hears it as PDF editing blocking deals. The request reaches the roadmap as “build a document editor.”

At each handoff, the statement becomes more concrete but less complete. The original context — a broken review-and-approval workflow — gradually vanishes. Like playing a game of telephone through the company.

A product thinker preserves that context as the problem description makes its way around the team. They recall that the request for PDF editing began with a workflow, that the workflow shapes customer behavior, that the behavior affects how deeply the product becomes embedded, and that embeddedness has consequences for retention and expansion. Their value to the team doesn’t require them to own every piece of information, but to keep the arrows between the pieces intact.

That doesn’t mean flattening legitimate disagreements into a false consensus. Engineering constraints still exist, and sales objections are critical, and support’s account of the customer’s pain remains a useful data point. The product thinker’s synthesis should help resolve these tensions. The team should better understand what it’s actually making a tradeoff between.

Great product thinkers are keepers of context. They gather the perspectives, connect them, add legibility, and return to the team with a more complete picture.

Being the keeper of context is different from being its owner. The knowledge shouldn’t live exclusively in one person’s head. Product’s responsibility is to help the organization retain and use that context as work moves between people and functions — and between scales.

Seeing the whole, without losing the parts

In sports, certain players are described as “glue guys.” They don’t dominate every phase of the game, but they connect players’ individual strengths and help the group function as a unit.

The best product thinkers play a similar role. They connect strategic intent to operating workflows, workflows to behavior, and behavior to the small interactions from which it emerges. They help specialists understand how their local decisions contribute to (or undermine) the larger result.

To see the whole doesn’t mean rising above details. It means understanding how the details become a complete whole.

---

Make sure to follow along in our series on The Anatomy of Product Thinking. Look out for part 3 next week, in which we’ll look at how product thinkers draw the right boundaries around problems to solve. If you missed it, check out part 1 on understanding “product sense”.