When leaders ask teams to "go faster," they're usually not asking for better outcomes. They're asking for more output. More stories delivered. More code shipped. More visible progress.
Implicit in that ask is a pretty big assumption: that we already know exactly what needs to be built, that the plan is correct, and that execution is the only thing standing between us and success.
So "go faster" becomes shorthand for "execute the plan harder."
That's where things start to go wrong.
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.
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.
Today, I’m excited to announce the beta launch of Collaboration Contracts, a lightweight app designed to help teams—especially distributed ones—quickly define and manage their roles in decisions. Whether you're using it to bring clarity to one-off decisions or baking it into how your team operates every day, the app is built to support alignment, accountability, and smoother collaboration.
When leaders ask teams to "go faster," they're usually not asking for better outcomes. They're asking for more output. More stories delivered. More code shipped. More visible progress.
Implicit in that ask is a pretty big assumption: that we already know exactly what needs to be built, that the plan is correct, and that execution is the only thing standing between us and success.
So "go faster" becomes shorthand for "execute the plan harder."
That's where things start to go wrong.
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.
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.
Whether you’re still figuring out your general product offering or you are enhancing and adding capabilities to a well established product, the ultimate test of whether or not you’ve hit the mark (or are at least trending in the right direction), is how your audience engages with what you’ve created. Yes, you can (and should) do market research before designing and coding up a potential solution to an identified problem, but the only way to know for certain, is to see what happens when your concepts come in contact with your audience.
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.
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.
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.
