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…
What’s the Difference?
The first thing to address is laying out what we mean by “default delay” versus “default ship” — and how it affects our day-to-day decisions as Product Managers. While the basic meanings are pretty clear — in a “default delay” culture you are fighting to ship a product, while in a “default ship” culture you have to come up with reasons not to ship a product — the implications and manifestations of these concepts can sometimes be tricky, and can sometimes vary by role and responsibilities. For example, your QA teams are probably always going to be default delay — it’s in their blood to seek out issues, identify them, and insist on them being fixed before release. On the other side, your best developers should have a “default ship” mentality, working to ensure that the code they are writing is as ready to see the customer as possible, as soon as reasonable. You can see this tension in other teams as well — Sales is likely to normally be “default ship”, while Support is likely to be “default delay”. These sorts of team-oriented biases are to be expected, and they can be fairly easily managed by a good Product Manager. The issue only really crops up at the more meta level of the company as a whole — where do your executives, directors, and managers fall on the spectrum, are they more “default delay” or more “default ship”?
The Problems With “Default Delay”
Perhaps the greatest risk involved in having a “default delay” culture is that it’s exceedingly easy to fall into analysis paralysis and wind up never shipping anything of value — or in doing so on an unpredictable and excessively long release cycle. This is because you as a Product Manager are always fighting to come up with reasons why you should ship, while your stakeholders are pushing in the opposite direction. While this may be typical of large corporations, due to risk aversion, gated checkpoints, and/or a disinterest in true experimentation, it can also creep in at smaller companies, where there is a lack of trust in the opinions of those doing the work, a history of missed quality bars, or even executives that are heavily involved in the weeds and unwilling to make compromises in their vision for the sake of delivering something of value to the market. In most companies with a “default delay” culture, fear is the primary driver of this default position — fear of making mistakes, fear of losing revenue, fear of losing customers. As a Product Manager, it becomes our job not necessarily to focus on doing the right thing for the customer, but rather on allaying the fears of out stakeholders — a tradeoff that inevitably winds up hurting the product in the long run, and causing churn on our customers as a side-effect.
The Benefits of “Default Ship”
On the other side, the benefits of a “default ship” mentality should be clear — we actually ship things to our customers on a regular basis, as they’re ready to go. We don’t run into the “perfect as the enemy of the good” problem within a “default ship” culture — we accept that “good” can always be improved upon, and that “good” is always better than “nothing”. Facebook’s principle of “move fast and break things” is probably the most famous (and most extreme!) example of this, but we don’t have to go that far to achieve a “default ship” culture. We just need to instill in our stakeholders, our developers, our QA teams, and our design teams the concept that we are going to ship something. It may not be perfect, but it will solve a problem. We can iterate on something once it’s released if we’re not completely satisfied with it. We will take the time to make it the best that we can, but we will also constrain that work to reasonable efforts within reasonable time frames. The major point to convincing people that a “default ship” position is better than the alternative is to focus on the customer — they have problems and pain points that we can solve for, an solving for them with something is always preferable to not solving them by giving them nothing. Alphas, Betas, Previews, and other ways of couching features to manage expectations are tools that we can use to allay the fears of the stakeholders, but the general principle at play is that the customer will benefit from us rolling out some feature or function even if it’s not the “perfect” or “complete” solution.
Default Modes Are Your Fallback Modes
Perhaps the most important and actionable thing to remember is that when we are stressed, human beings revert to modes of operation that worked for us before — it’s a basic function of evolution. And when we’re trying to migrate our culture from one that is “default delay” to “default ship”, the difficulties aren’t going to pop up when things are going smoothly — people will always agree to ship something that seems mostly done, or that’s polished enough to look and feel complete. But when things aren’t on the happy path; when things aren’t as clear and clean and polished as we might like, or when things don’t work out like we expect them to, that’s where we need to push in the right direction. That’s where we need to exert pressure. That’s where we need to remind people that delivering something — no matter how small, no matter how unpolished, no matter how incomplete — is almost always preferable to delivering nothing, especially in this day and age.
