Ship Sooner!

Your B2B customers are in pain because you haven't shipped yet.

TL;DR - As a product manager, it’s important to know when a product or feature is “done enough” and ready to ship, even if there are unfixed bugs and unsolved problems. If you’re a perfectionist you may delay shipping too long, which paradoxically can *hurt* product quality over time because you won’t get as much customer feedback to help you prioritize what’s needed next. Of course, don’t ship crap! But if like many successful PMs you tend towards perfectionism, consider shipping earlier than your instincts say you should.

If you're not embarrassed by the first version of your product, you've launched too late.

Reid Hoffman

As a product manager, being embarrassed about the product you’re shipping isn’t just normal, it’s often *required*. And not just the first version; for every other version too!

A PM’s job is to find flaws in the world and then fix them. If you’re a shipping a product where you can’t see the flaws, it either means you are unable or unwilling to find the many flaws in your shipping product (bad!) or that you’ve waited too long to ship this version of your product (also bad!).

Product Management rewards perfectionism

In my experience there are two kinds of junior PMs: “sloppy” and “perfectionist”. Sloppy PMs tend to struggle in the role, because everyone is always yelling at them. Engineers yell because PRDs and user stories are vague and incomplete. Customers yell because features don’t work right. Designers yell because the company is shipping incomplete work that they’re not proud of and that makes them feel bad. Execs yell because people complain to them and crap flows downhill. As a result. sloppy PMs are often stuck in junior roles or leave the PM discipline altogether.

But PMs with perfectionist tendencies tend to be rewarded. Developers are happy with precise PRDs and wireframes with details included and edge cases considered. Customers like using a product that’s polished and has few bugs. UX professionals appreciate the time to build and test multiple iterations of increasingly better designs. Execs are happy that no one is yelling at them about a product that’s riddled with bugs. As a result, perfectionist PMs get kudos and promotions.

But perfectionism also has a huge downside: it’s slow! The rest of this post briefly discusses the costs of perfectionism and its accompanying slowness. Then I offer some simple tips for how perfectionist-leaning PMs can tame their inner OCD and learn to love shipping sooner.

Reasons why it’s OK to ship sooner

Full disclosure: like most successful PMs, I’m a perfectionist. When I shop at the supermarket, I arrange cold food on one side of the cart so that at the checkout I can pack all cold items into the same bags, making unpacking at home is a few minutes faster. I keep checklists for different kinds of trips so I never forget what to pack. I wash dishes immediately instead of letting them pile in the sink. I notice when UI is one pixel out of alignment and it drives me nuts.

So my advice in this post applies to me too! Below is what I repeatedly tell myself to tame my inner OCD perfectionism. Hopefully it will help you do the same.

Your customers are in pain because you haven’t shipped yet

Many discussions around product quality in a tech startup revolve around the question of whether the current level of quality is sufficient to ship. But what these discussions often fail to consider is the other side of that coin: what are your customers currently experiencing *before* you’ve shipped? In other words, you need to always be comparing your product’s quality not just to some theoretical standard, but to the actual state of your customers’ current work environment.

Customers’ tolerance for product flaws is related to this current state. If, like all B2B startups I’ve joined, you’re selling a product into a market with bad solutions or you’re solving a problem with lots of customer demand but few competitors, then customers may be very tolerant of flaws. Dropbox and Expensify and many other products succeeded not because their initial products were so good but because their customers were so dissatisfied with current solutions that they were willing to overlook an incomplete product. You don’t have to be perfect, you just have to be much better than the alternative! And after hundreds of B2B customer visits, I can tell you that the alternative to your buggy product is often much, much worse.

Your customers are probably in pain RIGHT NOW, and they are depending on you to help them. So even if you’re not satisfied yet, it’s likely that they’d want what you have right now, not because what you have right now is so great but because what they have right now is so bad. Don’t deny them pain relief today!

Make it better after you ship

Most tech products iterative. There’s always another release. Getting the revenue and customer learnings from having a shipping product is usually better than continuing to polish it in the lab.

You don’t need to fix every problem and optimize every feature before you ship. Sometimes you can ship and then fix, which has a few advantages:

• Your customers’ usage and feedback can help you prioritize what to fix first

