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.
Have you ever stopped to think about what makes some products successful while others languish in obscurity? What made Orkut fail while Facebook took the world by storm? What made StackExchange such a tremendously popular forum when there are literally thousands of others who have attempted the same thing? As much as we Product Managers want to believe that there’s some magical formula of product/market fit, compelling MVP features, and user-centered design that is guaranteed to make our product a success, the simple fact of the matter is that there’s a lot of luck involved in whether or not our solutions “stick” in the market and whether or not our ideas lead to successful products.
If you’ve been reading this blog for awhile, you’ve probably noticed that accepting uncertainty is a a recurring theme when it comes to Agile and agility. While it’s never stated outright as a “value” in either the Agile Manifesto or the Twelve Principles of Agile, the concept itself underlies many of the points made in those documents. In my opinion, it’s the primary cultural distinction between organizations that still cling to the old, outdated “waterfall” approaches. Waterfall creates a false sense of security by defining everything possible up-front. Agile accepts that we don’t always know everything, and that new information will not only be discovered, but might alter the path. Here are a few specific reasons why accepting uncertainty is essential for teams to be successful.
For a term that’s so well-established in our profession and so widely used, it always surprises me when people abuse and misuse the concept of Minimum Viable Product (or “MVP”). It seems like such a fundamentally simple and clear concept, but often in practice it gets all wrapped up around the axles of internal struggles, until it no longer bears any resemblance to the basics of the concept itself. And when we abuse such a basic concept, bending it to our own purposes rather than using it for the purpose it was conceived for, we wind up watering down the meaning of the term and missing the entire point of engaging in the process of defining and building that MVP in the first place. We create MVPs to confirm a set of hypotheses, to ensure that the problems we’re trying to solve are real and valuable, and to make sure that the technology behind the solution functions as expected. At least, that’s the theory…here are some common missteps that Product Managers make that change their efforts from an actual MVP into something else.
One of the primary things that Product Managers are constantly working on is change — changing the way people view our customers, changing the way our customers view our product, changing the culture of our company to be more agile, changing peoples’ minds about what’s important and what’s not…the list goes on and on. And, not surprisingly, nearly every Product Manager eventually comes to the realization that change is hard. I mean really, really hard. And sometimes it seems like even the smallest changes are the hardest to get people to commit to and deliver on a regular basis. So why is change so hard? Here are a few of the common reasons…