A weak metaphor around the concept of waiting to ship things. Photo by https://unsplash.com/@igorovsyannykov

“Shipping early” is easy. “Shipping often” is hard

GoSquared
GoSquared
Published in
3 min readJan 18, 2017

--

Ship early. Ship often.

It’s a mantra you hear a lot in the world of lean software development.

But for such a simple piece of advice, it can be really difficult to stick to.

We’re trying to get better at this at GoSquared, so we thought we’d share a few things we’re trying out to help us ship updates and features to customers earlier and more frequently.

Ship early

Be clear from the outside on the value for the customer

Be clearer before writing a line of code on what you want to give to customers. What’s the point of this feature / improvement? Sometimes this takes a bit more deep thinking before diving into code, but it often leads to an update getting to customers faster in the long run because it avoids mid-stage pitfalls in the product development process.

If it’s better than what’s already in production, ship it

Get something to production as soon as it’s better than what’s already out there. Yes you can wait until it’s 100% of what you intended it to be, but if 80% is already better than what customers can see today, then it likely deserves to go out now. And the next 20% can go out shortly after when it’s ready.

If it’s usable, get it in front of a customer now

Debates about new functionality and UI ideas are rarely solved quickly through discussion internally. What usually leads to a clear decision and an agreement is cold hard facts, and real user feedback. The quicker you can put a real feature or updated interface in front of real users and ask them real questions and track real usage, the quicker you can make a decision to kill, improve, or completely change said feature.

Stop guessing

Even the smartest people and product teams waste time guessing and arguing about ideas without trying things out. “Guess-athons” is a good name for the blocks of time we waste on discussing ways to do things without building things.

Avoid guess-athons.

Watch this talk by Tom Chi on rapid prototyping and product management. Watch it now — you’ll be very glad you did.

Ship often

I think it’d be fair to say we have the “ship early” part a lot more nailed down than the “ship often” part.

Frequently shipping code, updates and refinements takes real discipline.

“Shipping often” requires listening to your customers and taking their feedback seriously. It requires tracking feature usage and interactions in your product carefully. It requires ingesting a ton of data, and swirling it around with all the other factors in your brain, and making a call on what and how you improve the product. It’s an art and a science and it requires military-like disciple to do properly in a product team.

Make sure you’re measuring it

Ensure when a feature is shipped that the key interactions are tracked — either with an internal analytics tool, or with something off-the-shelf. You wouldn’t believe how often teams get to a point where they want to redo a feature or interface, and only at that point realise they haven’t got any usable data to back up their decisions.

Do a user test

Get new features in front of users. Even if it’s just another team member who’s been less involved in the project at hand. Ideally get someone who’s a long-term user AND another who’s a complete novice, and see how their usage and interactions differ.

Make small improvements frequently

The longer you leave a feature or UI element, the less likely you’ll be to go near it again to improve it without wanting to rewrite the whole thing.

The best way to improve a product isn’t to tear it up every 3 months. It’s to continually iterate in small increments. Don’t let yourself or your team fear updating existing functionality. Rewrites and redesigns get all the attention, but incremental improvements add up to big changes over time.

Don’t stop

Never stop questioning your assumptions. Keep iterating and keep building momentum. It’s always so much harder when you stop and have to start again.

Want to be the first to get our future posts on product design? Subscribe to the GoSquared Weekly newsletter.

An earlier version of this article originally appeared on James’s personal blog as “Ship early. Ship often.

--

--