• The broken things may not actually matter enough to customers to be worth fixing

• Your customers can benefit from the features in the meantime.

For example: at a startup with a freemium-SaaS business model, I was working on a feature that improved discoverability of one of our most popular behind-the-paywall features. When we shipped this change, it boosted our paid signups by 60%!!! But while building this feature, our head of Design demanded many design changes before we could ship the feature. All of these were good changes; they made our app look much more polished. But, as is often happens, correctly implementing these changes across all browsers with multiple rounds of internal feedback pushed our ship date back about 2 weeks. This delay cost us about $60,000 in lost revenue! If we’d shipped first and then fixed UX quirks that most of our customers probably wouldn’t have noticed, we’d end up with the same UX but also more customers, more revenue, and faster headcount growth.

To maximize product quality, ship earlier and more often

A great way to find the flaws in your product, and to learn which flaws are most important, is to ship the product! Customers inevitably value different things about the product than you will. They will find different flaws. They will ask for things you hadn’t thought of. They will teach you things about your product and their needs. But you’ll never learn all this unless you ship.

It seems intuitive (especially to PMs like me with perfectionist tendencies) that spending more time to improve quality will result in a higher-quality product. This is true…but only for one release. To improve quality across time, the most important ingredient is feedback and usage data from real customers using your production product. You can’t get that if you don’t ship!

This means that, paradoxically, sometimes the best, fastest, and most cost-efficient way to improve product quality is to ship imperfect software. Afterwards you can prioritize fixes and improvements based on real customer pain, not just what you imagined beforehand might be problematic.

Most customers are less of a perfectionist than you are

You are not the customer! A big mistake for PMs is assuming that your customers have the same opinions about your product that you do. This is never true. What usually *is* true is that most customers are less sophisticated than you are about product usage and product quality. Your expectations are (as they should be!) higher than your customers’. It behooves you as a PM to internalize this fact, and to leverage this awareness to be OK with shipping sooner.

For example, when I work on developer-facing features, I repeatedly remind software-engineer colleagues that they are more experienced than most of their users, so we need to design accordingly. I even use a standard speech on this topic: “The median software developer (and hence, the median user of our features) is someone you’d never want to hire, you’d never want to work with, and you’d never trust to commit to your codebase. So when designing features for that person, don’t make features that you’d want; instead make features that assume less knowledge and worse judgement, and make APIs more resilient to mistakes that you would never make.”

Customers being less sophisticated than you are has a big upside: they may not care (or even notice!) product issues that would drive you nuts. So when you catch yourself wanting to delay shipping to fix something, ask yourself whether less-sophisticated-than-you customers will care enough about that problem to wait longer for the overall solution. If you’re being honest with yourself, often the answer is “no, they want it now.”

What work should you NOT skip or defer?

What does “good enough to ship” mean? What problems should stop you from shipping?

It’s always a judgement call, but I try to use simple guidance here: “will it prevent high-priority customers from buying the product, using the product, or providing the feedback you need to improve?” If so, fix that. This typically includes:

• Discoverability - If users don’t know your features are there, then you’ll never get the feedback you need to improve them. Make features obviously discoverable, even if it means unsubtlety or inconsistency in the UI.

• Core workflows - Spend an unfair amount of time on the things that most of your users do most often. Make those features great, at the expense of rarely-used features or features for a small subset of customers. If your entire app is a consistently good level of quality, then you’re doing it wrong.

• Differentiation - Also over-focus on things that you do much better than the competition. Skimp on other things.

• Reliability - If your app crashes all the time, you won’t get the feedback and your customers will be annoyed.

• Performance - Your app should load reasonably fast, otherwise users will give up and you won’t get feedback to improve it. Be careful to not spend time prematurely optimizing code and infrastructure that may not be the bottleneck after you ship. But if your app is already slow then investing in performance is often more important than one more lower-priority feature.

• Measurement & Feedback - Ensure you can understand usage and identify problems after you ship, both in automated ways (logs, analytics) and in communication channels between customers and you.

You’re not Steve Jobs

Many PMs hold Apple—and its famously perfectionist co-founder—as a model to follow. Apple’s approach of uncompromising design works well if you’re selling high-margin luxury consumer hardware like a Rolex or an iPhone, because customers who buy luxury consumer products expect near-perfect levels of quality in return for the price premium.

