A quick validation checklist to run before committing to work. Helps teams avoid building solutions to unclear or unimportant problems.
Solutions Disguised as Problems
A product manager walks into your office and says, "We need a report that shows daily active users by region, broken down by feature usage, with trend lines for the past 90 days."
You nod. Sounds clear enough. You estimate it, add it to the backlog, and two weeks later you deliver exactly what was asked for.
The product manager looks at it, says "thanks," and then... nothing. It sits unused.
A month later, they're back asking for a different report with slightly different breakdowns.
What happened?
You built the thing. You didn’t solve the need.
How Small Steps Saved Millions
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.
Don't fail fast; Observe often
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.
Bug Bashes are a Smell
The other day, I was in a Slack discussion with some of the good folks at Test Double. The topic of bug bashes came up, and the conversation was rich. People brought thoughtful perspectives and experiences, and the discussion left me reflecting on what bug bashes say about the systems we work in.
So, You Want To Release Ridiculously Often?
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.
Why ‘Best Practices’ Don’t Exist
The problem with the term best practice is not always the practice itself—it’s the perspective the phrase invites. Best is steeped in finality. It implies that nothing better exists, or ever will. That the thinking is over. And while we may not mean it that way, language shapes thought. When we call something “best,” we stop asking “is it still working?”
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.
Composition Isn’t Just About Code
The way your teams are structured shapes the software you build—and vice versa. In this article, we explore the profound connection between team and software composition through the lens of Conway’s Law, uncovering how misalignment leads to chaos and inefficiency, while thoughtful alignment drives collaboration, modularity, and adaptability. Learn why your true architecture isn’t in diagrams but in the code itself, and discover actionable steps to align your teams and software for better outcomes.
Why I Joined Test Double
When I say I’m joining Test Double as their new VP of Delivery, I’m not just making a career move—I’m making an alignment move. This is a company that already values the things I value. They’ve built a strong culture, a strong team, and a strong set of practices. I’m not joining to overhaul anything. I’m joining to help make something great even better.
Small Deployments; Big Impact
When teams hear about small, frequent deployments, they often picture chaos: code breaking, users complaining, and developers scrambling to fix issues. But in reality, small deployments do the opposite. They reduce complexity, amplify feedback, and create a smoother experience for both users and developers.