Most companies out there put a huge push on efficiency and running “lean” — doing the most possible with the least amount of overhead. And in most cases, that’s a very noble goal — after all, overhead in the form of people and positions is generally the highest cost that companies face. Reducing the number of people needed to achieve the same goals allows the revenue side of the equation to exceed the costs — which is almost every company’s end goal, to achieve a sustainable business model that makes money for the owners of the business. The problem with this is that it’s often taken too far — the drive to be “lean” winds up causing more headaches and issues than it creates an environment conducive to success. This issue isn’t only of concern to Product Managers, it affects every part of the business, from sales to marketing to support to development. And because of that, we’re often in a unique position to see they dysfunctions that trying to drive too lean causes throughout the company. It’s up to us to be aware of the risks and raise them as we start to see red flags, before they damage the ability of the organization as a whole to compete in an increasingly competitive marketplace.
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.
Due to the unique role that Product Managers play in most organizations, we’re often capable of being the strongest influences on the overall culture of the product development organization and of the company in general. And while there are many companies out there who are truly only interested in giving lip service to the concept of agility, there are others who actually want to be better, who want to embrace the concepts of agility — and it’s up to us as leaders to influence that and contribute where we can. While there are a lot of different behaviors that we can engage in which are likely to increase the adoption of agile practices across our organization, in my experience there are three key things that we should focus on if we want to broaden the success of agile adoption in our companies…
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”.
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.
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.