One of the most important parts of being a Product Manager is making sure that your stakeholders and developers understand not only what you’re trying to do, but the surrounding circumstances in which you’re trying to do it. Often, this is a matter of discussing and managing scope; at other times, it’s making sure that people understand the schedule and resources working on the improvement; and at still other times, it’s ensuring that what comes out at the end of an iteration is what everyone wanted at the beginning of the iteration. But there’s a larger set of considerations that are of key importance to aligning your teams on — because they significantly impact the overall success of what we’re trying to do. All too often we ignore these three components to our peril, and when we do there’s an even chance that they’ll come back to bite us in the ass…
“Product” is More Than Just Development
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”.
Looking Back to Look Forward — Understanding Retrospectives
There’s a tool in the Scrum toolbelt that is so utterly critical to success yet so fundamentally misunderstood by far too many development teams, Scrum Masters, and Product Owners. I’m talking, of course, about the Sprint Retrospective. I’ve seen it time and again, teams that are able to hit all the right notes in their standups, reviews, and planning sessions — but who wind up botching their Retrospectives in such a horrible fashion that they miss out on the single most important part of agile product development, continuous improvement. Certainly, it’s never fun to take time out of our day to look back and discuss what went wrong in the past two weeks — much less try to come up with new things to try on a sprint-by-sprint basis. But it’s the single most important part of the culture that we’re trying to build — the culture of agility, of adjusting, of improving…of change.
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…
The Product Lifecycle
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!
- « Previous Page
- 1
- 2
- 3
- 4
- …
- 7
- Next Page »