Every iOS release planning at Apple started with a story and themes and this story is what we showcase at WWDC and to the world. If you need to plan better why don't your give the Apple way a try - Story, Themes, Tentpoles, and Features.
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? I.e.
- Was this an all hands event that the whole company attended to?
- 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.
- 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?
- 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?
- 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”)
Maybe there’s enough material to keep me hanging for another blog post.
Joe - these are amazing questions and most definitely a blog post in there lol. Let me dedicate some proper time to these questions and give you full and complete answers this week. Luckily enough - this fits well in the wheel house for Systems of Work which I am dedicating my writing to lately. 🙏 ❤️ 🙇
I would say different planning mechanisms can be applied to different type of organizations. For traditional companies, the requirements could come from different business units, and there is no one overall story/theme. Different development teams have to prioritize their work. For each business units, the features mostly have dependencies on multiple systems. Without understanding that dependencies and aligning them up, you may not get the features working. Certainly there are better ways to understand the dependencies and align them up other than several days of BFMs.
I do think regardless of the autonomy engineering teams enjoy at any organization, the story and theme has to to be central otherwise we are a thousand ships drifting in a thousand different directions and part of the input for that overall story comes from Business and Product as well.
Ex: Nike is composed of such a matrix organization that it is sometimes frustrating for new members to find their heading in the organization. Yet, you can have stories and themes like "Membership: Improve membership by 10x" or "Performance + Quality: Improve product search performance by 2x" or "Marketing: Access to 1st party user data for target marketing campaigns".
Everything needs a story and I think leadership that spends too much time micromanaging rather setting these stories (which can also be OKRs, Goals, etc) are wasting everyone's time.
Agree. The top leader of the program or initiative needs to clearly define the story and themes, so the teams can rally around, plan ahead and implement the features to materialize the story/themes. Even in infrastructure/platform/operations space.
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? I.e.
- Was this an all hands event that the whole company attended to?
- 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.
- 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?
- 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?
- 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”)
Maybe there’s enough material to keep me hanging for another blog post.
Joe - these are amazing questions and most definitely a blog post in there lol. Let me dedicate some proper time to these questions and give you full and complete answers this week. Luckily enough - this fits well in the wheel house for Systems of Work which I am dedicating my writing to lately. 🙏 ❤️ 🙇
I would say different planning mechanisms can be applied to different type of organizations. For traditional companies, the requirements could come from different business units, and there is no one overall story/theme. Different development teams have to prioritize their work. For each business units, the features mostly have dependencies on multiple systems. Without understanding that dependencies and aligning them up, you may not get the features working. Certainly there are better ways to understand the dependencies and align them up other than several days of BFMs.
I do think regardless of the autonomy engineering teams enjoy at any organization, the story and theme has to to be central otherwise we are a thousand ships drifting in a thousand different directions and part of the input for that overall story comes from Business and Product as well.
Ex: Nike is composed of such a matrix organization that it is sometimes frustrating for new members to find their heading in the organization. Yet, you can have stories and themes like "Membership: Improve membership by 10x" or "Performance + Quality: Improve product search performance by 2x" or "Marketing: Access to 1st party user data for target marketing campaigns".
Everything needs a story and I think leadership that spends too much time micromanaging rather setting these stories (which can also be OKRs, Goals, etc) are wasting everyone's time.
Agree. The top leader of the program or initiative needs to clearly define the story and themes, so the teams can rally around, plan ahead and implement the features to materialize the story/themes. Even in infrastructure/platform/operations space.