We began our series on Product Thinking by investigating the mysteries of having good “product sense.” What does it mean to have an adept mind for working on products? What looks like intuition is often accumulated judgment: recognizing the shape of a problem and understanding the forces behind it.
In part 2 we looked at how product thinkers are comfortable working on different scales, from the level of individual features, up to customer value, business outcomes, and even go-to-market approach. Great product minds can trace the relationships between those scales.
Together, these skills help us understand what we’re looking at, with a discerning eye and enough experience to make balanced decisions. Having a clear picture of the product as both a collection of connected individual parts and a comprehensive functioning whole gives us a solid foundation. But understanding a system leaves us with a practical question: where should we intervene?
The Anatomy of Product Thinking Series
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
When you identify a problem and follow where it leads, you always find more to consider. A request for easier report sharing leads to questions about access, review processes, permissions, and organizational habits. Asks for better search lead to questions about how content is organized, what users are looking for, and whether the thing they need exists in the product at all. Each connection reveals useful data. Yet we have limited resources, and some changes will do much more than others to reach the outcome we care about.
How do we know where to focus effort so that it makes a meaningful difference? We need to frame problems clearly enough to establish what we’re trying to accomplish, then shape an approach that can accomplish it within the constraints we face.
In this third essay, we’ll examine that judgment through boundaries, tradeoffs, and leverage. How do we draw a boundary that keeps the problem manageable while preserving what’s necessary to solve it? Which compromises can we accept? And how do those choices help us find the places where our effort will have the greatest effect?
Bounding the problem
A few years back I wrote a piece called “Hard Edges, Soft Middle,” in which I argued for setting constraints around problems, and not on solutions. The ideal path is to be clear on the goal, but loose on techniques to achieve it. I argued that many product teams invert where they impose constraints:
Setting a hard edge with a soft middle defines what the field of play and game plan look like, but doesn’t prescribe for the team what plays to run. The opposite model has a team hung up on specific play calls, with no sense for how far there is to run, or even how large the field is in the first place. When you grant the team the freedom to make the tactical choices, everyone knows there’s some freedom, but it isn’t infinite. The team can explore and experiment to a point, but doesn’t have forever to mess around.
When we identify a problem we want to solve, the first thing we have to do is define, crisply and directly, what we understand the problem to be, and why it deserves a solution. Not in a casual way, but clearly and with enough conviction that we can articulate it in writing. We want to lay out our best understanding of what the problem is, why it’s a problem, and critically, how much it’s worth to us to solve.
This what/why/how much triad defines the hard edges. Once we have confidence in our understanding and are clear about how much we want to invest, we have a detailed outer boundary. Then we can move to the middle.
The “soft middle” is the how of our solution, the specific shape and form of what we come up with to address the problem. With the outer limit clearly circumscribed, we now have an open space to explore, within which to experiment and search for workable solutions. And that “softness” is important to keep engineers and designers relatively unfettered, free to explore the solution space for the right fit.
Mediocre product teams violate this principle. They don’t do the up-front work to articulate the hard edges. The problem has this vague, hazy outline, making it difficult or impossible to verify whether any solution even solves the problem well — after all, they don’t even have a concrete description of what the problem is. So the tail starts wagging the dog. They let whatever solution they build define the problem. In the worst cases, the hazy edge is made worse by overly-rigid preferences for solutions. Maybe the team’s got a technical tool / library / feature they want to build, and they’re eyeing an opportunity to shoehorn it in. If the problem space is poorly defined, the rigid solution chooses the problem for them (and spoiler: it’s rarely one anyone needed). The hazy boundary allows too much play in the system. Too many options are on the table, and the organization has a harder time holding the line on what options go too far, when there’s little to no line to begin with.
This is why the how much factor is so critical for a concrete problem definition. In Ryan Singer’s Shape Up, he calls this the “appetite.” Every problem you choose to solve has some range of value; a solution is worth something, but there’s a logical limit to its value. That’s why it’s essential to factor this into the boundary. Leaving the edges fuzzy is how you end up 3 weeks into the work, to only then discover that the thing you were willing to grant 2 months to is about to take 6. Now you’re in the uncomfortable position to choose between hitting the brakes to recalibrate (possibly tossing out those 3 weeks spent so far), or to let it go, and throw good money after bad. Appetite-setting is essential to avoid sunk cost temptations.
Making tradeoffs
Defining the problem and appetite provides a basis for comparing solutions. Several approaches might fit inside the boundary, but each spends resources differently. One might get the customer to a useful result sooner. Another might take longer but make future work easier. We need to understand what we’re gaining and giving up with each.
This is the work of shaping: getting specific enough about an approach to examine those consequences. The frame gives us something to judge them against. Does the added work materially improve the outcome we’re after? What would we have to postpone to make room for it?
In talking through options, an engineer might propose building a reusable library or a more complete API alongside the feature we need today. We could take a narrower approach and deliver the feature sooner. Or we could invest in the broader foundation now, delaying the immediate benefit in exchange for unlocking future capabilities. Both approaches have a cost. The question is whether the future gain justifies the near-term trade.
When we also want to prioritize a future benefit, we need to account for the future investment required to realize it. How likely are we to pursue those uses? What else has to happen before they pay off? Building the foundation is only part of the commitment. The case gets stronger when we point to likely uses and explain how the work would make them cheaper or easier. It gets weaker if we’re only leaning on theoreticals with “we might need it someday.”
The when matters, too. A company with twelve months of runway has limited room for investment that takes five years to pay off. Sometimes prioritizing a feature for a single target customer generates the revenue in the short term to keep building. With comfortable cash flow, we can afford more bets.
This is where seeing across scales becomes practical. A product thinker connects the implementation choice to the big picture business conditions that make it worthwhile. We need enough conviction in the long-term direction to invest in it, and enough realism about the current situation to recognize when something more immediate deserves our attention. Either path carries a cost. The product leader’s job is to understand the gains, what’s being postponed, and why the exchange makes sense.
Understanding those costs helps maintain focus on the most worthy problems. A change to one part of the product may improve outcomes elsewhere in the system — and sometimes those wider cascading effects turn out to be of even greater value.
Finding points of leverage
Some product work offers far more return on your effort, where a relatively small intervention delivers outsized reward. A minor change might improve an entire workflow, or help people discover something they otherwise never would’ve encountered. We’re looking for these pressure points, spots where a focused investment produces wider benefit.
You’ll have a hard time finding points of leverage without a clear picture of the complete product (the systems thinking we explored in part two). You need to understand how the effects of a decision travel through the system, to be able to trace threads to secondary and tertiary benefit, not simply the 1-to-1 direct value of the feature.
We encountered a great example of product leverage in the early days of Fulcrum (pun only somewhat intended).
Around late 2012, we were attracting a diverse audience of users and use cases. Many of them were less technical, and needed better onboarding to the product’s use and best practices. As an early innovator in the “low-code / no-code” product space, Fulcrum built the tools for customers to create out their own field data collection forms digitally. It offered a palette of tools and building blocks to pick from (data types, configurations, settings), and a canvas on which to build a custom solution. Some users would jump in and get it right away, and others needed a bit of nudging in the right direction. So we started making templates to demonstrate ways to use it, and to help get people going without the blank-page problem. The first version of the “App Gallery” went live.
We wanted to give users something recognizable to start from, so we created templates for hundreds of use cases: pole inspections, storm drain surveys, asset inventories — templates that covered many markets and uses we were seeing with existing customers. We didn’t expect each one to be a turnkey solution to immediately hand to a field team, but as a starting point to build on and customize.
To this end, the Gallery was hugely beneficial as an onboarding resource. But an even bigger benefit came from an adjacent decision.
We’d built out a backend infrastructure that let us publish a dedicated web page for each template, so visitors could browse examples of what Fulcrum could do on the website, without signing into the product yet. We knew there was additional value in this idea, but we underestimated how much.
Customers weren’t necessarily looking for a generic data collection platform when they ran across Fulcrum. They were searching for a utility pole inventory form, or a way to inspect underground utilities; they had a narrow problem to solve. Our hundreds of domain-specific templates gave those searches relevant landing pages to hit, and these individual page listings became many users’ first encounter with Fulcrum.
As we saw visitor traffic climbing, we directed more attention to SEO and acquisition. Eventually, our understanding of the Gallery’s primary purpose flipped. We came to see it mainly as an acquisition channel, with the teaching function still useful but secondary.
We found leverage in the connection between those uses. Work we were already doing to help existing users also helped potential new ones find us.
We had to look beyond the feature’s role inside the app to recognize that, and we had to be willing to revise our original assumptions. The initial problem scope gave us a boundary to start with. In shaping our approach, we chose a path that made us easier for customers to find, in addition to the core goal of user onboarding.
There’s still a tradeoff to examine here. It’s easy to convince yourself that something is worth doing because it promises several benefits. But depending on what you uncover in the shaping process — each tradeoff and its benefits — it can be tempting to scope-creep and fund things too divergent from the initial goal. The search for leverage has to stay, as best you can, somewhere inside the initial boundary. In the case of the App Gallery, we identified a way to open up that SEO opportunity without much work we didn’t already intend to do in the first place.
Recognizing this opportunity required an understanding of both the product’s onboarding gaps and knowledge of how potential customers found us. We needed awareness of the customer acquisition funnel and some principles of inbound marketing in order to spot the opportunity. Without that wider lens, we may have been too myopic in our implementation to realize the leverage.
Choosing where to intervene requires a wide view and a willingness to narrow your attention.
A clear boundary gives you a place to work and problem to solve, and sound tradeoffs keep you honest about the value of your investment. But you also have to watch what happens. With Fulcrum’s App Gallery, understanding the wider system helped us recognize value beyond the original goal.
Once you’ve found leverage, there’s another important question: what keeps the value coming?
In the final essay, we’ll look at how product thinking focuses on sustainability. As product leaders, we want to find opportunities to create sustaining loops. If we can help customers accomplish something valuable, it strengthens the business, which, in turn, makes the product more valuable to its customers. Those reinforcing relationships can give an intervention a life well beyond the work required to build it.
Make sure to follow along for the final entry our series on The Anatomy of Product Thinking. Part 4 is coming next, where we’ll tie together everything we’ve learned and look at how to create a sustainable “product machine.” If you missed the earlier posts, check out part 1 on understanding “product sense”, and part 2 on thinking at different scales.
Intuition as accumulated judgment rings true, and tradeoffs are where that judgment shows most. What helped me was practicing tradeoff questions out loud until the reasoning felt natural. Disclosure, I built allthingspm.app, and its free PM question bank has plenty of those to work through.