Adil Majid
EssaysPhotosProjectsNotesBookshelfRecsPodcast
Ship by Friday
February 2024
10 / 10
COMPLETE THOUGHT
10-Point Article System
9 / 10
ALMOST THERE! NEEDS FEEDBACK AND TIME
10-Point Article System
8 / 10
THIS COULD PASS AS A COMPLETE THOUGHT
10-Point Article System
7 / 10
I COULD STOP HERE WITH ONLY MILD EMBARRASSMENT
10-Point Article System
6 / 10
ROUGH DRAFT IN NEED OF EDITING
10-Point Article System
5 / 10
HALF DECENT BUT IN THE VALLEY OF DESPAIR
10-Point Article System
4 / 10
ALL THE KEY POINTS (POORLY WRITTEN)
10-Point Article System
3 / 10
HALF-WRITTEN PARAGRAPHS / UNFINISHED ORDERING
10-Point Article System
2 / 10
SUMMARY OF ROUGH THOUGHTS
10-Point Article System
1 / 10
TITLE AND NOTE TO SELF
10-Point Article System
0 / 10
TITLE ONLY
10-Point Article System

If I was to boil down the most important rule learned over eleven years of shipping software, it would be: velocity above all else.

Velocity trumps everything. It trumps prioritization, code quality, design quality, feature completion, sales strategy, whatever else it is that you consider sacred.

Velocity is the cure to many ills.

I prefer to think of this rule as ship by Friday.

What is your job? Ship by Friday. Your job is to get the maximum amount of product out the door by the end of the week.

The amount of product that you ship is variable. The end of week release is not.

If we shipped more often, what would change?

Shipping more often unlocks customer feedback sooner, and customer feedback is the ultimate source of truth. Customer feedback to actual working software beats user research teams, subject-matter experts, talking to your sales guy, navelgazing, or whatever it is you’re currently doing. Everything else is a proxy. Customer feedback is reality.

Shipping more often unlocks customer usage behavior, perhaps more valuable than feedback. Are they using the new feature or product? For what? How often? What are they achieving with it? Does their usage behavior and feedback align with the rest of your roadmap, or would they actually prefer you go in a different direction? By monitoring your customer’s actual usage in addition to their feedback to your actual product, you can frequently adjust your product direction to be most accurate.

Shipping more often forces prioritization. You must release by Friday. What features will make the cut? Is it better to push for that extra feature or for QA? Pushing to Monday is not an option. You must decide. What can you not live without? Nothing makes your priorities clear like sitting in the pressure cooker.

Great, Adil, this is well and good – but I can’t ship faster. I have important customers with high expectations. A bad release is the end of my business.

It may be true that a shit release will end your business. There are workarounds. An easy one: set up an opt-in alpha or a beta program. You can incentivize it with a slight discount if your customers don’t bite. Now you’ve got a set of customers who have specifically opted in to the potentially messy world of software development. And you can continue shipping by Friday.

The discount or some other incentive structure may cost you a little, yes – but you’re paying for early access to ground truth. It is worth it.

A couple of mindset shifts may be necessary before you’re ready to commit at the altar of shipping by Friday.

First, a partial product is better than no product. And yes, obviously, a complete product is better than a partial product. But if your customer has to endure 6, 12, 18, 24 weeks of no product in order to get the complete product as you envisioned it… try to give them something along the way. Most products have a bite-sized version you can release that captures some part of the spirit of the whole and will be useful for you to get access to ground truth sooner.

Second, there is a paradox regarding the value dev time. Ship By Friday maintains both that dev time is a business’s most sacred resource and that dev time is not a business’s most sacred resource. The first few times you commit to shipping whatever you can by Friday, you might build the wrong thing, and that will feel like wasting dev time. But as you pick up real world feedback on a rapid cadence, your conviction in your roadmap will grow massively, and you’ll be much less likely to build the wrong thing.

Inverting the point a bit: if you ship whatever you can every week, then you can never waste more than a week of dev cycles at a time. By comparison, if you invest 12 weeks into a big release, you are closer to betting the house.

The best part about shipping by Friday is it is insanely addicting. First, it stops feeling like being in a pressure cooker. Then, you get addicted to the constant drip of customer feedback. You begin to think that it would be literally insane to not re-validate your roadmap on a weekly basis. You begin to feel a slight condescension to user research teams that spend hours assembling dossiers in order to save some dev time. You begin to appreciate just how quick and cheap software development can be if you would just get off your high horse about wanting to ship something more complete.

Addendum. It’s worth stating here that I don’t believe you should actually ship on Friday. Monday is probably a better option, in case you broke a bunch of stuff. But rhetorically, ship by Friday is exciting. You can’t log off for the weekend until you have something ready to ship Monday morning. And when it comes to setting an aspirational goal for a team, good rhetoric goes a long way.