BA 33/52: Story, Themes, Tentpoles, Features
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.
Every release is a story.
Every story has themes.
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.
Every September and October, we would anxiously await the themes from Craig Federighi and Staff. These themes would guide our release planning for the upcoming year. These themes gave us context for what key big ticket features we will work on. We called these big ticket features tentpoles. This terminology and style of planning was from the Steve Jobs era.
I have never come across a simpler way to plan or set the strategy for a massive engineering organization like the Apple way. Perfect balance of leadership guidance, and engineering org autonomy.
In my experience, many leaders lean on process as a way to eliminate chaos that is generated when teams of teams come together to achieve a predefined set of goals and objectives. For these leaders, chaos is an annoyance, a disruptive force, a type of energy that has no value add. Frameworks like SAFe and Scrum all have an underlying promise that this chaos can be eliminated through a regimented set processes that will provide leaders more control to make their teams work more "effectively" and "efficiently".
The work at Apple felt chaotic and that was by design. Rather than eliminating it, we leaned into this chaotic energy, we harnessed it. Barreling down the release ramp, trying to design, build, and market a plane by the time we reach the end of said ramp with every team united around a single purpose - no matter what, this plane will damn fly and it will fly high. This was normal for us. This was the Apple way.
At Nike, watching teams miserably go through the motions of SAFe where everything feature or project needed 50 squads, a multi-day unnecessarily complicated choreography of forced communications between feature and services teams, I sometimes wonder how much energy would Nike have saved if leaders focused on giving teams themes to focus on.
By nature, the release planning at Apple was designed to induce conversations at regular steps. The goal was that the themes would help us stay grounded in the final outcome. Throughout development we would lean on those themes and the story to make sure our decisions (add scope, reduce scope, etc) never violated or drifted from the themes and story.
Process and regimented release planning is at best a false sense of control and at its worst designed to cripple the innovative energy that takes hold over a team of excellent engineers who will make shit happen when left to a task.
The vision has to be clear. The story must be compelling and worthy.
Why should I care about this?
Somewhere, at some point, some leader will come to you and say, "we need to be better at planning". Before you could say or ask any further questions, this leader forwards you an article or some blog post about "SAFe" or "Scrum" and says "lets do that."
OR, if you fancy corp, some bigwig consultant from M Inc sends a slide deck with the tagline "Digital Transformation through Agile Thinking by Implementing SAFe".
I exaggerate but you will be asked to make planning better. Before you do anything, start by asking yourself:
Is our current release planning process capable of telling compelling stories?
Do your engineering teams know what the vision is for the release?
Are they picking meaningful work that leads somewhere?
Then, before you try anything else, I want you to give the Apple way a try. It is very simple:
Ask your leaders, what matters this year or release cycle to them?
Are we focused on performance?
Are we focused on new shiny features?
What is the current customer feedback telling us?
Leverage your product team to understand opportunities and issues.
What is our story this release cycle?
For this story, what are our themes and tentpoles?
Then, communicate the vision, story, and themes to the design, marketing, product, and engineering teams and ask them to tell you how we make this story a reality.
Let the teams fill in the details; they should recommend and plan features around those themes.
Then, focus your energy on deciding which features align best with telling your release story in the most compelling way.
Here is an example of this in action from iOS 11, my last release before I left Apple:
Theme: Make iPad Better
Tentpole: Better integration between iPad and Pencil
Features:
Redesign Apple Notes UI
Handwriting recognition
Reduce Pencil drawing latency to 20ms
QuickNote functionality
Although this may seem simple on the surface but a lot goes into crafting the release story and themes. That is exactly what the leadership should be focused on. Then, let the design, marketing, engineering teams fill in the finer details. If this doesn't work for you, then my all means, nerd out on SAFe 🥲.
Until next time 👋 .
-Aadil
P.S.
One of the things I love the most is discovering new newsletters and reading sources.
I want to give a shoutout to Jakob Greenfeld and his Business Brainstorms newsletter which helps fellow entrepreneurs level up their entrepreneurial game. Each email includes paint points, trends, and frameworks specifically for founders looking for better business ideas.
Join more than 7000 creators and solopreneurs getting the free Business Brainstorms newsletter. Level up your entrepreneurial game and get high quality paint points, trends, and frameworks delivered straight to your inbox.
How was this week's newsletter?
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.
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.