The Perfect Product — Part II

This is loosely based on a blog post I wrote for Atlassian. I’m breaking up some of those ideas into a few smaller posts here. Check out part I: Cast the vision, build the version.

Introduction to the blog series

Confession: I’m a perfectionist. I’ve learned that for me, the biggest impediment to shipping value to users is the temptation to pursue the perfect product. (Any other PMs struggle with that? Just me?)

I thought I’d share some thoughts across a few posts around focus, knowing when to ship, and ultimately, how to fight the perfect product. Part one focused on casting the version, but building the version. Now…Onwards to part two!

Part II: When to ship

Remember, it’s just a version!

As product managers, one of our goals as we move from casting the vision to executing the version should be to de-pressurize the room. No one, especially the product manager, should be wasting energy sweating over the perfect product. Why?

1. It won’t be perfect because it can’t be perfect, because a version is temporary! You’re just building a version — not the version. There is no perfect version. That’s the benefit of agile, iterative product development — you always get another shot!
2. It won’t be perfect because it can’t be perfect, because users’ problems will change! You spend your time researching, prototyping, and testing, and the longer you wait to deliver that value to users (even an imperfect first version), the greater the chances that their problems or expectations have changed or evolved.

So fight the urge to ship the perfect product. Because that’s an impossible goal anyway. Focus the team on shipping the right minimum in order to get insight, and then use that as a compass to guide future versions.

So…what is the minimum?

Minimum.

The one word that can mean so many different things to different people. Is it something that just…works? Or is it something that’s just shy of elegant? Something that’s at least 50% bug free? Something that solves most of the problem for the user? Or is it something that just ships on time, no matter what actually ships?

The minimum is not simply the smallest amount of work necessary to get something shipped as fast as possible.

Here’s a guiding light for the next time the team looks at you to settle the “when do we ship” debate: The minimum should primarily refer to what you need to ship in order to learn in as few cycles as possible. And then don’t forget to assure your team that there will be a “next” version: Cast the vision, build the version.

Be smart about what you determine as necessary for your first version, because a feature that’s purely usable, while faster to ship, may not return valuable insight if it lacks the right delight and polish.

That’s why there’s no one-size-fits-all description of the “minimum.”

If you’re a startup, you may still be trying to validate the business, in which case, ship before you build anything! Shipping doesn’t have to mean code — It could be a paper prototype or a landing page with sign ups. You need rapid insight and data more than anything else.

If you’re an established company, your minimum may be different. Your users probably depend on your product at this point, so you have a responsibility to make sure you’re shipping functional and delightful software with each version (even if they are just experiments).

Regardless of your product’s maturity, you’re still shipping when you’ve built the minimum that can return insight back to the team.

The challenge for you, PM, is having the intuition to know what the minimum is for your product and users at that particular point in time.

In conclusion…

You’re shipping to a moving target: Users. It will never be perfect! Stop wasting energy on the perfect product.

Perfectionism is paralyzing. Combat that by encouraging your team to ship sooner to learn, because your users’ problems may be changing as you’re building! Knowing you have another shot to ship the next version in an hour, a day, a week, or even a month will help you fight the perfect product.

I promise: You will deliver more value to your users by shipping software than by sitting on software.