Know the problem you are solving

When Playing It Safe Is the Riskiest Move

Most teams agree that learning is key to reducing risk. But not all learning happens during implementation. And not all approaches to product discovery are as iterative as we like to think.

In many orgs, there’s a tendency to treat product discovery and design work as a way to front-load certainty. Research gets packaged into polished prototypes. User flows are vetted, click-through demos reviewed, copy finalized. Boxes have been checked, sign offs are obtained, success feels inevitable. By the time development begins, there’s a sense that the hard part—the learning—is done.

From there, teams move into delivery mode. They build incrementally, they iterate on implementation, they follow agile rhythms. But the product thinking has already solidified. What gets built may be sliced small, but the underlying decisions are no longer being questioned.

It creates the comfort of “knowing” while giving the appearance of agility.

But it’s not agility. It’s choreography.

And when things shift—as they inevitably do—it becomes clear how little room we left ourselves to adapt.

Certainty Feels Safe. Learning Is Safer.

When we invest heavily in up-front discovery, it can feel like we’ve reduced risk. We’ve anticipated edge cases, validated with users, aligned on a vision. But that confidence is only real if we keep validating as we go.

No matter how thorough your discovery process is, the most reliable learning still happens where software meets customer. Early. Often. In context.

The further discovery is from that point of contact, the more assumptions sneak in. The tighter the prototype, the harder it is to change course. And the longer we go without user feedback on the live experience, the more fragile our work becomes—no matter how good it looked in design reviews.

Treat Discovery Like Delivery

The healthiest product teams don’t just iterate on implementation. They iterate on understanding.

They approach product discovery the same way they approach development: in small, testable steps. They release early prototypes not just to stakeholders, but to real users. They fold learning from production back into their product thinking. They augment initial discovery learnings with live product analytics, customer feedback, and satisfaction surveys (to name a few) as input to adjust and improve on what they've delivered. And they keep discovery going through delivery—not just before it.

This is what continuous discovery looks like. Not a separate phase, but an ongoing practice.

Instead of trying to eliminate risk through “getting it right,” they reduce risk by learning faster and adjusting sooner.

Make the Learning Loop Short

The teams that adapt best are the ones with the shortest feedback loops. They don’t pretend to be certain—they design their work so they don’t have to be.

They test assumptions quickly. They validate throughout the development and delivery cycle, not just after launch. They expect their early thinking to evolve. And because they’ve built that expectation into how they work, change doesn’t feel like failure—it feels like progress.

What’s Next

If your product process feels stuck—if discovery happens all at once and delivery happens in isolation—it’s worth asking: when was the last time we changed our minds?

Not because we were wrong. But because we learned something new.

Doubling Down on Diversity

Doubling Down on Diversity

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.

Fixing Full-Stack Teams; Specialization Required

Fixing Full-Stack Teams; Specialization Required

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.

Opportunity Solution Trees

Opportunity Solution Trees

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 Behaviors

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.

Beginning a New Book

My plan is to write a series of blog posts all related to the behaviors framework. Some of them will be about a specific behavior. Some of them will be about tools or techniques that help teams express one or more of the behaviors. Some of them will be my own experiences. And some will be damn near complete fiction.