So, it’s four weeks into a project, and you’re running into a few problems. First, your teams aren’t sure what resources they need to bring to bear. One engineer, for example, is now half-time after you’d have sworn you had her for a full six weeks. Second, no one is really sure about what this project is about. The team seems to get to similar places when discussing the “why” behind the project, but it takes a lot of prodding. And finally, leadership isn’t really clear on how this project supports the company strategy.
You’ve been working with an epic you wrote weeks ago. After the kickoff meeting and the creation of a shared product requirement document (PRD), we should be aligned.
Is this just how this works?
Or is there a better way?
I’ve run into this situation frequently in my ten-plus years of product management and team-building experience. Keeping teams aligned after the initial kickoff is a struggle, and that goes double for leadership.
That is why I have shifted from working on “epics” to crafting initiatives. This seemingly small change has had a huge impact on how my teams, colleagues, and leadership think about the work. It’s also made us more aligned.
Before we discuss the initiative model, we’ll go into epics and why they let the above scenarios happen, how initiatives drive better team alignment, and how to get started with initiatives at your company.
What’s an epic (and why does it encourage misalignment)?
Epics are what most companies use when they work with an Agile process. They are a mass of work that is made up of user stories — the smallest components we use to parse out work the sprint level. An epic consists of a couple of sprints of work.
Epics are organizing tools to help bundle up user stories, tracking work across sprints. That’s it.
An epic is simply not structured to promote alignment. In fact, epics can damage alignment by encouraging siloing of various teams. There is no real process, and how much effort is put into epics depends on the product manager who writes them. I’ve seen both well-written epics that consider everything that can possibly happen to lackluster ones that are just a few sentences. With no structure, the results are haphazard and usually end up in the place above, with no alignment after a few weeks on a project.
Also, the product development team is often looking at the epic first if they look at anything at all. Most other documentation feels esoteric and heavy. If you’ve had a PRD that someone outside the product team has looked at more than once, I’ll buy you a drink.
To align properly, we need something short enough to capture folks’ attention while also providing the most important data. Part of our role as product people is to be the protectors of company efficacy. All wasted effort is money burned, and that is something we should strive to avoid.
That is where the initiative comes in.
What’s an initiative (and why does it encourage alignment?)
An initiative is another way to structure your team’s work. Unlike an epic, it fosters alignment because it forces you to lay out assumptions upfront. Epics are a continuance of the status quo, which in most places, means a reliance on hidden inferences. The initiative process helps push those assumptions into the light, making sure you don’t go into the project without help. Bright, clear definitions let you understand underlying long-term priorities.
By writing out the company history and simplifying it, you’ll get a better understanding as to why this project either fits or doesn’t fit into the organization’s direction. This compounds with later projects, as you get better tools for storytelling.
The conversations you’ll have around this document as you are building it as well as after it’s done brings a level of trust. It’s consumable and available. Unlike storing epics in Jira or GitHub, where people who aren’t technical aren’t likely to go, this document is something you can ship to leaders and start sprints with while keeping everyone aligned.
How to get started with initiatives
For your next project, you’ll be tempted to write an epic like you’re used to. Don’t.
Instead, you’ll want to take a step backward. To help you understand what an initiative looks like and how it can help you and your team stay aligned, take the time to write one for a past project. You can skip the asking part. You’ve already done the work — it’s just a matter of writing all of this down and making sure you understand the importance of each part of the document.
Why is this step important? Because you’ll need an example to show to stakeholders to make sure it serves their needs. Every company is different and you may need to adjust the initiative to build a document that truly works for everyone. This goes double for the product team. My bet is they have the same annoyances you do and gathering their feedback on this document will get the entire group on the same page.
Building the initiative
The act of writing an initiative trains us to think objectively about the work we are doing. By going through this process and forcing ourselves to “check” if we should move forward, we have the opportunity to stop bad projects before they start.
Each section, when done correctly, forces a conversation across the organization, giving us a temperature check on the internal politics and keeping leadership aware of how product work happens. Projects look less like gut decisions and more like a product.
There are five parts of the initiative one-pager, and each is important to keep everything in line. Each of these five sections addresses common sources of misalignment and misunderstanding. By explicitly tackling each of them, you’re going to ship better products and have a better time doing it. You’ll also be encouraging alignment and collaboration throughout the process. They are:
- Abstract
- Company objectives
- Success/failure
- Resources and responsibilities
- Time scale
All five of these sections should fit on one page, and each section is designed to be a check on the next section. If your abstract isn’t clearly helping your company reach its objectives, you should have the ammo necessary to scrap the project. Same with company objectives, success/failure, and so on.
Abstract
For this section, you’ll need to sit and write about what you are trying to achieve, who is it for, what is it for, who is affected by the work, what success looks like, the history of the team, etc. This section is where you’ll spend most of your time. However, it’s the key to understanding what you are spending all of this effort to build.
This is the paragraph that outlines the work, and it needs to be short. Someone should be able to read it and repeat it. When writing the abstract, one technique to consider is the protostrategy method from Chris Butler — build a five-page outline, then cut that down to one page, and eventually, to a single paragraph. After completing the other four sections, you’ll come back to the abstract and finalize it.
Company objectives
How does this initiative tie into the overall product strategy? Your project should have a direct line to the company’s objectives and goals.
To get started, you’ll need to reread the company’s product mission/vision/strategy docs and relate your project to these overarching themes. Do not try to force a connection between your abstract and the company objectives. This should serve as a check to see if this is worth doing. And if it isn’t, you should stop here and make your case as to why this is a waste of time.
Success/failure
What does success look like? What about failure?
To start determining the answers to these questions, look at the abstract and start pulling the numbers. Think about survival, failure, and success, and explain it in terms anyone can understand. You’ll need to be very clear here. Describe exactly when to pull the plug, keep going, or double down. This will be the key to mustering your resources.
Resources and responsibilities
How are we going to staff this? Who is going to do what?
You want to collect all of this information in one easy-to-share place. You don’t want any surprises when the actual work gets going. Begin by looking at what (and who) is available and start talking to the folks involved to make sure they have an understanding of what’s at stake and what you need to get it done. If you are finished with the above three sections, you’ll have the data you need to move forward. However, remember it is their resources that you are going to need — they can say no.
Time
How long will this take? Leadership will want to know how you are going to use the resources available to complete your project, and on what timeline.
Start with an estimate of how many sprints the work will take. Try to remember Parkinson’s Law (things take as much time as you let them) and balance it with the Law of Slack (we never finish things on time.) You are never going to nail this, but an estimate will help folks make a “go, no-go” decision.
Finalizing the abstract
Now’s the time to look back at the abstract and finalize it. Can you contextualize the project more accurately now? With the data above, you should be able to write a clean, easy-to-read paragraph.
Does this sound like a lot of work? It is, but it’s worth it.
Be prepared to spend more than a few hours creating this document. Consider this, though. You are leveraging millions of dollars worth of time to your project. The thousands of dollars of work hours that you’ll spend getting this together is worth the investment.
Initiatives help us stay aligned
Wasted effort happens in every project. As a PM, you can’t stand over and watch everything that happens. But while we can’t avoid it, we sure can work to minimize it.
This initiative sheet does that, giving you a process for sharing the important parts of a project in a general way that folks can understand and reference.
The ultimate goal is the improvement of our decision fitness as a team, which is always worth thinking about. Otherwise, well-meaning product teams end up building something that has no tie-in to the project, then wondering why it sits on the shelf.
