One of our main goals as product managers as we move from casting the vision to executing is to de-pressurize the room – no one on the team should waste energy sweating over the perfect product. Instead, focus the team on shipping the best first version in order to get insight. Then use that feedback as a compass for future versions.
Confession: I’m a perfectionist. And for me, the biggest impediment to shipping software is the temptation to pursue the perfect product. That is, a product that every single user loves immediately.
How much to build? When to let go and ship? These are tough questions.
Cast the vision, build the version
Challenge yourself to fit your first version in a single iteration or sprint. It reinforces the fact that what you’re building is just that: the first version. (Because agile.) And it forces you to think in chunks rather than thinking of your product as an all-or-nothing project.
Remind your team that you’re building *a* version – not *the* version.
The goal for that first version is to inform future versions. Get that killer feature out as quickly as possible in order to learn as much as possible before building more. It won’t be perfect because it can’t be perfect. Versions are temporary things, and temporary just doesn’t work that way.
One of our main goals as product managers as we move from casting the vision to executing the version is to de-pressurize the room – no one on the team should waste energy sweating over the perfect product. Instead, focus the team on shipping the best first version in order to get insight. Then use that as a compass for future versions.
How do you know when to ship your first version?
There’s no magic equation for that. And the answer may vary based on your product’s maturity.
If you’re a startup, you may still be trying to validate the problem and business case. If that’s true, start selling before you build anything! Your first version could easily be a paper prototype. And why not? You can learn a lot from those. But if you’re an established company, you may be trying to validate the effect a UX change has on user retention. In that case, you can certainly learn from a paper prototype, but your users probably expect more polish on a first version. So ship your first version when you’ve built the minimum that can return insight back to the team.
Pro tip: As tempting as it may be to think that “minimum” refers to scope (i.e. “Cut all the polish because we’re late!”), it really should refer to the amount you need to ship to learn. You may not learn much from a feature that’s usable and works, but lacks user-facing delight. Be smart about how much polish and delight you remove in the name of getting it out the door faster. Otherwise, you may not get the insight you need.
Ship, ship, and ship!
Perfectionism can be paralyzing. Combat that by shipping sooner rather than later. In the long run, you’ll learn more and deliver more value to your users by shipping software than by sitting on it.
No matter where you draw the line for your first version, aim to start simple and build iteratively. (And believe me: that’s really hard for a perfectionist like me to say.)
