The Best Methodology for Product Management
It probably wasn’t my most Agile moment, but I Leaned against some Scrum at the Kanban and it’s going to take a Waterfall to clean it off…. I’ll be OK…R.
As you can see, I dabble in the emerging art of Product Management comedy. If you’ve spent any time working in or studying Product Management, you will recognize the genius.
Now that we’ve gotten that out of the way…
There are a number of options when choosing a Product Methodology to guide your development activities.
These methodologies will outline principles, rules, processes, ceremonies, and templates to use to define, develop, and deliver your product.
So which one should you use? Which one is the best?
___
Before we explore the question of the “best” methodology, it is worth asking “Do I need to use ANY methodology at all?”
The answer is probably yes.
However, if your product is very small, and you don’t have any specific customer expectations or timelines to meet, and you don’t need much in the way of documentation, and you don’t have to worry about prioritizing tasks, and…. you know what… you should probably just use a methodology.
Think of a methodology like being tall playing basketball in the NBA: can you succeed without being tall? Maybe, but you will have to work a LOT harder than everyone else, and you probably still won’t be great.
But now imagine that you are going to play in the NBA, and you can chose whether to be tall or short. Which would you pick?
Tall. You would pick tall.
Using a methodology is picking tall.
___
Returning to the original question: Which one is the best?
I asked ChatGPT (not a sponsor) to give me a list of Product Management methodologies, and this was its output:
Sure thing! Here are a few popular Product Management methodologies:
Agile: This methodology emphasizes iterative development, flexibility, and collaboration. It's ideal for projects where requirements are expected to evolve over time.
Waterfall: A traditional approach where each phase must be completed before the next begins. It's suitable for projects with well-defined requirements.
Scrum: A subset of Agile, Scrum focuses on small, cross-functional teams working in sprints to deliver incremental improvements.
Kanban: This visual approach uses boards to manage workflow and optimize efficiency. It’s great for projects where continuous delivery is a priority.
Lean: Inspired by Lean manufacturing, this methodology aims to maximize value while minimizing waste. It's perfect for projects focused on efficiency and value creation.
OKRs (Objectives and Key Results): This goal-setting framework helps teams align their efforts with company objectives and measure progress with specific, measurable results.
These are just a few examples, and each has its own strengths and use cases. Do you have a particular project in mind where you're considering these methodologies? 😊
Yes, it really gave me a smiley emoji. It’s that good.
But if you can just ask ChatGPT to help you pick the best methodology for your product, what is the point of this article?
Because, contrary to the authors of every methodology, the “right” methodology doesn’t exist.
Let me explain…
___
I have worked in a wide range of teams across a variety of companies. Each team has adopted and adapted some named methodology. Mostly they were some form of Agile development. I noted, over time and experience, what worked and what didn’t.
Agile could be considered an acknowledgement that technology, industry, and competition are moving too quickly to follow the traditional linear flow of the old “Waterfall” methodology.
Waterfall fell out of favor because it did not formalize mid-stream adaptation. It was the sort of project plan you might get if you asked your 6th grader to come up with a project plan: after gathering requirements and developing a plan, each phase is completed in sequence until the project is done.
The problem was that the Tech industry started to increase in pace, while the projects did not decrease in complexity. It would still take multiple years to go from inception to launch for a new chipset or operating system, but the industry would move so much in that time that your original requirements may not resemble the market realities you launched into.
Agile helped to address this by formalizing a process of prototyping, testing, and improving continuously throughout the development of the product. This shortened the time to market because requirements could be quickly gathered and work could start, and the requirements could be refined in real time as the testing of prototypes made the necessary changes clear. It also made it easier to pivot based on input gained from testing, narrowing the opportunity for a disconnect to grow between the market and the product during development.
This is a simplification, as Agile goes much deeper than this, but it is woven from the most common threads that run through the family of Agile-style methodologies.
So is Agile the Best?
No.
Well… not exactly.
You will almost certainly rely on key Agile principles, and it is important to be familiar with the concepts and the logic behind them (not just the “what” but also the “why”).
What I have typically found in high-performance Product teams, is that they view methodologies as a toolbox, and they take what they like and what makes sense for their product and their personalities, and use them in a loose Frankenstein methodology that works for them (a Frankenology? …a Methostein?).
They have daily meetings they call Scrums, they arrange their tasks and requirements on a Kanban board, and then they want to make sure each item on the board is linked to the corresponding OKR.
It is rare to see a product development team that operates purely and accurately on a single methodology.
Is this a problem?
No.
Well… not exactly.
There are potential problems with either approach.
The Frankenstein approach is usually a healthy accommodation to the current reality the team is operating in, but there does need to be some structure around how work is defined, prioritized, assigned, tracked, tested, and delivered. A hodge-podge of terms and tools can encourage a breakdown of formality, and a product can easily go off the rails, with no clear leadership or ownership and no clear understanding of what went wrong.
That said, strict adherence to the proscriptive practices of a single methodology has its own problems. I typically see this in one of two situations: either the Product Management is overbearing and bureaucratic, or the Product Manager is inexperienced and relies on the methodology to make sure they don’t miss something important. In both cases, the outcome is similar: there is an over-emphasis on specific ceremonies and terminology that are often over-using people’s time and can give a false sense of confidence because all the right steps are being followed, but not all the right questions are being asked.
So what is the best methodology? I would propose that the best methodology is a Frankenstein combination of the Frankenstein and strict approaches (the Strict Frankenology?).
What does this look like?
First, the Product Manager needs to understand their team culture, their customer’s needs, and the market dynamics.
This will help them to take the next step, which is to review the methodologies they know, the preferences of the development leads, and the software tools available, and then pick their favorite pieces from the available options. Scrum, Kanban, OKRs, and others, each usually have one or two really great processes or tools that can be used independent of the rest of the methodology. Take what you like, leave what you don’t, just makes sure that you are covering all of the current and future needs of the product development effort.
The next step: stick to it.
Treat your processes with gravity.
They should not be optional.
They should carry weight and impact.
If you are using a Kanban process for prioritization and tracking, use it for everything. Do not permit a mix of tools, emails, and spreadsheets.
If you are tying your efforts to OKRs, make sure those OKRs are solid and make sure everything you do links to them.
You are not operating without a methodology. Rather, you and your team have created your own methodology, and you need to own it.
Of course there can be flexibility, but changing the process should be taken seriously, discussed openly, and communicated clearly.
___
So, what is the best methodology?
The one that works for you and your team.
It is unlikely that an off-the-shelf methodology will perfectly match the culture and criteria of your product and your company, so keep what you like, toss what you don’t, and find something else to plug the gaps, but document it, communicate it, and FOLLOW it.
