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.
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.
One of the many challenges that Product Managers face in trying to move organizations toward a more agile approach to product development is that some stakeholders simply don’t see the value in the shift. They believe that, since their way has worked for them for so long that there’s no need to change — after all, it can’t be broken if it works, right? But the simple fact is, the bad old ways of product development are dying, as markets and customers move faster and have more options available to them to solve their problems every single day. There’s not a single industry that isn’t facing high-investment newcomers who are able to move fast and adjust — and leave they’re slow-moving, waterfall-based competition in the dust.
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…