Why you should exchange your epics for initiatives

posted on April 27, 2020

a group of people sitting around a table with laptops — Photo by UK Black Tech on Unsplash

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.

BLOGLearn how to calculate your product engagement score

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.

[Lean] Building an internal growth process for your teams

posted on April 8, 2020

Use these two tools to Lean on learning to get your teams ready to execute better each time they work

white and green ceramic plates on brown wooden dining table — Photo by Juliette F on Unsplash

I’ve seen my fair share of companies.

As a former director of strategy for the incubator Cofound Harlem and a product strategist for the agency Philosophie, I’ve had the experience of keeping track of the strategy of various types of companies.

I’ve had to understand their past, present and future.

And in my last role, as the director of product for Informed, I moved from advising companies to building our own process. I had to ensure we execute whatever strategy the leadership and I come up with.

It isn’t enough for me to execute; the team has to, as well. As much as I can work on controlling myself, at the director level, it stops being about me. It’s about the folks I have the pleasure of leading.

You need a process to cover the gaps of your team’s capabilities, so you can make company strategy exist on more than Google Docs.

How can you do that?

This article gives you two tools to ensure you are moving forward with your team and growing a long-term strategy — not just standing still.

Let’s start with a mental model; I think Lean works well here.

Lean methodology

Lean methodology is a mental model that uses the term “Build-Measure-Learn” to create a feedback loop.

Although it is generally used for product development, I’ve found it useful as a starting point for building processes in tech companies.

Why? Lean is a known quantity in many product teams, and it’s always easier to build on a foundation that exists. There is one part of the methodology on which teams under-index. Read on.

Now we have a mental model. What’s next?

Life in product management is about priority, so let’s pick what we want to prioritize. It is my experience that there is one of the three parts of the feedback loop you need to focus on to help build a team that is better at executing on strategy in the long term.

That is learning, which is under-indexed at most companies. That is a shame.

The strategy isn’t just about the next sprint. I believe a good strategy helps grow the team, as they try to hit the goal. That is why tools, such as OKRs, when properly done, force your team to stretch.

Executing strategy well makes your team better, and over-indexing on learning will leave your team better than when you arrived.

five person by table watching turned on white iMac — Photo by Jason Goodman on Unsplash

What happens otherwise?

My experience in dealing with other companies has led me to see what happens if you “Lean” too hard on the first two words of the phrase in working with teams to execute. You’ll miss the boat. Here is why:

Building teams constantly execute

Build-Measure-Learn

Execution is excellent, except when you find yourself six months into a vision with nothing to show for it.

Let’s make it real with a marketing example:

A visible sign this is happening is in New York City subways. Nothing says a fresh round of funding like a subway ad campaign that just “exists.”

You know what I mean when you see them. The ads have some quirky saying, whisked from the mind of a newly minted top-15 MBA ready to show the world how smart they are.

https://cdn.embedly.com/widgets/media.html?type=text%2Fhtml&key=a19fcc184b9711e1b4764040d3dc5c07&schema=twitter&url=https%3A//twitter.com/aecushing/status/1214651153964847107&image=https%3A//i.embed.ly/1/image%3Furl%3Dhttps%253A%252F%252Fpbs.twimg.com%252Fprofile_images%252F1197246434380308487%252FdlaytXn0_400x400.jpg%26key%3Da19fcc184b9711e1b4764040d3dc5c07

This approach could work if you’re Coca-Cola, as you already have trust and influence. If you are Series-A Whatchamacallit, who cares, other than the team, when they get on the subway? I’ve been inside companies like this, and what happens is: They are given a strategy, and they are cranking things out.

Here is a quick way of finding out if you are in this situation with your strategy: Ask yourself if you’ve ever just stopped.

The remedy? Retro (retrospective) now and forever. You need to see if what you are doing is working, because my bet here is: The customer never gets a chance to make a promise, because your team is building too much to give them a chance.

That means you miss the boat.

Measure-focused organizations may be worse

Build-Measure-Learn

Instead of working on things, they are making sure they get the right KPIs. This comes in the form of triple checking and quadruple checking. In organizations, this looks like another focus group, another listening session or yet another internal iteration.

