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.
It’s far too common in the world of Product Management for us to wind up being narrowly focused on the actual product development cycle – define, build, measure, repeat. But there’s far more to building, launching, and maintaining a successful product than just what goes on between Product Management and Development. The best and most successful Product Managers try to look at the “whole product” and not just one small (though essential) part like the development process. To get the whole picture, we need our eyes, ears, and fingers on the pulse of all the activities that go on around the product — development, sure, but also marketing, sales, support, implementation, services, and anything else that might be considered “product-adjacent”.
One of the many challenges that Product Managers face in trying to move organizations toward a more agile approach to product development is that some stakeholders simply don’t see the value in the shift. They believe that, since their way has worked for them for so long that there’s no need to change — after all, it can’t be broken if it works, right? But the simple fact is, the bad old ways of product development are dying, as markets and customers move faster and have more options available to them to solve their problems every single day. There’s not a single industry that isn’t facing high-investment newcomers who are able to move fast and adjust — and leave they’re slow-moving, waterfall-based competition in the dust.
A couple years ago I ran across a blog post by Paul Jackson where he mentioned in passing the idea of a tension between “default ship” cultures in relation to corporations versus startups. For some reason, those two ends of a spectrum have stuck with me ever since, and after struggling with some culture change in my day-to-day job recently, I thought that it was an interesting subject that deserved a little more attention and dissection. Because, even though Paul positioned it as a startup v. corporate culture issue, my feeling is that it goes much deeper than that and is a topic that every Product Manager should be aware of and have their eyes out for — you never know when the “default delay” police will come knocking on your product’s door…
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…
This post comes courtesy of a direct request from one of my supporters over at Patreon, who asked me if I could give them a 10,000 foot-level overview of the Product Lifecycle from ideation to delivery. While nothing here should be terribly earth-shattering or world-changing, I think it’s important for us as Product Managers to stop on occasion and think about how things should work for us from the point of an idea to the days supporting a thriving product. So here’s my personal take on the subject — as always, if you have thoughts or comments, feel free to drop them here or hit me up on Twitter!
So, another year is starting up, and we’re just now starting to unpack ourselves from the holiday break that so many of us take time to enjoy with our families and friends. The best thing about a new year is that the future really is a blank slate, 365 days to make of them what we will. Sure, there’s carry over from last year, but there’s far more to look forward to than to look back on. It’s the perfect time to stop for a moment and take stock of what happened last year, what you want to do this year, and how you’re going to make 2018 more successful than 2017!