But most SaaS products, despite costing more than a Rolex, aren’t “luxury goods”. In B2B, our job is much less sexy. We build digital office supplies¹: practical tools that save time and/or money for business customers, or that help those customers do things they couldn’t do otherwise. They’re paying you for “better” and, crucially, “sooner”, not for perfection.

Several years ago I was talking to a B2B startup founder who told me that he expected the graphic design polish of his apps to be “as good as AirBnB”. It was hard for me to agree with him, because all I could think about was how his customers would almost certainly be thrilled with “90% as good as AirBnB” design polish delivered with 2x the features 2x sooner. Perfection is expensive in labor and calendar time, and in B2B where you measure success in revenue and customer satisfaction, it’s really hard to justify the opportunity cost of perfection.

This doesn’t mean you should skip important UX, performance, quality, and other work in your product. If your customers can’t use your features or can’t discover that they exist, then fix that before you ship, both because customers (even business customers with lousy existing solutions) expect software that works well. But here’s what they don’t need to buy or use your product:

• Every font, color, drop shadow, and border radius is consistent and beautiful

• Everything is gracefully animated with just the right amount of whimsy

• Every known edge case is handled with dedicated UI and super-clear help text

• Every multi-step process has been unified into guided workflows

• Every feature can be used without looking at the docs or contacting support

UX polish should absolutely be added over time, especially when it comes to usability rather than aesthetics, but lack of polish shouldn’t stop you from shipping. The best way to figure out where you need more polish is to… ship something without enough polish!

Don’t obsess over bugs vs. features

On Engineering teams, there’s a distinction between a “bug” (something that doesn’t match the intended design) and a “feature request” for a different intended design. If I had a dollar for every time I’ve had to argue about this distinction, I’d be rich!

The result of this distinction is often that “bug fixes” are prioritized over “features”. Engineers will push back on scope creep far harder than pushing back on fixing bugs in their code.

But customers—especially non-technical ones—don’t make these distinctions, and you shouldn’t either. Customers just care about whether the product does what they want, not whether it does what you intend. Sometimes it doesn’t do what they want because the feature doesn’t work the way you intended, aka a “bug”. Sometimes if doesn’t do what they want because the design of the feature is bad, aka “not a bug”. It doesn’t matter. So prioritize your work accordingly, and be willing to leave some bugs unfixed if you can trade those fixes for filling a more-important feature gap that needs to be filled instead.

Downsides of shipping early… and how to mitigate them

Above I tried to convince you to ship earlier than you otherwise want to. But it’s important to be clear-eyed about the tradeoffs involved. Usually those tradeoffs are worth it, but they do exist. This section is about problems you may run into, and how to work around them.

It’s hard to convince others if you don’t believe

PMs live in a state of perpetual dissatisfaction about the currently shipping product, because by the time you’re shipping the current version you’re already planning the months-from-now version which is going to be SO MUCH BETTER. Also you’re painfully aware of all the tradeoffs and compromises that had to be made so you could ship today’s product. Any large product ships with hundreds if not thousands of known bugs, design flaws, incomplete features, etc. And that’s just the known ones! If you fixed every bug and polished every feature, it would never ship and your company would go out of business.

But the success of your product often involves convincing everyone else (Sales, Marketing, your users, journalists, etc.) that your current release is the BEST PRODUCT EVER. Otherwise why would they sell/promote/buy/write about it? So as a PM you're always hiding your embarrassment from almost everyone. This can be emotionally draining.

What matters isn’t what you think (e.g. embarrassment), it’s what your customers think. Will your customers like/buy the product? Will *they* think you should be embarrassed? Their opinion matters more.

My advice is to keep reminding yourself that shipping early is a benefit to your customers and to your company. You’re doing it for them, not for yourself. The more you can keep your mind and empathy focused outwards, the easier it will be to convince others.

Don’t ship a *relatively* worse product; instead, go where the competition is worse than you are

If you don’t have the time or capital to ship a product that’s good enough to meet market expectations, then don’t go head-to-head with a competitor’s polished product, because you’ll probably lose and if you don’t acquire customers then shipping won’t help you. If you’re selling into a market with existing high-quality solutions, then it’s not OK to ship crap. Tesla can’t ship a “just OK” car given that they’re competing with BMW, Mercedes, etc. which are already pretty great cars.