No one executes on anything, because they are worried about covering their asses (CYA). CYA tells me you aren’t there yet. CYA tells me you will measure forever. CYA means you won’t put work out in the world when it needs the feedback it deserves.

Our work doesn’t count until someone who isn’t paid by the organization can see it in the wild. We don’t know how this thing works, because we haven’t given it a shot.

Ask yourself this: When is the last time we launched?

The remedy? MVPs. We’re hitting the go button on X date. We are putting something out in the next 2 weeks. We’re getting data.

Your team never made a promise to the customer, because you are too scared to give them a chance.

You can’t go on a journey if you never get off the dock.

What about learning-focused organizations?

Build-Measure-Learn

It is my opinion that, if you are focused on learning, the rest handles itself. Learning-focused organizations never seem to have the need to call in help. Learning-focused organizations focus on two things: reflection and iteration.

Reflection: Ask yourself this question: Have you had a retrospective lately? Also known as “retro,” this gives you the place to pause and reflect on what has happened and how you plan to avoid it next time. It’s a balancing act. Great retros, when running well, have the participants ready to move forward while feeling their grievances have been addressed.

Iteration: What is the next step? Iteration is all about getting to the next step and executing it. How do we take what we’ve built and measured, take its flaws (hello retro), and build it into the next step? Iterating while executing makes sure your team gets aligned with the strategy.

Promises made lead to learning

There is a push-pull with building and measuring that leads to learning. The right metrics and getting product out are both critical, but unless we sit down to discuss what we’ve learned, and how far away it is from where we need to go, we’re not maximizing our teams.

Ask yourself: When is the last time you “learned” anything with your team, and when was the last time you took that learning and put it into the product?

If you can’t come up with an answer, it’s time to get back to the basics. You are building too much or measuring too much, and my guess is the strategy is bad.

What happens isn’t about measuring 10 times before you cut or cutting 10 times before you measure. It’s about executing the long-term strategy, so you can make things happen.

Lean on learning, and adapt the other two for a better process, and execute a better strategy today.

Fake vs. Real innovation: how to tell the difference

posted on March 24, 2020

brown wooden blocks with number 6 — Photo by Brett Jordan on Unsplash

Here’s a situation you may be familiar with. Instead of creating something truly new and interesting for your customers, your innovation team seems to be dragging their feet. This is an unwelcome surprise. After all, you created this team to give the company the moonshots it needs to get to compete in an increasingly crowded market. And, well, they just seem … stuck.

It could be the world conspiring, or (more likely) your innovation team isn’t set up for success.

My name is Adam Thomas, and I started working with “innovation” over ten years ago as the lead of new mainframe initiatives at DTCC. Since then, I’ve consulted as a product strategist at Philosophie for companies like PwC and Google, as well as built my own innovation teams in-house at Informed.

In my experience, most teams that are tasked with innovation aren’t given what they need to function effectively. These three blockers tend to be the biggest reasons for it:

The innovation team isn’t given a clear directive.
The innovation team is just building what leadership wants
The innovation team is seen as a “‘training ground”

In this post, I’ll talk about how these three situations happen and how you can prevent them so your company can keep pushing forward.

The innovation team isn’t given a clear directive

I started here because this is the mistake I see most.

When teams decide to innovate, they are usually are facing the maturity of a product line and/or high levels of stability. Or their backs are against the wall.

While those situations are drastically different, I’ve seen teams in all three circumstances make the same mistake: not being clear about how the team operates. Innovation takes a mindset that is vastly different from standard product development. Instead of success, you hunt failure. Instead of stability, you go for speed. You seek ugliness instead of beauty.

This isn’t clear to anyone who hasn’t worked on a team like this before. And when creating this type of team, it needs to be stated that we are here to roll our sleeves up and make mistakes until we get to moonshots.

The same goes for leadership. It is tempting to think of folks doing innovation work as extra resources, to pull when needed. However, you’re asking them to change mindsets, not just workload. That won’t go the way you think it will. The team will get “soft in the middle” — confident on the outside, but constantly curious when alone.

Combat the lack of clarity by making it obvious that the innovation team is there to do just that — innovate. If they have to go to different projects, make sure it happens constructively, not ad-hoc.

