The advantages of frequent shipping
I’ve been preaching a lot lately about the importance of creating a culture of frequent shipping.
Whether it’s with my own team or while helping out some early stage startups, I keep finding myself explaining why it’s so important to stop thinking that things are not 100% ready and just ship them.
First, let me start by saying this: agile development does not guarantee frequent shipping; a team can work in an agile methodology, run short sprints and still release new versions to the market in a very slow pace.
What I'm taking about is the mindset to constantly put your deliverables to the test with real users, in real-world conditions, even when things are not fully ready. It’s the urge to show the world what you’ve created, even if it’s in early stages or provides limited functionality.
Shipping is that moment when the rubber meets the road and interesting things happen.
And yes, working with this mindset requires further effort: you need to break down pieces of functionality into smaller chunks that still provide value. It's not easy, but it totally pays off.
Let me explain why I’m so fanatic about it:
1. Shipping helps you validate your ideas quickly
I’ve seen young entrepreneurs working months (and even years) on building their first MVP. They spend their precious time and money on prioritizing features that are not top priority, instead of running small experiments and gain the confidence that their main ideas and assumptions are even worth the effort.
The same happens in larger companies where new products or new features are being developed for too long, aiming for one shot at the target as if things ever work perfectly in the first attempt.
Getting into a shipping mindset doesn’t mean you need to work faster, but it means you need to work smarter: find the most viable elements in your product, plan for smaller releases, and release them frequently and incrementally. Each release helps you gain more knowledge and gets you closer to success,
In theory, fewer product drops can save the overhead caused by each release. If you spend less on packaging, regression, releases, etc. the team can better concentrate on the actual development, but that's just in theory:
In reality, things never go according to plann, so it's much better to make the changes before you spend too much time and effort on the wrong things:
2. Shipping improves teamwork and communication
Good team communication is vital for efficient development and successful projects.
Sometimes all it takes is a short discussion with the product manager or one of the developers to figure out a way to solve a technical problem without even solving the technical problem at all (by bypassing it or compromising on the functionality).
As teams get closer to the shipping date, the level of communication, engagement, and overall accountability grows: long emails and endless Slack messages are replaced by short face to face meetings and pragmatic decisions are taken.
The more you ship, the better you get in closing items hermetically, and the performance of the team improves.
3. The power of forming a habit
I believe in small steps, backed by persistence, to achieve big goals.
In that sense, shipping is like a muscle that needs to be trained in order to get stronger.
You can’t replace 4 short workouts with 1 long workout. The impact is different and there are more chances to end up with an injury.
Shipping a product, even a small incremental change, comes with an overhead: regression tests, packaging, deployment, app-stores submissions - those things cost, but as the habit grows, efficiency improves, those costs are decreasing and that “muscle” grows and improves.
The more you ship, the less you are dependent on a certain release. If things go wrong and features are delayed or fail to achieve the outcomes they were supposed to - there's always the next drop.
In that sense, frequent shipping helps minimize the "trauma" caused by possible delays or feature drops.
Check out some more goodies:
- 5 basic mistakes product managers still make
- The good, the bad, and the ugly truth about early adopters
- Why do we suck so much in time estimations and what to do about it
Comments
Post a Comment