Lessons on Effective Release Planning From Apple and Google
Issue 008 - Lessons and observations from my time at Apple, and Google on making your annual, quarterly, or regular release planning sessions successful.
Welcome to the 8 new travelers ✌🏾🙌🏽 🥳👥🙏🏽 since my last essay. Drop by drop we make an ocean grow. I look forward to hearing your feedback on the topics I write about.
If you’re just passing by, enjoy the writing; maybe, if you change your mind and want to stick around, try hitting the subscribe button below. It will be fun, I promise.
Here are some pieces you might find interesting:
I will see you all on the social - @aadilmaan.
O.
Release planning season is here, underway, almost over, done.
I wish you all the best.
Figuring out what to build next is an exercise in prediction and retrospection. You are looking the past, present, & future at the same time.
Getting down to brass tax - objective is high value, low cost outcomes.
So, what are we working on next?
Some organizations will take the top down approach.
Some will take the bottom up approach.
Some will take a middle out aligned to the top.
At Apple, our annual release planning for iOS began in September/October with theme's for the release coming from Craig Federighi and directs. Each theme had a exec sponsor (VP of a functional group with the most expertise in the game). Then, the engineering, product marketing, business, design, project management teams would develop tentpole features (these will be showcased on the stage at WWDC) and non-tentpole features (equally important but may not get front-stage at WWDC) from existing roadmaps or develop new ideas to be reviewed and approved by Craig and directs. This was the top down, bottom up approach.
At Google, with the diversity of products and constant experimentation & cross collaboration between product teams, releases were matched to the ultimate Google wide OKRs. This was the top down, middle out approach. Certain teams had a top down approach, like Android.
Tactically, release planning is the act of balancing between ambition and reality across 3 time horizons.
Short-term - This is your upcoming release, the one you are planning.
Long-term - That is your North Star stuff, planning release + 1 (often + 2).
Universe - This is a future we know exists but it is too early to predict. Much of your R&D dollars will go here. These are the moonshot ideas.
Each time horizon has it's own set of inputs from which the work to be done is chosen.
Short-term: It is quick wins, existing roadmaps, technical debt or quality improvements. For some organizations, its the immediate money maker moves.
Long-term: North star visions, bets, opinions, R&D (Special Projecrs Groups, Google X, Area120, incubators etc), anything that isn’t focused yet on monetization but rather exploration. Some of these will eventually make it to the short-term time horizons.
Universe: Consists of, but not limited to, consumer trends/expectations, new tech, competition.
So, how do you make release planning successful?
Here are some observations and notes on what goes it an effective release planning exercise that I have picked up from my years at Apple and Google:
Ensure alignment across short-term work and long-term ambitions and commit to it with zeal and patience.
Constant feedback loop from frontline engineering teams to VP and C-Suite is necessary. Earlier in the process the better.
Don't commit to something if you cannot staff it - If you get the okay from leadership to hire, don't present any hard deliverable dates based on butts not in seats yet. Hiring is hard and it can often take months to find the talent; hiring contractors is only good for a stop gap measure.
Don't commit to something if you cannot test it - Unless, you have robust testing infrastructure in place, quality testing must be treated equal to development. (You will be surprised how often this doesn't happen and testing is an after thought).
Don't commit to something just because you want to do work.
Always intersperse dedicated space and resources for quality bug bashes throughout the release. (Either as Top 10/100 quality bug bash, or whatever).
For organizations with revenue impacting work, examine the math behind the proposed revenue increase/impact numbers with each proposed work item.
If you are leveraging data in anyway, Privacy By Design is an absolute.
Be honest, be factual, leave the emotions and optimism at the door.
When in doubt, bring options to decision makers but come with recommendations.
Always plan for outcomes, not the work. Actionable over aspirational objectives.
You may build it once, but maintain it forever, so build it right the first time and to do that, you need to have the patience and endurance to play the long-game with your bets.
Nothing is permanent, build checkpoints throughout the release and plan to make adjustments as the uncertainty reduces as time passes.
Build or buy - build is painful and difficult in the beginning but always better in the long-run. Buy makes sense if you are small and nimble organization and need to unlock immediate wins
Get input from everyone in preparation for the big release plan gathering (engineers, product, program, quality, every voice is important).
You will be tempted to flesh out all the dates down to the day, don't. Focus on time windows rather than dates (quarterly, monthly, perhaps even week).
You can create amazing thing's by re-arranging old things. You don't always have to build something new.
Wishing you all a happy release planning season.
How would you rate this week’s newsletter?
😄 Great — 😐 Average — 😒 Not Satisfactory
That’s it for this week. See You Next Time! 👋🏽
If you enjoyed reading this, please do share with your friends, family, colleagues, Linkedin peeps, twittersphere, or you know whatever/wherever you have.