Instead, try to narrow your focus on a market segment with customers who don’t think the existing “high quality” solutions are actually meeting their needs. Win those segments, and then use the learning and revenue to expand into the mainstream over time.

Go back and fix things; don’t leave problems unfixed forever

One of the main reasons that engineers in particular are always pushing to fix the product before shipping is because they know that companies are really bad at going back after shipping to mop up remaining issues. This is a valid and justified fear! New features and products typically drive more incremental revenue than fixing bugs or usability blockers, so the incentives of most of your colleagues will push towards never fixing those annoying issues until they become intolerable.

This is bad! For example, in the early 2000s, the frequency of security bugs in Windows became so painful for customers that Microsoft stopped much of the engineering work on Windows for about a year to fix security bugs. Tens of billions of dollars of future Windows revenue was deferred in order to produce the no-cost Windows XP Service Pack 2 instead of a new version of Windows. Had the team proactively put more focus into security for a few years before, it would have been both a huge financial benefit *and* addressed the market perception (correct, IMO!) that Windows was a buggy mess.

The takeaway here is that incrementally cleaning up messes in your products is important. These messes can be usability issues for customers, technical debt, product bugs, performance, security, etc. And if you don’t proactively plan to fix them, then they’ll pile up and fall on you and your customers like an avalanche.

For technical debt, I wrote a post about how to deal with it:

The same approach works for other kinds of “product debt” like usability blockers: carve out a percentage of your capacity to fix things. Think of it like insurance: a small amount you pay on a regular basis to avoid an avalanche of badness later.

A perhaps-unexpected benefit of regularly cleaning up technical and usability issues is that your engineers, support people, salespeople, etc. will start being more comfortable with shipping sooner, because they’ll start to have confidence that when you say “we can fix this later” that you really will fix it.

Quality is important! Don’t ship crap, especially if it’s hard to revise.

As a PM you DO NOT have a license to ship crappy products every time. Figuring out when a product is good enough to ship is an important skill it will take time to learn. But for the people who grow into good PMs, what usually takes work to learn is the habit of shipping sooner than your perfectionist, aspirational instincts tell you to. Good PMs will just ship the damn product anyway. But it’s a learned skill for most PMs, not something that comes naturally.

Tune your “good enough to ship” bar to the cost of fixing what you mess up. If fixing means patching a few lines of code or making an online form more usable, ship early and often. If you’re selling hardware, especially expensive hardware (e.g. cars, spaceships, etc.) your quality bar is obviously a lot higher because a product recall can bankrupt you. If messing up can kill people (e.g. medical devices) then please, please don’t ship crap.

Epilogue: Am I just recommending AI slop?

AI tools can help you ship more features and ship them faster. That’s good!

AI can also tempt you to make features and products larger and more complex (which especially in B2B can cause customer grief if you try to unwind them later), and can make it easy to pile up technical debt which can slow your team down over the long run. That’s bad!

So how does AI relate to my advice in this post? I think it’s too soon to tell. But my guess is that AI won’t fundamentally alter the advice that I’m suggesting you follow:

• Align your quality bar to the quality expectations to your customers’ current state, not your own perfectionist instincts.

• Recognize that shipping sooner can paradoxically increase quality over the long run, because you’ll learn faster what your customers really need.

• Over-focus on the highest-priority parts of the product, and skimp on the rest.

• Anticipate problems that shipping sooner may cause, and proactively plan to mitigate those problems.

I suspect that AI will continue to raise expectations about how fast software should improve. In that environment, winning companies must figure out how to thrive in a ship-sooner environment without going overboard and degrading customer experience too much. In other words, I think AI will be an accelerant that will make the lessons in this essay more important.

But things are moving fast… ask me again in a year. In the meantime, happy shipping!

1. “Digital office supplies” has long been my favorite analogy for B2B tech, borrowed from Gen X author Douglas Coupland who said “Microsoft without Gates truly is nothing more than an office supply company.” If you’re in B2B, you may think you’re building Apple Store but your customers think they’re buying Office Depot.