Most Product Managers have, at one time or another, heard the apocyphal quote often attributed to Henry Ford, “If I asked my customers what they wanted, they’d have said a faster horse.” And when we hear the line, we laugh because there’s no way that we would do such a thing — the “faster horse” is a fictional thing that we’d never actually spend out time and effort working on. We slap each other on the back, smile, and then go back to our office where all too often we return to working on the “faster horse” that we’ve deluded ourselves into thinking is innovative and fresh. It’s an unfortunate fact that much of what we do really is just delivering faster horses, giving our customers what they say they want (or worse, what sales tells us they say they want), and not digging deep enough to uncover the real need, problem, and desire that’s driving the request.
Sometimes Failure is the Best Result
As a Product Manager, it’s in our bones to always do the best job possible, to deliver the best product possible, and to satisfy the most customers possible. But what if I told you that by always succeeding, we’re actually hampering ourselves? While it might feel good to hit a home run every time you step up to the plate, you’re probably not playing in the right league. It can be easy to fall into a pattern of complacency, of certainty, of feeling invincible because you never miss a swing — but the simple fact is that if you’re never wrong, you’re playing it too safe and you’re limiting yourself to only what you know that you can accomplish. It takes bravery to step outside our comfort zones, to stretch ourselves and test our boundaries, and to try new things that aren’t guaranteed to be winners. In fact, failure is essential to growth not only as a Product Manager but as a person in general — for it is only in failure that we learn from our mistakes and can adjust to ensure that the next stretch, the next test of our abilities, passes with flying colors. If you never fail, you never grow…
User Stories Aren’t Enough
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.
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…
Having a Vision Isn’t Always About Distance
When most people talk about “vision” they’re evoking a concept of long-term planning, setting big and brash goals that you might or might not achieve, but which set a “north star” by which you can plot the course of your product and company. And while that’s an extremely valuable use of the term, I’ve recently been thinking that having a “vision” doesn’t always have to be a 5-year plan, but can be a 5-minute plan and be equally effective. In recent discussions with some fellow product managers, I’ve come to believe that we actually do use shorter-term visions regularly, but we talk about it in a variety of different terms. And when we do, we provide a similar “north star” effect to the people with whom we work on a daily basis — we allow them to chart the course to do more than they might have if we just told them what to do, and not where to go.
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…
Personal Productivity is Just as Important as Professional Productivity
As Product Managers, we’re often deeply and intimately involved in the processes that our companies use in their everyday business. Issue tracking systems, customer feedback systems, email and IM systems — there’s a neverending list of tools that we use on a daily basis to further our own (and others’) professional productivity. Having such a laser focus on the things that we do at work sometimes means that we forget that some of these very same tools (or tools like them) can be used to help ourselves on a daily basis in our personal lives. As I’ve taken on this blog, and written paid posts for other companies, I’ve come to value several tools for both professional and personal productivity that I thought it would be fun to share.
- Next Page »