You really need to read part 1 before this post, or it won’t make much sense.
But the TLDR of part 1 is:
- In scale-ups you need to move away from the idea that everyone must know all the context and can do whatever they want. That idea slows everyone down and distracts them from doing their actual jobs, as you scale.
- Using written briefs, product and organisational leadership needs to explain what they want and why. Product squads need to respond with how they will deliver it.
- The result is trust, clarity, focus and speed.
AI-generated content in this article: None.
Where this pattern applies: Software scale-ups, 100-200 people. But it may apply more broadly.
Warning: Applying the wrong technique/pattern for a given context will cause negative effects.
This post covers objections, and also the process, timing and templates for making it happen.
Objection 1: How does senior leadership actually know what objectives to set? Aren’t they going to ignore customers and make terrible choices?
We’re talking about a scale-up here. So senior leadership should not be too divorced from the reality of the customers or the software. But in addition, this process acts as a forcing function to make sure they stay very much engaged.
Von Moltke, the inventor of mission command, created strategy for entire military campaigns. To do that well, he used reports from senior offices, reports from his own special team that he sent out to gather information, and… his own telescope! He needed insights about what was happening, and he made sure he got them.
By agreeing that the commanders’ intent is where alignment begins, “commanders” make themselves accountable for forming a good strategy. They’ll need to work with senior product, design and tech to understand their situation, and formulate a good strategy. The intention is to ensure that senior leadership sets up the systems and process to pull the information they need to them, from across the org. leaders who are not connected to customer and organisational feedback will become divorced from reality, missing out on the knowledge and ideas they need to make the right calls. They’ll also be perceived as aloof, living in an ivory tower, and similar.
You can see that part of the process captured in the diagram later in this post.
Objection 2: Yes, but what if the commanders really are misguided and are doing the wrong thing?
Unlike many of Von Moltke’s soldiers, you do have the option to go get another job. If you’re convinced the commanders are driving the company to certain doom, then it’s best for everyone if you go get a job in a company that you do believe in. It’s best for your current org too, because you’ll be slowing them down if you’re not really aligned with the direction.
But before you dust off your CV, just check:
- Are you convinced there is a profound misjudgement, or is this just a matter different ordering: Certain things have to happen first?
- Do you understand the factors driving senior leadership’s choices, and the objectives you’re being set? Sometimes things like “We need revenue now or we’re dead” trump things like “Our customers would have a nicer time if…”
- Have you communicated your proposal crisply, convincingly and to the right people. Do not sit there saying “I have no voice”, just start speaking. Take charge, write a doc/make a video and send it to the senior leaders. Keep it positive.
Objection 3: What’s all this talk of commanders? It sounds like I just take orders and do nothing creative!
In The Art of Action, Stephen Bungay explains that beyond management and leadership, there’s that there’s a third dimension that excutives need to master: Command.
- Leadership is about making sure teams and individuals succeed at their task. Picture the leader of a SEAL team for example.
- Management is about organising and making resources available, so that teams have what they need to win.
- Command is the name that’s used in the military world to describe the process of defining a strategy and giving clear instructions so that the strategy can be executed.
Understanding that command is the “missing category” in leadership discussions really helps. The word “command” can be off-putting for people in business – we tend to use “director” and “directions” or “objectives” But once I understood what was meant by command, I realised it’s a wonderful thing. For me, the fresh use of the term brings fresh thinking.
Objection 4: Doesn’t this cause product squads to disengage?
Yes, if you do it wrong. But if you do it right, it makes squads breathe a sigh of relief.
Product squads will feel productive, valued and empowered if…
- You explain the reasoning and the amazing history behind the idea.
- You demonstrate that they get a lot out of it: Trust to own the how, and the right to demand a clearly defined what and why.
- Make sure you have good mechanisms in place to get insights and ideas from squads to leadership – clear channels with feedback so they can see evidence that their voices and ideas are being heard.
- Make sure that when a squad is having a planning week, the whole squad works together to create the plan/back-brief. This is hugely powerful, because it gets engineers engaged in understanding the strategy and objective and formulating the solution. No waterfall from product to engineering. No chance for developers be excluded from the ideation work that they actually love.
Timing, process and templates
Work backwards from when you want quarterly planning to be finished. Here are some key events I recommend.
|Weeks relative to planning week||Activity||Who does it |
|– 7 |
(7 weeks before)
|Gather recommendations from squad triads about what they think the objective for the next quarter should be and why. Do this “formally” and clearly. Put the ball firmly in the squad’s court to provide crisp, clear suggestions for recommendations, along with rationale.||Senior product leadership, squad triads.|
|-6||Create a strategic brief document for the whole of Product.||Strategic org leadership, product and tech leaders.|
|-4||Create product objective briefs, and circulate to the relevant squad triads.||Strategic org leadership, with product and tech leaders.|
|-3||Get feedback and create back-brief for org leadership. Iterate the strategic product brief.||Product and tech leaders.|
|-3 to 0||Discovery of problem space. This can involve user interviews, data analysis, stakeholder interviews, feedback analysis, problem trees, technical investigations, business analysis…||Squad triads.|
|0||Planning week. Squad creates solutions together. The squad writes a back-brief and plan document, led by the product manager. Negotiate plans to create agreed plan documents.||Squad triad. Product and tech leaders.|
|+1||Create integrated quarter roadmap for all of Product.||Product leader, product managers.|
There’s simple recipe for briefs in Art of Action. Here’s an outline with a bit more detail, for digital product.
Product objective brief for a squad
- Win state (what customers and the org will have, and be able to do, when the objective is reached)
- Why make this investment
- Trade-offs (investments we’re not making, so that we can make this one)
- Budgets (how many people, for how long)
- Scope / boundaries (how far to go, what not to do)
- Problem/solutions areas
- Press release
- Concept sketches
- Key business metrics (which major metric to move, direction, but probably not amount)
- Product team KPIs (adoption, leading metrics, performance…)
- Health metrics (what not to break)
This is created by the squad. Remember the rules of artificial certainty from the previous post: Create certainty to get speed, and there’s no shame in changing the plan when you get new information.
- Restating the intent, and response to the intent
- Outcomes and dates
- Milestone 1
- How we’ll do it – approach
- Delivery date
- Milestone 2
- … (as above)
- Minestone n
- Milestone 1
- Key business metrics
- Product team KPIs (adoption, leading metrics, performance…)
- Health metrics
Notes about the content of the foundational/context items
These are blog posts in themselves. But as a quick guideline, I think…
- The one-page strategic plan is a good way for a business to articulate everything it needs for the org-level strategy and goals to be clear.
- The product vision needs to articulate what the product will be like in the future, when we’ve made our goals a reality. It should contain personas, concept sketches and narrative copy. It should articulate the benefits that customer get from the future product. And it will need videos, presentations and workshops too.
- It works well if the the vision is based on a brand promise: a statement of what we promise to customers, why, and how we measure if we’re delivering on the promise.
To keep drilling into these essentials, read: Reforge 4D roadmapping.
There’s more to cover and more to learn in this space. So do feed back to me with learning and ideas from the battlefield.
 Defining the who
- Strategic org leadership: CEO, COO, any other clearly-defined strategy leaders (eg. Head of Strategy, Founder…)
- Product/tech leadership: VP Product, CTO, VP Design, and any other key leadership roles (eg Group Product Manager, Head of Data, …)
- Triad: Product manager, engineering manager, senior product designer