BA 35/52: The Tactical Side of Strategy, Vision & Storytelling
This piece is part of an ongoing stream of thought on Systems of Work. Together, these individual pieces form a playbook on how TPMs can leverage their skills to help teams do the work of doing work effectively.
Questions from Joe about my previous post on Apple’s approach to release planning:
This is incredibly valuable, I really appreciate you sharing this information, not something I’d find anywhere else. 🙏🏻
It seems that what other companies see as mere brand and marketing work to support launches, is the actual strategy behind product launches at Apple, a very concrete example of Andreessen Horowitz’s quote from The Hard Thing About Things “The strategy is the story”.
I love how this approach feels like a simple Vision (Theme), Mission (Tentpoles) and Ideas (Features) framework applied to product lines as a way to ensure clarity of direction. I imagine that Themes and Tentpoles were carefully framed and communicated to ensure there would be room for creativity but no misinterpretation.
Would you be willing to share more about this process?
Maybe there’s enough material to keep me hanging for another blog post.
Boy was Joe right about that last bit. These are some fun questions that I would rather answer in depth instead of in a comment thread. Here we go, Joe!
Was this an all hands event that the whole company attended to? Were features “handed down” from Frederighi’s team as a surprise to you or was something that your team would be suggesting as possibilities beforehand? As in; did Frederighi’s team own what feature would make it into the roadmap?
Once the Vision (Themes) and Mission (Features) is set, each individual leader (VP level or equivalent depending on the scale of the organization) would go back to the their respective teams for a walkthrough:
What is the story? (over arching goal for the release)
Who are the main characters and important plot lines (Themes and tentpoles and which exec will be sponsor for which theme area)
The task is now up to the engineering, design, product marketing teams to help fill in the details for to build the most compelling story.
At Apple, once Craig and his staff established the release themes and tentpoles, every team would begin to go through their respective roadmaps, backlogs, tech debt, customer feedback, all of it, to find the pieces that fit the release story. Those would be reviewed with the exec sponsors who will do a first pass at what feature would be prioritized. Afterwards, the multiple leaders will bring their respective feature lists back to Craig Staff meeting for the final sign off.
Once the feature list is blessed, it would be shared out with the entire software organization in written communication form. This is the easiest way to keep the teams aligned when you are 2000+ strong engineering organization. If you are an early stage startup, then I suggest an all hands to walkthrough with the whole company.
How did Frederighi and other leaders from different Product Lines or Business Units come together with a coherent higher level story at every WWCD? Most of the companies I worked for struggled to align views from different “siloed” departments.
I think there is a myth I need to bust here or rather explain the nuance. You have probably heard of stories about how Apple is secretive including even internal with some teams not knowing what others are working on. Although that maybe true for certain teams, what made Apple APPLE is the amount of communication that occurs between teams.
Although decision making is centralized, the DRI philosophy and framework at Apple ensures that tactical decisions are made by teams talking teams closest to the work and the accountability of that lies with the DRI. So, during the story sketching part of the release, all leaders from design, product marketing, engineering, technical program management, every key leader is involved and providing input.
Ultimately, decisions is centralized with the SVPs who report to Tim Cook like Craig, Eddy, Joz, etc. You want to break through silos, make it easy for teams to talk to each other and build an accountability framework that puts the strategic decision making to the leaders and the tactical to the frontline members of the organization.
Would this approach work for Apple main events for hardware as well? I’d imagine that, for example, Macbooks took longer to develop than a redesigned Apple Notes UI, so would that be a case of placing longer term bets on themes (i.e. “in xx years this will be a relevant theme in laptop computing”)
HW is a different beast altogether from software. Those M1 chips, well they were set in motion many years ago. Any given time, the Silicon Group at Apple is working one chips 1-4 years out. Same thing goes for HW components with any of the Apple product lines from iPhones to iPads to Macs.
Part of the yearly iOS release was what work do we need to do for the hardware trains this year.
For example: one of the iOS 7 tentpoles for the Hardware theme was the TouchID.
When you have release trains or bets that have varying lengths and development times, it becomes a challenge to keep everything aligned. Tactically, only one train can be in command; at Apple that was the hardware roadmap. If a software team is working on a critical feature for a specific hardware component or functionality and is at risk of missing the schedule, you go through this decision tree:
Can we slip the hardware?
If not, can we slip the feature?
If not, can we remove the HW component?
If not, can we do a beta announce and ship the full feature later?
If not, can we get everything else off the engineering teams plate and double down on the hardware feature?
Apple had perfected the art of ruthless decision making. The famous tagline: for 1 yes, there are a 1000 no. If it is not ready, don’t half ass it, delay the launch; if it is not ready, and it must go, then go all out (works nights, days, weekends) to ship it.
You mention different conversations at different steps in the release planning: were there any other internal events, forums, tools that Apple used to maintain guidance consistency with these themes?
The SW Engineering Program Office and it’s leadership team worked hand in hand with Craig and his staff and other SVP level leadership plus teams. The PMO set the deadlines for when what conversation needed to be had and what output was required.
Keynote templates were developed for how each cross-functional feature team would review their feature development plans with Craig and other key senior leadership from across Apple. Every P1 tentpole feature had to go through a feature review for the official blessing from exec stakeholders that the proposed in-scope and out-scope aspects of the features are good to go. This ensured nobody was ever surprised of what exactly are we shipping in each feature.
Once the release plan was ready, all feature reviews are done, the PMO was responsible for rolling up weekly org wide status for all active features under development using a custom internal tool. The Status report is organized along the themes and tentpoles. This may sound quant but this status report process kept Apple aligned with itself every step of the way.
A lot has changed since my time at Apple ended in 2017. The primary method for communication for us back then was email and keynote slide decks. Today‘s Apple uses Slack and a host of other tools that may have added more robustness to the process.
Ultimately, the consistency came from the most important tool of all: the right people communicating each other. I know that sounds ridiculous and obvious but unfortunately, obvious isn’t always easy. It takes discipline, rigour, accountability, ownership at every level, and the ethos that we all serve one purpose: building surprise and delight for our customers.
Until next time 👋🏽 !
-Aadil
How was this week’s newsletter?
Thank you so much for replying my questions. I’m still taking the time to dissect and digest everything as this is gold! Also taking the chance to possibly make another request; you mentioned a few books that made an impact on you, would you be willing to share a list of your recommended books? I’d love to hear your take on Project Management and Stakeholder Management there.
Pure gold as always!