This is why Shipping is so important to me

 

From the early days of our startup, I’ve been putting a lot of effort creating a culture of product shipping.
Developing a B2C product, our goal was to ship 2 new releases each month. At first, our releases included only our mobile apps (iOS and Android) but with the evolution of our architecture, we included more server-side updates (holding the majority of our logic) and back-end tools, almost on a weekly basis.
To me, shipping represents a strong execution, the ability to release frequent product updates, overcoming environmental uncertainties and resource limitations.
I believe it’s proof that the product and development team has built an efficient machine.

There’s a huge difference between agile development and what I see as a shipping culture.

Shipping != Agile

Agile development is about short, iterative and incremental development cycles. While this is a prerequisite for frequent shipping, reality shows agile doesn’t guarantee shipping:

• A team can work in short development cycles and never really release the product. 
• Companies can work in sprints, invest time and money on agile tools, scrum masters, ceremonies, and still ship new product releases once a quarter. Is that shipping? 
• Startups can announce a new version every few weeks but if no one uses it - that’s not my idea of shipping either. 

“A rubber that never meets the road doesn’t get worn down and never gets a flat tire. “

G. Bouhnick, Jan 2019
(yep, that’s me quoting myself)

Shipping means you start something, finish it, deal with last-minute issues, cut down content if needed, make conscious compromises, package it up, integrate, configure, document and release it to the hands of real customers.

Shipping forces you to think harder

Leading a product is more than building a vision. It’s dealing with the details, dealing with the long tail of consequences caused by every decision.
Building a product vision is often much easier than dealing with the details and anticipating the challenges but when you need to ship a working release every 2 weeks, you need to be pragmatic: break the long-term vision into small doses and plan the route carefully.
The same goes with the engineering work: breaking down big items into smaller independent chunks, ready to be used in production, makes the development even more challenging.
If you do it right, you will see some amazing results long before you reached the finish line.

It's not agile development that turns a company into an agile one, it's the shipping culture.  

Shipping helps you steer the ship

It’s not the short development cycles that give the business flexibility you need, it’s the frequent shipping that gives the possibility to learn how new features are received by your users and how to proceed. Shipping brings the product manager one step closer to the users while monitoring their behavior and trends.

Shipping is like a muscle

You need to train your muscle in order to make it stronger and it’s the same with product shipping.


Product project management is tough, especially in hi-tech, where creativity is high and so is the appetite of the stakeholders.
And yet, if you wish to improve your project management skills you need to practice some tough exercises and strengthen your shipping muscle:

• Cut down features
• Say “no” to some stakeholders requests 
• Say “yes, but not now” to some stakeholder requests
• Say “OK! We’ll do it for this release!” to some stakeholder requests 
• Simplify a feature to be able to finish ship it on time
• Keep last minute bugs unfixed
• Deal with localization every 2 weeks

If the above list makes you feel uncomfortable - you are not alone. Those are the activities you need to orchestrate in order to become a shipping master. Trust me, it’s much nicer to deal with features cut and unfixed bugs when everyone knows you have another release coming in 2 weeks...

The power of habit

Sustainable progress is achieved through persistence, habits and small wins and not by a one-time effort.
If you replace 4 short workouts a week with a single, 5-hours-long workout, you won't make any progress, but the trauma might get you injured.
Regression tests, backward compatibility, localization, configuration, integration, submitting your apps to the stores - they all seem costly, but once they become a habit - the cost is approaching zero and the benefits remain high.

 The best part in having frequent releases is that it reduces the dependency of the business in each release and minimize the trauma caused by occasional delays or features drop.

Better teamwork 

Team communication, engagement, and accountability - they all increase towards the shipping date. There’s a healthy tension in the air. People are more focused and more cautious when they know that their changes are going to be live in a few days or even hours.
Tedious slack messages are replaced with efficient face to face work, and the entire team is working together - which is always great.

Frequent gratification 

There’s nothing more satisfying than to see the code you wrote a few days back, live and being used by real customers in production.
I believe that even the geekiest developers who care more about the code than their users want the products they develop to be successful.
Shipping frequent releases provide that sense of success and bring everyone in the team closer to the field.

If you are not there yet - give it a try

Product shipping is hard, but with the right mindset and some extra project management effort - it’s doable even if the company doesn't have a large team to support this process. While the main benefit is accelerated time to market, there are many other advantages in building a shipping culture.

If you are a product manager or an entrepreneur striving to create a shipping culture in your organization - here are a few tips that helped us get started and might help you as well:

1. Be transparent as to why the company needs frequent shipping
2. Define the heartbeat of your releases (I would start with somewhere between 1 week and 1 month)
3. Plan your backlog accordingly
4. Be ready to make product sacrifices in order to achieve a proper scoping 
5. Work with the development team to overcome the extra challenges of releasing small working chunks 
6. Help the team push forward the peripheral activities that come along with shipping - the first few releases might be painful in this respect 
7. Important: fuel back the development team with insights learned from the previous releases and how they helped to shape up current/future development items - this will provide their energy for the next cycles. 
8. Lead the process and solve obstacles as they occur until the process becomes a habit and a part of the team’s culture.

While you’re here - give some other posts a try:

• Early adopters - the good, the bad and the ugly
• Here’s to trade-offs and compromises. Your product‘s best friends.
• What to do when you can’t trust your customer, friends and even your mom
• UX writing: a comprehensive guide for designing text in mobile apps

This post has been published on www.productschool.com communities.
Follow me on twitter @gilbouhnick or subscribe to the Mobile Spoon newsletter to get my occasional blogs directly to your inbox.