The innovation team is just building what leadership wants

Let’s consider company leadership again.

You built this innovation team and got them ready — why can’t they just make what you want?

It’s your company, isn’t it?

Sure it is. However, if you want them to build what you want more than likely it won’t be your company for long since you are wasting your and their time.

If you are ready for some straight talk, here it is: The team is there to innovate for the customers — not for you.

Innovation teams, even more so than standard product development teams, are research- and action-driven. You can’t do both and listen to leadership. There are too many voices and the room and you’ll slow the team down.

Moonshots are incredibly hard and require a bit of luck. Everything the team can do to improve confidence in themselves is critical for success since the market will be rejecting them constantly.

Taking that agency out of their hands is a death knell for these teams because it kills curiosity.

Combat this by not asking questions about the work, but only about progress. Leadership needs to care about decision and experiment velocity as well as success. Everything else slows the team down and keeps things from getting done.

The innovation team is seen as a “‘training ground”

So, I just mentioned speed. It’s tempting to put junior staff on innovation. I understand why because I’ve been there. The senior staff has a lot of things to worry about. You can throw juniors on it, then claim you care about the innovation team because it has a high headcount.

However, speed is super important to innovation. You need to find out if you can something to market quickly and make it matter to your customers — fast. That is where senior staff come in. They have been through a lot and can take a “no” here or there.

They also know who to talk to get what they need. Not having to hold hands during the process is paramount to getting things out the door. Plus, the senior staff knows where the bodies are buried. They will ensure quickness and are more than likely looking for a place to grow. Put the responsibility on them and watch them flourish.

Make sure you have at least a 2:1 ratio (two juniors to one senior) to ensure that the innovation team is working effectively.

Innovation is hard work

Some of the most rewarding work of my career came when I worked on and with innovation teams. I got a leg up on technologies like AI and VR by being part of innovation teams at the beginning of the decade.

However, it’s hard work that can be demoralizing, and the mindset shift is important to note because real innovation requires clear direction, customer focus, and the right staff to make it happen.

It’s an investment that can make your company millions, so make sure you treat it like that.

How lessons from wargames can help you ship products and build strong teams

posted on March 16, 2020

low angle photography of cranes on top of building — Photo by Danist Soh on Unsplash

We all know that product is hard, so here are some themes from a very playful activity that will help you get better at it.

Shipping products is rough, full of false starts, lousy execution, and a lack of will to kill products quickly. But a bad strategy creates a state of false hope, and can leave you and your team punched in the face after months of work.

As a product executive, I deal with the strategy all the time. One of my favorite jobs was as a product strategist at Philosophie. Philosophie focuses on innovation work in the enterprise, where ambiguity is the norm, not the exception. My job there was to focus my energy on finding the best strategies to create positive outcomes from the ambiguous problems of our clients, who usually didn’t have the time to deal with them.

Every engagement was different, and I had to learn how to apply different strategies to solve those ambiguous problems. The great thing about strategies is they translate well to other areas. They aren’t one to one, something I used to help a startup could potentially help a fortune 100 company, and vice versa. That translation is a good thing because to become a better strategist; one must implement a strategy. Like all product work, it doesn’t happen in your head. This wasn’t the first place I learned this, however. It goes back to one of my first loves, wargaming.

Wargaming is a hobby where people gather to simulate combat from different time periods. A game usually has a team trying to achieve an objective, using a rule set, dice and lead figurines to do so. In short, it is a bunch of people gathered around a table “pushin’ lead” and having a good time. Like wargaming, success, no matter how impressive your strategy, is not guaranteed. However, like wargaming, the right concepts can help any product manager increase their chance of success.

Wargaming looks like this:

blue and red boat during daytime — Photo by Elias on Unsplash

Pretty cool right?

The great thing about wargaming is when there is a challenging scenario, both skill and luck play a role in finding success. Doesn’t that sound rather like product management?

We may get lucky with building something. With that said, if you want your product to make a recognizable impact on someone’s life, strategy is essential. If one isn’t in place, the team will fail, given enough time. Good news! I think there are some quick heuristics that I’ve learned playing wargames that can help you make sure that your product strategy is well rounded.

