It's a mantra you hear a lot in the world of software development.
Ship early. Ship often.
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 I thought I'd share a few things we're trying to help us ship updates and features earlier and more frequently.
Ship early
- 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.
- 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.
- 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.
- Avoid guess-athons. Watch this talk. Watch it now.
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.
- 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.
- 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.
- 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.
- Never stop questioning your assumptions.
Any thoughts or suggestions on how to ship updates earlier and more often? Let me know on the Twitters.