It’s commonly accepted nowadays that we use user stories or some variation on them to communicate our “product requirements” to development teams (job stories, jobs to be done, scenarios, etc). And while this is certainly an improvement over some of the bad, old Big Up-Front Requirements (BUFR) methods that were used many moons ago, they’re still not perfect, for a wide variety of reasons. All too often, they assume that certain considerations have already been made, that certain work has already been done — when in fact it often hasn’t. Not every development team has a UX and UI member dedicated to help them achieve a story; not every product can afford to have user-story level architecture decisions being made — and every User Story has to be the result of some amount of planning and forethought, both from a business and a technical perspective. While user stories are a great tool, they’re far from the only tool that we need in our drawer to be effective. Here are some things to consider when you’re relying on User Stories as your primary method of relaying work to be done to your development teams.
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.
Assumptions, Risks, and Constraints – The Keys to Success
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…
That Which is Urgent is Not Always Important
We’ve all been there — that sudden call from one of your Sales team with a customer “on the hook” but they only need this one more thing to close the deal. Or maybe it’s an escalated issue from your biggest customer that lands in your mailbox with gigantic ALL CAPS AND EXCLAMATION MARKS!!!!!! Or worse yet, it’s your CEO who “stops by for a quick chat” about something that he overheard at an industry event last night. Regardless of where these things come from, they all have one thing in common — they’re urgent. They require your time now. They simply cannot be ignored.
Or can they? Or more accurately, should they be ignored? If you ask me, the answer is absolutely. Things that are “urgent” are thrust upon us by others with some expectation that we’ll drop everything and deal with them — not on our terms, but on the terms of someone else. Here’s why you should beware of the urgent and instead focus on what’s important…
You’re Already a Product Manager…
One of the most common questions I encounter in my work as The Clever PM is a simple one — “How do I become a Product Manager?” And, while the specifics depend greatly on the individual person, where they’re at in their careers, and what companies they want to break into, one of the things that I’m always telling people is that it’s likely that they already have the skills that they need. The best and worst part about being a Product Manager is that the role is often a “jack of all trades” role — filling in where there are gaps in the organization, ranging from the strongly strategic to the severely tactical. No matter where you sit in your organization, chances are good that with the right perspective and point of view, you can likely position the things you do to fit some definition of “Product Manager”.
[Read more…]
- « Previous Page
- 1
- 2
- 3
- 4
- 5
- 6
- …
- 41
- Next Page »