A very common challenge faced by Product Managers of all experience levels is understanding and implementing some form of repeatable process around prioritization. Some people take a very light approach, making decisions based on their own experience, data, and beliefs about the direction of the product. Others take a much more rigorous approach, applying scorecards and “objective” measures across a plethora of different possible metrics. I’m here to tell you, there’s nothing wrong with either of those approaches, but it’s also become clear to me in my years as a Product Manager that there’s no “silver bullet” to ensure that your prioritization decisions will be right more often than they’re wrong, and placing too much value in systems and scores often just results in a false sense of security that the “process” was right, when digging in you’ll find that those “objective scores” are nothing more than a system to be gamed. There are, however, three things that I think every prioritization system needs to take into account. So, without further ado, let’s discuss value, difficulty, and instinct…
Proper Care and Feeding of Your Product Backlog
One of the least glamorous parts of Agile development for most Product Managers is the process of backlog grooming. It can be a challenge to get teams to engage when they’re in the middle of a sprint, it can be difficult to convince stakeholders to refer to the backlog instead of the Product Manager for simple questions, but most of all it reminds us of the gigantic list of things that we’re not doing — which is a source of frustration for any Product Manager. However, maintaining a clean, healthy, and vibrant product backlog is essential to the success of not only an Agile product team, but to the organization as a whole. When backlogs are clear, prioritized, and public, people can freely and regularly review it, raising questions and concerns as they come up rather than waiting for a big bomb drop of feedback during some strategic planning session. If you’re a fan of my blog, you know that I strongly believe that it’s the little work in upkeep and transparency that transforms an organization from just “doing” Agile to “being” Agile — and the product backlog is the number one arrow in your quiver to make change happen.
“Agile” is More Than a Buzzword: Three Truths Behind the Manifesto
It’s become rather commonplace lately for people to dismiss “Agile” out of hand as an industry buzzword with no meaning or substance to it. And in some ways, the term has earned that reputation — mostly from people who use it regularly without really knowing what it means or how it changes an organization — or more accurately, how an organization must change to be Agile. And while there will always be those who abuse such terms, mostly out of ignorance rather than malice, it’s important to remember that “Agile” is a word with meaning, substance, and history behind it. There’s a good reason why the Agile Manifesto begins with the words, “We are uncovering better ways of developing software by doing it and helping others do it.” These words ring true because they aren’t an end in and of themselves, they don’t attempt to prescribe or proscribe any specific approach, and they accept that there is fluidity in what we do and how we do it. Truly embracing “Agile” requires that we hold certain truths to be universal…
Knowing Your Effort Budget
It’s amazing to me how often I talk with someone about a project they’re working on, and when asked “what’s your budget on this” they just look at me with a blank look. Let’s be real for a minute — everything we do in product design, development, and management has limits. We have limited resources. We have limited time. We have limited energy. But all too often we just assume that everything that we’re doing requires 100% of our effort, 100% of the time. But that’s simply not true. Some things are more important than others. Some things require more time and effort and energy than others. Some things that we do can slip through with a smaller amount of our attention than others. We instinctively do this, but we rarely actually plan it — and that’s to our detriment and to the detriment of our stakeholders. Laying out a clear understanding of the amount of effort that you’re expecting to spend on any given project or component can be an essential tool in any Product Manager’s belt.
How Much Technical Debt is Too Much?
Let’s face it, technical debt is something that every Product Manager has to deal with on a constant basis — whether it’s making snap decisions that unblock your team so that they can keep working, short-cutting an ideal architectural solution because you have time-to-market pressures, or deciding to put off working on bugs found after a story’s been closed. While the common wisdom may be that you should never take on technical debt, the real world intrudes on such a fantasy each and every day, and if we don’t want to wind up in a death march that never sees the light of day, sometimes we have to make the choice to sacrifice some long-term stability in exchange for short-term gains. But how do you determine when there’s too much technical debt, or when the specific item of debt is too much to bear? That’s what we’re going to discuss today…