I’ve picked out three that have helped me think about my next steps, shape overall vision, and communicate effectively with the teams I’ve worked with to help us execute successfully.

1. Rules Affect Implementation, not Direction

You better know the rules if you want to execute, with that said though, your strategy shouldn’t be strictly based on the rules.

In wargaming, the rules exist to bring in some order. We have to know what system we play in to make sure the scenario is clear and fun. At the beginning of the game, the person in charge, known as the game master, goes over the set of rules for the game.

In product, it may be the opposite. The market, stakeholders, and team dynamic make the rules. No one talks about them publicly, and you often have to figure them out as you go along. No matter though, either way, if you don’t know the rules, they can send you right to a confusing failure if you aren’t careful. With that said, you can’t let the rules dictate your strategy. If you are overly worried about a “morale roll” or a “stakeholder,” you can lose sight of the ultimate objective.

Remember: Strategies = Sets of rules. Knowing the rules changes your strategies on implementation, not the strategy.

2. The Goal Comes First, Everything Else is ego

At the end of the game, no one is going to care if your tank survived or you took Persia – did you win? In both product and wargaming, sometimes the name of the game is resource allocation. Questions like, “Where can I reinforce my attack?” or “What workshop can I do to improve alignment?” are always going in and out of your head. You can’t, however, forget that ultimately, every answer should serve the objective.

Sometimes, in wargaming, that means letting a territory go. In product, that may mean a feature has to die. If you don’t have a clear objective, every decision afterwards is tainted. If you have to stop and reorganize, do so. With that said, moving forward without your goal is a losing proposition.

Do whatever it takes to remember the goal in all things, even if that means you take the brunt of the punishment. Failure often happens because people get far too worried about what things “look like” and ego instead of the objective. Remember: Objectives = Vision. Sometimes we care about the aesthetics or the beauty of the code… in reality, we have an objective, and your job is to connect all the pieces together so the goal wins over everyone else.

3. Get Your Ideas out of Your Head, Then Commit

Talking with your teammates means focus and focus wins. When you huddle with your team, the best idea has to win. Ego leads us to believe that we have the best ideas. As a product manager, you may think that means your ideas are best. They aren’t, so don’t fall into the trap of having your title determine the strength of your ideas. That’s what happened to Napoleon at Waterloo.

Everyone has something to contribute, so get your thoughts out of your head. More importantly, facilitate other people to get involved. More ideas are better than fewer, so after they are out on the table, commit to the best idea.

The key to good teamwork is high-velocity communication. It means you listen, use your judgment to sift out bad ideas (even your own) and once the team has weighed in, decide and commit. Operationally this means that you should get your ideas out on the table and see what lives. Once they are out there, find the best option and commit to it.

Commitment doesn’t equal blind fanaticism. The landscape changes and leaders are malleable. Product is all about finding shifts and exploiting them.

Listen to your team and keep people updated. Don’t be afraid to take a break to understand next steps. Sometimes continuing to work for the sake of “progress” will leave an army, or product, dead in its tracks. Remember – decide and commit. You don’t have the best idea all the time, and one way the best idea is going to win is high-velocity communication.

Key Takeaways

Product is about helping teams to visualize a direction and execute to make it happen.

As Dwight D Eisenhower said, no plan survives first contact with the enemy. You’ll make mistakes along the way, especially when the “game” is on the line, much like when you are in crunch time with a product. The world is ambiguous, and your job is to help see that through. Strategy gives you flexibility and a position to pivot from, as well as a method to communicate with your team.

Remembering that rules affect implementation, not direction, that the goal comes first, everything else is ego, and that you should get your ideas out of your head and commit, helps you, as a product person, keep communication and trust high. As a result, you’ll ship well and more importantly, with consistency.

Product is a constantly shifting environment. Understanding the rules, knowing your resources, and communication can be the difference between success and failure.

A good strategy is a way for us to stay consistent and make sure that we keep our teams prepared for what comes our way. Even though it doesn’t guarantee victory, it does help us grow a community and build trust with our teams.

So, go out there and roll some dice. Your team will thank you later.

Additional menu