“Know the problem you are solving” is about knowing the specific problem and for whom this problem exists. It isn't about knowing what solution a persona lacks but about truly understanding a persona's needs and challenges. When you can focus a team on solving a problem rather than implementing a solution, you get more creative and innovative solutions. Oftentimes you discover that there are easier ways to solve the problem and the solution you thought was needed might never get built, but the problem still gets solved.
From a request for comprehensive authentication and authorization being solved by moving one web page inside the firewall, to entirely eliminating a process rather than automating it, I have seen over and over again how when a team understands the problem and has the latitude, they can come up with solutions that take less time, cost less, and have meaningful impact.
When you know the problem you are solving, it increases clarity for the team and it helps to shape how you think about scope and prioritization by giving context to options and tradeoffs.
If you can move a team from thinking in solutions they need to implement to problems they need to solve, you will see positive outcomes without addressing any of the the other 7 behaviors.
In future articles, I’ll talk about tools and techniques that help with the behavior, “Know the problem you are solving.”
If you want to keep up on the progress of the Behaviors Book, pay attention to the Behaviors Book page. And if you would like to learn more about how we use The Behaviors to guide teams, reach out.
Related Articles
The problem with "fail fast" is that it too often becomes "move fast." Failure is hidden or spun as success, speed is rewarded, and the learning part gets lost entirely. At its worst, "fail fast" is an excuse to rush into the next thing without pausing to understand what just happened.
What I want to promote instead is Observe Often. The shift in language is intentional—when we say “observe,” we bring focus back to what matters: seeing, measuring, and learning from what we do. And “often” reinforces frequency over haste. It’s not about reckless speed; it’s about small, deliberate moves and frequent feedback loops.
These days, it seems like even talking about diversity and inclusion can spark a political debate. But here’s the thing—it doesn’t need to be political. This isn’t about left or right. It’s about people. It’s about teams. It’s about building environments where different perspectives aren’t just welcomed, but seen as essential.
Because they are.
In tech, in product, in leadership—diverse teams consistently outperform homogeneous ones. Not because it feels good, but because it works better. This is a business discussion. A design discussion. A collaboration discussion.
So let’s talk about it.
Full-stack teams are a brilliant concept. They’re designed to have everything a team needs to solve problems in a given domain—front-end, back-end, database, security, you name it. When done right, these teams are little microcosms of outcome achievement, creativity, and autonomy. They blur skill boundaries, enabling faster delivery and real-time learning across disciplines. Sounds great, right?
But there’s a catch. Somewhere along the way, we started confusing “full-stack teams” with “teams of full-stack engineers.” When I say we, I mean it. I did this too. I was on the full-stack teams of full-stack engineers bandwagon. But that shift—over time—has cost us. By prioritizing generalists at the expense of specialists, we’ve inadvertently traded depth for breadth and innovation for adequacy. Let me explain.
In this article, I want to go more in depth on Opportunity Solution Trees; what they are, how they are used, how to create one, and how I think about them slightly differently (but only slightly) than folks like Teresa Torres who really introduced them broadly to the Product community in her book “Continuous Discovery Habits”. This book, by the way, is a must have for anyone who works in software product development - not just folks in product-specific roles.
The Experiment Canvas is a simple means of planning, tracking, and responding to your experiments.
Gall's Law suggests that for software teams seeking to build efficient, manageable, and scalable solutions, they should start with something simple and then evolve it.
“Know the problem you are solving” is about knowing the specific problem and for whom this problem exists. It isn't about knowing what solution a persona lacks but about truly understanding a persona's needs and challenges.
Over the past several years, as I’ve been helping teams and organizations improve their ability to deliver software products that are desirable, viable, and feasible, I have been experimenting with a Behavior Framework that has proven to be rather effective. And I’d like to share it with you in hopes that you find it useful and that you provide me feedback on your experiences with it.
A while back I worked with a large manufacturer that needed to modernize a system that managed a key part of their operations. Once completed, the company projected savings of more than $100 million a year.
The plan was to go big. A highly detailed three-year plan.
They assumed that if they were to get a large solution done, they needed to tackle it in big steps.
We suggested small steps.
Here’s what happened.