Finally, The Minimum Tolerable Process

Dear adventurer,

"Would you eat a can of cat food?"

The question is Aha! lore at this point. I first brought this up in 2013 when I introduced the concept of a Minimum Lovable Product as a counterpoint to the Minimum Viable Product. My reference was the idea that even though kitty chow might be a viable dining option for an exceptionally hungry human, it would likely not be your first choice.

Viability is not the same as lovability. Lately, I have been thinking about this in terms of the way we work as well.

Would you rather chase your tail — planning forever before you can make a move, then waiting on approval for the next step? Or run after that laser pointer with no regrets and no idea why you ended up where you did?

Neither is fulfilling. But that is the impossible choice many teams face with today's product development frameworks, whether they follow a legacy waterfall approach, a ceremony-heavy methodology (like the Scaled Agile Framework?), or the free-form flow of doing whatever seems to make sense (some version of kanban).

None are satisfying. After decades of building software, I have seen firsthand how challenging it is for companies to set a methodology that consistently creates customer value. Not quite cat food. But I knew there must be a more healthy and enjoyable way.

What teams crave is an agreed-upon and repeatable way to approach product development with agility rooted in strategy.

We forged our own way at Aha! with The Aha! Framework for product development , which we publicly shared for the first time a few months ago. Our framework puts both strategy and agility at the forefront. It is how our team builds products, and something we have spent the last 10 years refining (and will probably spend the next decade refining even more).

We were ruthless when refining and formalizing it. Our focus was on how to realize tangible product value with as little effort (and friction) as possible. This meant questioning the inclusion of every suggested activity . The framework needed to be only what is most essential to propelling the team and the product forward.

Our team at Aha! started calling this just-enough view of product development the "Minimum Tolerable Process" (MTP).

Note that we chose to call it "tolerable," not "lovable." Few people aside from consultants and theorists love (and get paid for) process. So the focus here is pursuing the minimum overhead needed to effectively deliver what customers will love — and for the team to be happy doing that work.

You start by removing the friction that typically occurs when there is tension and conflict around objectives and accountability. And you continue by removing every meeting that is not absolutely required.

To succeed, you need real insights and a true north. And you need to establish some defined ways of working. (Otherwise, you are relying on luck and sure to experience chaos.)

So how do you know if you are very far from or very near to your own MTP? Determine whether your team has the following:

• A set of assumptions behind what you are building
• Goals that are shared widely and understood
• Defined and published responsibilities
• Trusting communication
• General time frames for planned work
• Signposts for success and a way to measure it

The Aha! Framework is our team's MTP . As you review your answers to the bullets above, it will likely be clear where your organization lags and where you soar. And even though you might not be able to effect change immediately , knowing where you can and should streamline work is critical to putting improvements in motion.

When you reset around the MTP, you create guardrails for success, and it becomes easy to identify when you veer off course. You shun bureaucracy and push back against mediocrity . You have a clear vision and spend as much time doing creative work as sitting in meetings. You focus on achieving and encourage others to do the same.

We all have limited time and energy to expend in life. We deserve to channel both in ways that enable us to achieve our best and do something meaningful.

Building products is both a privilege and a responsibility. I believe wholeheartedly that product development provides that opportunity for meaningful achievement.

The ultimate goal is to create something of value, enjoy the journey, and have pride in what you do — without drama or pain . But we cannot get to that next level if we are caught in a maze of "next steps" or keep sprinting without a destination.

I am hopeful that we can tolerate less and aim for more.

Efficiently yours,

Brian