How many meetings a day can a PM tolerate?

Dear adventurer,

Remember when "going agile" was the buzzy phrase on every exec's lips?

When I first started writing on the Aha! blog about 10 years ago, any company that wanted to innovate faster needed to implement scrum.

"Scrumdamentalists" clashed with scrum wannabes, and the rest of us were caught in the fray. I had some fun poking at the seriousness with which many approached scrum's principles, roles, and ceremonies.

Scrum and other agile frameworks became almost religious. They provided rituals to believe in, giving structure to your day and meaning to your work.

My perspective back then was that like most ceremonies, scrum zeal was symbolic without much real authority. It was borderline navel-gazing — prescriptive internal processes focused on delivery. And it often ignored the core customer-value-generating activities that product managers bring to product development, such as strategy, market research, and go-to-market readiness. But hey, anything to "go agile."

Now, you are seeing big companies that want agility with greater predictability "go SAFe?." The allure is coordination for large teams with large portfolios, but it also brings even greater overhead. Another methodology, another promise. And even more meetings. I hear from a lot of product folks who are worn down by process overload.

Methodologies and frameworks are about helping people make the right decisions that will create the most value and work together efficiently. The larger the team and product portfolio, the more important it is to have an agreed-upon approach. Good structure allows people to focus on solving customer problems in a creative way — not get lost in how to do that work, starting from zero each time.

Realistically, can you be an effective product manager without getting involved in delivery? No. But it should not (and cannot) consume you.

If a product manager is not leading from a customer-first mindset and the team is overly focused on how work gets done, you will end up with what I call "random acts of software" instead of something that solves a genuine need. I would also suggest that, as a discipline, product development is a long way from finding a foolproof framework that allows for goal-based agile development.

This is something we have been working on at Aha! for some years now. We recently publicly released our approach, The Aha! Framework for product development. It is the best way that we have found so far to combine strategy and agility with the least overhead (no fussy terminology or ceremonies needed). And I am certain we will continue to improve it over time.

In my experience, product managers are uniquely positioned to encourage the team to run the Minimum Tolerable Process (how about that for a new term?) for delivering a Minimum Lovable Product.

You are obviously one person in a larger organization, and overhauling or rolling out a new process might not be possible or wanted. You can still affect change though, even if just for your specific team. And if you do and are effective, you might inspire broader improvement.

The key is to focus on where you can bring the most value and reject practices that hold back progress:

Be the customer

Your customers are the reason why your company exists. Your customers do not care about a spanning palette or know what an agile release train is. Yet these important people fade into the background when teammates are overly concerned about internal workflows.

As a product manager, you are often the main proxy for the customer in planning conversations and development meetings. Keep the customer at the forefront and bring them into everyday work. When customer needs are the priority, folks can more easily see how spending yet another hour in a dead-end meeting —?when you could be getting stuff done —?will only hurt those who matter most.

Know the essentials

Rapid development and cumbersome processes are natural opposites. You cannot move quickly when you are worried about remembering acronyms and jumping from meeting to meeting. But you need some agreed-upon approach so people do not spin aimlessly.

Work with your teammates to pinpoint the most crucial activities and how often they should occur (depending on your strategic planning cycle). When we were formalizing The Aha! Framework, we did this by organizing our activities around the core product development stages within a biannual strategy time frame that simultaneously honors weekly sprints and continuous deployments.

Break the rules

Breakthrough products do not come from following others. Just because your organization subscribes to a defined methodology does not mean you have to follow it purely. Flexibility to react to emerging customer needs with urgency is more important than slowing down to follow someone else's rules.

After witnessing more than a decade's worth of product managers succumb to calendar overload and deal with unhelpful cross-team barriers, we decided to eschew silos and standups entirely. For each product in our software suite, everyone who works on it comes together for one cross-functional team meeting each week. And we have one weekly meeting with just the product manager and the engineers who work on the product.

Process pedantry never leads to anything good. You want to find the sweet spot between "We know why we are doing this" and "We know how to do this."

Pick and choose what consistently brings your customer, your team, and your company the most value. Invest in the lightest scaffolding you need to build successfully. Do not get too caught up in semantics or rules.

And remember that many of the more unwieldy frameworks are businesses themselves, often requiring expensive certifications or consultants. You want to build products — not be the product.

Standing up for fewer standups,

Brian