All right, so I'm going to sort of adapt my talk as we go. While I've been listening to people today, I realized that when I first started talking about outcomes, people didn't understand what they really were. I had to spend a lot of time convincing them. Now, listening today, Mobius is about eight years old, which is probably one of the oldest outcome models out there in terms of the newest reinvention. So, I'm going to talk a little bit more about the community behind it because Mobius is open-source, and there's a lot of amazing coaches and thinkers populating this space. I'm going to make it a little bit more about them. I'll speed through the first part so I can get to the fun stuff.
One of the problems we're trying to solve is that there are a lot of frameworks out there, and every year, more and more frameworks emerge. When I get called in for so-called transformations, people ask me, "Which is better? Should we be using Scrum? Should we use Kanban? Lean Startup?" There are so many terms. I think there's a lot of value in all these different ways of working, and I don’t think organizations should be treated as something that must be fully standardized into one single way of doing things.
I think we have moved into being outcomes-driven, and there’s a way that we can adapt and create our own innovation models. We also have many practices. Someone this morning, John Smart, said, "Oh, I saw this image from Deloitte, but I still love it." Christopher Webb went through and mapped out all the different agile methods onto the Japanese Tokyo subway map. Agile is meant to be really simple, yet that looks awfully complex to me. Imagine being a new person, overwhelmed with all these different ways of working—how do you make sense of it?
There’s a lot of pressure now that we’re moving more towards outcomes. I see the language changing, but at least in the early days, I always asked people, "What do you measure?" and I would get told everything from function points, cosmic function points, lines of code, deadlines, on-time and on-budget metrics. That shifted to velocity, story points—very output-based measures. When I asked why we measured them, it really came down to the fact that they were simple and easy to understand.
Now, we're moving into a time of outcome measures. You'll see things like OKRs becoming extremely popular. Having done this for a while, I think the next problem to solve is how to create these in a sane way. What I see is almost a replacement of what we had before, but imposed on the organization, and we’re still not getting the behaviors or the impact that we want.
When I simplistically talk about outputs versus outcomes, I just show two pictures. I love the TV remote control, which is very output-based. The more buttons on the remote control, the less value it actually provides. In fact, I think the opposite is true. When we do a lot of feature farming and measure the wrong things, we end up with more and more features that make our products more complex to use.
Instead, the next picture sums up what we should be doing—minimizing outputs and maximizing outcomes. Outcomes over outputs. The next picture comes from a man who was at his grandmother's place and noticed she kept getting up to change the channel. When he asked why she wasn’t using the remote, she said it was just too complicated. So, he figured out what she really needed to do and removed all the inessential features. To me, that should be how we approach most of our products.
When I work with customers and we start analyzing what’s really going on—who’s using what and at what frequency—it turns out there’s a lot of waste in what we build. You’ll notice things like design thinking becoming more popular. This is about building the right thing, understanding the customer experience. Agile has always been about building something, validating it quickly, and getting fast feedback.
Deep discovery is great, but sometimes we risk getting stuck in analysis. On the other hand, we can deliver features rapidly, but if we're not building the right thing, we're simply failing faster. More features, faster, is not the idea. In fact, sometimes I’ve had to go into organizations where Agile has just been used as a faster sausage factory—delivering more and more sausages when, in reality, everyone’s vegetarian and doesn’t want meat sausages in the first place.
What we need is balance. This is where Mobius came from—the idea of balancing our strategic intent with delivered value, something that can be used across an organization. It’s both open-source and liberating in the way that you can mix and match different techniques. We can use a range of frameworks and models, and they can coexist.
For example, in the first part where we frame the problem, we use purpose design challenges. When analyzing motivations, we draw from design thinking and business model generation. When creating outcomes, we now see more traditional outcome approaches alongside OKRs.
The key is to start with a simple guiding path, much like training wheels for a bicycle. It helps people get through the flow and understand the key pieces. However, it’s not meant to be linear. It’s a feedback loop with multiple levels of learning and adaptation.
As you gain experience, you can move around the loop at will, starting at different points. We generate ideas, decide what to work on, and refine them. The left loop is about discovery—understanding why we're doing something and identifying measurable outcomes. The middle, what we call the "options pivot," is deliberately named that way instead of "requirements." "Requirements" make it sound like they must be done, but we treat them as potential solutions—our best ideas at the time. We validate which ones to pursue for the highest value.
From there, we move into designing experiments, launching to customers, and constantly measuring impact. A proper feedback loop brings learning back into the organization. If you see a linear flow, it signals a one-way process, missing valuable adaptation opportunities.
This methodology isn't just for product development. We use Mobius for process improvement, strategy, and coaching engagements. We map organizational issues, measure progress, generate options, and constantly feed learning back.
Our toolkit is designed to be fun, visual, and easy to use, helping people engage with the process. I like to let people create their own journeys. There are multiple ways to achieve an outcome, and giving teams flexibility fosters innovation.
Ultimately, Mobius is about movement—momentum. It's not about delivering features faster, but about making smarter, outcome-driven decisions. We measure, adapt, and continuously improve. It’s a powerful shift from just tracking outputs to focusing on meaningful impact.
If you're interested in joining the community, hop into our Slack group. Some of our work extends beyond business—like using Mobius in conflict zones to improve socioeconomic conditions and reduce extremism. The applications are vast, and the community is always growing.