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.
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…
I find it entertaining when people talk about how Agile and Lean and Kanban are all relatively new, untested, and revolutionary concepts. That’s because they’re none of those things — they’re simply descendants of ideas and concepts that have existed in manufacturing contexts for a half-century or more, just pitched in a different way, at a different time, to a different audience. What we talk about now is just an evolutionary adoption of principles of line production that were brought into being by W. E. Deming and his contemporaries at the end of World War II — the concepts of identifying and reducing waste, focusing on just-in-time stock-keeping, and narrowly focused on doing only the work needed to move a product to the next step of the line. Even the empowerment of individuals and teams owes a great bit of gratitude to the Toyota Production System and it’s focus on granting every line worker the power to stop the entire process if there was something wrong or something to improve upon. I think that it’s past time that we not only acknowledged this history but embraced it — and leveraged the long history of success in that domain over into our own work.
As Product Managers, we’re called on a lot to weigh in on questions, considerations, and issues related to our market, our customers, and our products. And we’re often pressured to provide opinions either with or without sufficient data to feel entirely comfortable about drawing conclusions that we know people will rely on and act on — regardless of how carefully we couch our words. It’s par for the course, to some extent, but the more prevalent such requests become, the more we might begin to lose sight of the hazards of engaging in such speculation, and start to leap to our own conclusions without doing our due diligence, even when we do have the time to do so. After all, if we’re truly experts on our market, customers, and products, then we have license to make such gut decisions and skimp on the data collection. WRONG. Part of our job, indeed our necessary role in the organization, is to push for truly data-guided and data-driven decisions — especially when the conclusion isn’t crystal clear (and often when it is). We need to be comfortable stopping the train, or at least slowing it a bit, to do some basic fact-checking before we make decisions that can literally affect the lives and livelihoods of our team members. We owe it to them, and to ourselves, to understand when we’re stepping out of our “known knowns” and into the territory of “known unknowns” (to blithely steal a classic from Donald Rumsfeld).
One of Amazon’s prized leadership principles is “Be right, a lot.” And we should certainly strive for that as Product Managers, no matter what company we work for, or what product we’re working on. But there’s a corollary to that statement that’s equally important — that you’re not going to be right all the time. And that’s a good thing, believe it or not. Making mistakes is part of the game that we play on a daily basis, and it’s only through making these mistakes that we learn, we grow, and we understand that we’re willing to take the chances needed to truly innovate! If you’re not wrong at least part of the time, you’re either a certifiable genius who outranks even the Elon Musks and Bill Gates of the world — or you’re not truly taking chances.
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.
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…