Tips for shipping faster, and better

As a Product Manager, you have to just ‘keep shipping’ [in Zuck’s words].

I will keep this very simple and straightforward, following tips can help you ship faster and better.

1. Plan your shipping. Know what you are shipping. Is it a feature, is it tech-debt, is it a hotfix, is it a platform? Once you know this, you will be able to plan your shipping. Larger features can be broken into smaller sub-parts. Hotfixes can go live on the basis of urgency. Platforms need much better planning.
2. Don’t ship an incomplete feature. A complete feature will work well without any further work for a long time (a few months, maybe years). You never know when you will pick up the feature again (you may never). Keep shipping, but not at the cost of tech-debt.
3. Always think of the Best Possible Feature (BPF) and trim down until you reach a Minimum Viable Solution (MVS). [Yes, I invented those terms.] But this is by far the most important point to consider.
4. Break the feature into multiple smaller features. For instance, if build a feature to cancel orders for an e-commerce platform, the feature can be shipped for active orders without a ‘Cancellation History’ of your orders. No feature ever is ‘perfect’. Know when to ship. Unfortunately, this is a skill that only comes with experience.

5. Make sure tracking is in place (Analytics events, event logs, etc for whatever tool/s you are using). This is super-critical. Since you won’t be able to track the metrics for or debug any issues in your feature in absence of this.

6. Think of edge cases. Edge cases are problem/s or situation/s that occur only at an extreme operating parameter. Take a call on which ones to solve for.

7. Communicate. Communicate. Communicate. Communicate to users. Communicate to internal stakeholders (Ops team, Sales folks, Business folks, end users) long before you ship. This is IMPORTANT!

8. Be prepared to rollback. This depends on what you are shipping. But ‘ always hope for the best, prepare for the worst’. Make features backward compatible. Put feature flags.

9. Test, test and then test again. But the thing is, the more you test, the fewer are the deployment cycles, and hence time consumed in shipping. FYI, 20–30% of the time in feature development normally goes in deployment.

Testing a new feature

10. Bonus: Never ship on a weekend. :P

By doing this, you can single-handedly ruin the weekend and mental peace of all the stakeholders working on the feature.

PS : These are some of the things I have experienced first hand. This no way is an exhaustive guide. Feel free to suggest changes/additions.