As a Product Manager, sometimes we get so caught up in either the macro or micro concerns of our day-to-day lives that we forget that getting shit done is our primary job. It does no good whatsoever to have our product remain in a constant state of development, with projects that get put on the shelf after being half-complete, in preference for the new hotness over what’s now old-and-busted. As a Product Manager, we’re not only in charge of making sure that we’re doing the right thing at the right time, but also that we’re actually finishing what we start — and that what gets done gets into the hands of the customer as soon as reasonably possible. Iterative development is literally impossible to do within the confines of your four walls; unless you’re constantly releasing a stream of iterative improvements, you’re just not getting it done.
Default Ship or Default Delay?
Last week, buried in a post by Paul Jackson that was primarily a response to the #noestimates crowd, I uncovered a pearl of wisdom that literally hit me like a ton of bricks. In that post, near the bottom, Paul notes that “Corporations are…default delay” organizations, meaning that their default behavior is to delay releasing product rather than to release it when it’s ready. They might claim that it’s for marketing purposes, or for quality purposes, or that their customers “can’t handle rapid release cycles,” but what it really is at the end of the day is risk aversion. Contrast this with a startup culture like you see at Facebook, where the product is one gigantic experiment, and where code is pushed to live all the time after seeing just enough testing to ensure that it doesn’t bring down the whole damn system. The strong code survives, the weak dies out — it’s survival of the fittest, code-style.
The reality is that no single Product Manager is going to change their entire corporate culture from default-delay to default-ship overnight. But realizing that your company has such a mindset and recognizing the anti-patterns that follow from that realization can be an important part of reinvigorating yourself to focus on your #1 job — getting shit done. Once you realize that your company has a default-delay mindset, you can start probing to find the edge cases where risk is more acceptable, and to start pushing on those edges to demonstrate that the risks that they are concerned about are largely in their minds. And, after you can prove out your success on those fringes of the product, you start pushing that success inward, leveraging what you (and the teams) have learned to mitigate those risks and challenge the discomfort with the unknown, until you’re actually getting shit done for real.
Seriously, Just Get it Done! Then Fight the Fight…
When trying to maneuver a company away from a default-delay mindset, it’s really important to take some time to critically assess the resources available to you, the opportunities that you have, and the manner in which you’re going to approach the process. Ultimately, very few people are going to be able to reasonably fight someone who wants to get more done, more quickly — but they are out there, and their irrational fears can only be overcome by demonstrating success such that they have no alternative than to accept that marketing, quality, and customers actually can adjust to more rapid deployment — or at least that you can build up a queue of finished work that can be released at a later, more acceptable date.
Getting it done doesn’t necessarily mean that it’s shipped and in the hands of the customer — that’s obviously the ideal situation, but in some organizations it’s a massive win just to get the code to a complete and stable state, then let it sit on the shelf for a couple months until marketing and QA and customers are “ready” to take it in. In fact, in some organizations this is actually going to be the best first step, since once you start “finishing” things and they wind up sitting on the shelf, gathering dust, this becomes the next angle of attack — why complete things and then just let them sit on the shelf? If they were important enough for the teams to work on, why aren’t they important enough to get into the hands of the customers? Again, only irrational arguments can be posed against this position — but those irrational fears can be allayed over time, and with sufficient pressure from a position of influence, since you’ve got stable, tested, ready code behind you.
So, the next time you’re faced with some cultural pressure to not release, realize that you might be facing a default-delay situation, and adjust your approach appropriately! Then, just get that shit done!!
