I’ve been spending lots of time recently thinking about and working with my team on what I can only refer to as “how we should spend our life force.” If that sounds weird, hold on to your hats because I’m going to make it even weirder by (and I apologize in advance) throwing a 2x2 matrix into the mix. So. Come with me in this post as we discuss how our biggest strength as product managers can easily become our biggest weakness, and how we can protect our health and sanity in the midst of all the turmoil in our companies and the world at large.

First, without getting too deep into the metaphysical or get myself in trouble about things I don’t know enough about, I do think it’s import for each of us to make conscious decisions to spend our “life force” on things that make us generally feel fulfilled and bring us closer to the person we want to be. That can take many forms—a bike ride, a fun side project, a bad action show (The Night Desk is so bad good!), an interesting problem at work… those can all be good ways to spend our life force! Being on the internet too long, on the other hand, is rarely that:

This is true at a macro level in our daily lives, but also when we zoom into how we spend our time at work. PMs in particular have this annoying habit where we tend to gravitate towards the wicked problems—a trait that makes us good at what we do, but can also be self-defeating because when we spend too much of our time depleting our life force, burnout eventually finds us.

So 2x2 matrix incoming! I think of the way we spend our life force as PMs on two dimensions: the difficulty of the task, and our likelihood of influencing the task’s success.

Some tasks fall in the easy bucket (relatively speaking—don’t @ me!). Think about things like customer interviews, collaborating with designers on a good user experience for a feature, or puttering around in JIRA making comments here and there. But then there are the difficult tasks—solving an organization’s quality problem, fixing development and deployment dependencies, understand team dynamics and creating a safe and open work environment where the whole team feels happy and fulfilled… you get the idea.

We are probably all familiar with that dimension. But the dimension we don’t always take into account is the probability that our work will actually influence the outcome of the task to ensure its success. Maybe the collaboration with the designer has a low probability of success because they report into a different org with different values. Maybe fixing development and deployment dependencies have a high probability of success because you have a really good relationship with engineering leadership and you all are highly motivated to solve the problem.

Which leads me to my main point. It’s in the combination of the ease/effort involved in a task, as well as our known sphere of influence, that we are able to make the best decisions about where to spend our life force. Let’s break out that long-promised matrix now, shall we?

You’ll have to excuse me, I’m not good at naming things. But let’s go through these.

Just don’t

Let’s get this one out of the way first. There are tasks that are easy, that we might be tempted to pick up—especially when we’re already tired and close to burnout—that simply don’t make sense because there really is no winning.

Maybe you are a JIRA wizard, and you think it would be an easy win to redo some of your workflows. But maybe the engineering team has no interest in changing any workflows and they see no benefit in learning a new system. They dig their heals in, and before you know it you’ve spent weeks on an “easy” task that only served to erode trust between you and the engineering team.

Just don’t.

Unnecessary hill-dying

This bucket is really interesting to me because I think a lot of ambitious, smart PMs gravitate towards problems like these. We want to go for the hardest, “wickedest” problems out there, and prove to ourselves and the world that we can solve them. This is such an admirable quality, but not a sustainable way to live your work-life.

Think of our example of solving an organization’s quality problem. This is likely a really hard problem that requires coordination and buy-in across multiple teams, with a lot of resistance and meetings and meetings about meetings and meetings to talk about how bad that one meeting went. With extensive effort and superhuman patience and collaboration skills you might get to a point in 9–12 months where the quality of the organization’s output has seen a marked improvement. At that point it will feel amazing and you’ll be proud—as you should be. But it might also kill your drive, enthusiasm, and ambition and turn you into a relentless cynic.

I think we should all attempt a task like this at least once in our careers. But it is no place to build a home.

Hero makers

Oh, we love these kinds of tasks too, don’t we. Really hard problems with enough social and organizational capital to make a real difference in a reasonable time frame? That’s PM catnip right there! This box is definitely a better use of life force than unnecessary hill-dying, but we have to limit ourselves here too. Because even though the payoff / enjoyment / fulfillment of this work can be huge, so can the cost. This is difficult work that can also become addictive, and if we don’t pace ourselves and limit the number of tasks we take on in this box, burnout will find us here. So choose these carefully, and try to shift more of your life force to…

Huge impact

As we progress in our careers some tasks that used to be difficult become second nature to us. What sometimes happens is that we forget that it wasn’t always easy, so we erroneously start to think that everyone on the team already knows what we know, and we start to undervalue our contributions / knowledge.

Take a moment to think if this is happening to you. Maybe you have gotten really good at JTBD interviews, or facilitating group FigJam sessions, or getting a team to define a customer problem / business outcome effectively, or… What are the things that you can do in your sleep, but only because you’ve spent so much time on those tasks that you have a level of familiarity that others on the team simply don’t have?

Those, my friend, are high impact tasks that take very little energy/life force, and often gives you energy because of how electrifying it can be to be really good at something. You should always be on the lookout for ways to apply those unique skills to problems/opportunities where it can be really impactful. Unfortunately we can’t spend 100% of our time on tasks like these—and frankly, we shouldn’t want that, because then we’ll stop growing. But the number should definitely be more than 0% and probably closer to 20% of our time.

---

The main point I want to make with this post is that as PMs we generally have a lot of autonomy over how we spend our time, and that can be a blessing and a curse. A blessing because we get to prioritize our impact. A curse because we too often spend our life force on tasks that drain us and lead us towards burnout.

So take a moment to breathe, and think about the amount of time you spend in each of the life force buckets I mentioned here—and where you might need to make changes to avoid the road to exhaustion and burnout. And please, come up with better names for the buckets than I did.

At Postmark we’ve long been fans of the “Entrepreneurial Operating System” (EOS) as presented in the book Traction: Get a Grip on Your Business by Gino Wickman. We also love the “W Framework” as outlined in the article The Secret to a Great Planning Process—Lessons from Airbnb and Eventbrite by Lenny Rachitsky and Nels Gilbreth. Both resources are excellent and highly recommended for the thesis and theory behind each of these frameworks.

In this post I’d like to describe how we combined these methods to set goals and run our business and product delivery process. I’ll start with a short summary of each method, and then go into specifics on how we used them together to ensure our teams are aligned on the same goals and have all the context they need to work autonomously on projects.

I promise I’m not here to start an argument about what is the best way to set goals. Instead, I hope this could be useful to folks who have tried a bunch of different frameworks—including OKRs—and found that nothing quite worked for them. Maybe this is a good alternative to try…

Goal-setting using EOS

We tried a several different goal-setting frameworks before landing on the Entrepreneurial Operating System (“EOS” from here on out). There’s no way to cover all it entails here, so please read the book, it’s very good. What I want to focus on specifically here is one of the primary outputs/artifacts of the system. EOS calls it the Vision/Traction Organizer (V/TO), but we adapted it into what we ended up calling the Vision and Focus Plan. This is sort of the equivalent of an OKR document, but we found the additional context extremely useful, especially when we layered W Planning (which I’ll talk about next) on top of it.

In its simplest form the document has two sections, one section for Vision, and one for Focus. The basic structure of the Vision section, using an example from our 2020 planning session for the Wildbit brand as a whole, is as follows:

Every year our leadership team got together for a few days to work on any edits we needed to make to the Vision section. Principles, Values, and Purpose should not change a lot. These are the long-term guiding principles for the company and though they should be revisited at least once a year, frequent changes would indicate that we don’t really know where we want to go with the business, so that should be a red flag.

The 10-year picture is a level down from the purpose—a way to look into the future of what the business would look like in reality if we achieved all our goals. The 3-year picture is way more concrete, and where we spend a good amount of time modeling and debating based on what we know about our business and the industry at large. These are the revenue goals that we want to achieve in the shorter term.

The Focus part of the document changes the most, and this part is the most directly comparable to OKRs. We generally made one of these for each product line (and sometimes even for individual teams). Here’s an abridged example from Postmark that we worked on during 2021 planning:

The sections can be summarized as follows:

• 1-year plan. Think of this as the “Objectives” in the OKR framework. In tandem with the Vision this is where we want to be at the end of the year from a business perspective.
• Quarterly plan. Similar to the 1-year plan, but a more immediate timeframe to reflect our planning cadence (this could also be 6 months, 6 weeks, whatever cadence you use for planning).
• Goals for the Year. This is similar to the “Key Results” part of OKRs. They are measurable metrics and indicators that will tell us whether or not we’re on track to meet our 1-year plan. It helps for this section to cover a longer time horizon so that you can prioritize projects and bets effectively, and avoid sudden changes in priorities (which are really disruptive to teams).
• Tasks for the Quarter. This is the nitty-gritty prioritization of problems we want to solve in a given planning timeframe to achieve our goals for the year. The visual planning and delivery/execution of these tasks happen in Productboard and JIRA, but this single view keeps us honest about what we’re working on. (See the next section for how we populate this column)
• Issues List. This is a core component of the EOS system, and is an ongoing list of concerns, things we’re worried about, obstacles or impediments that we have to address, etc.

An essential component of making this approach a success is that we review the Vision & Focus Plan every week in our leadership meetings. We review business metrics, we talk about our progress, where we might be off track, what needs to change, what issues we need to add, how we are doing in addressing the issues, etc. That way we have a weekly check-in where we can adjust our plans and solve problems together1.

One really important part that I skimmed over in this section is describing how things make it onto the “Tasks for the Quarter” list. That’s where W planning comes in…

Planning using the W Framework

As I mentioned earlier, the original article does an excellent job of explaining the W Framework, and it should definitely be on your reading list. But in the interest of time I wanted to provide a short summary of how it works here. The gist is that planning is most effective when it is a collaborative effort between Leadership (senior/executive leaders of a business unit) and Teams (people executing the actual work). This makes it a particularly appropriate framework for empowered and autonomous teams. The framework looks like this:

The four stages are described as follows in the article:

Context: Leadership shares a high-level strategy with Teams.

Plans: Teams respond with proposed plans.

Integration: Leadership integrates into a single plan, and shares with Teams.

Buy-in: Teams make final tweaks, confirm buy-in, and get rolling.

So when we go into our quarterly planning we use our Vision & Focus Plan along with W planning to come up with our tasks for the quarter.

Phase 1: Context

As a leadership team we review our annual and quarterly goals as laid out in the Vision & Focus Plan, and make sure we are still focused on the right things. We ensure that the entire team has the strategic context they need to successfully enter the planning phase.

Phase 2: Plans

Teams take the goals and strategic context, and create project plans as bets on how they would like to achieve those goals. Note that at this point the “Tasks for the Quarter” column in the Focus plan isn’t filled out yet—that comes from the teams based on how they believe we can achieve our stated goals. In the words of Father Cagan:

Instead of being given a roadmap of features, an empowered team is given a problem to solve and they get to figure out the best way to solve that problem.

We use our Project Plan template for this part, which you can see on Github. The plan does not have to have every detail figured out. We view it as “a road sign into the fog.” We make sure the direction and first few steps are known, then add and edit as the fog starts clearing down the road.

We then share the plan with everyone in the DACI section of the plan by posting a link in Basecamp and requesting feedback form the team. We discuss comments asynchronously in Google Docs, or synchronously on a Zoom call if a decision can’t be made quickly in the comments.

Phase 3: Integration

Once the team planning phase is done the leads team gets together again to discuss the plans, how it all fits together, and any trade-offs that need to be made. This is where we fill out the “Task for the Quarter” section and make sure we are not taking on too much work for the quarter.

Phase 4: Buy-in

As a team we then get together to finalize the project plans, discuss any final questions/feedback on our priorities, and move individual tasks to Basecamp/Asana (for non-dev projects) or the appropriate JIRA Epics (for dev projects).

Once we finish this process our teams are ready to execute on their projects with clarity on how each project aims to influence our goals. This includes essential engineering scaling and reliability work—for instance, if our goal is to significantly increase the number of messages sent, we’re going to have to make sure that the platform can scale with that!

---

So there you have it—a way to combine two different frameworks to create a seamless goal-setting and prioritization process for empowered teams. Admittedly, I left out quite a few details in this post—there are lots more to discuss in this process, such as how we track progress, how we adjust based on new information, how we aim for “healthy pressure” within teams using high-integrity commitments, and so much more. But I am hoping that this brief overview sparks some ideas for teams who might have been struggling to make other frameworks work in the context of their own teams and culture.

Like all things related to software, planning and goal-setting require discovery and experimentation to get right. Even this article should be viewed as a snapshot—capturing a moment in time that describes our planning process. But we are also still constantly evolving the process as we get feedback from our teams and learn what works and what doesn’t. So try this one out, and let me know how it goes if you do!

---

1. I plan to write more about the structure of our weekly meetings in a future post. ↩

I think about The Fog of War in the context of product management often. The term started as shorthand for an important concept during battle:

The fog of war is the uncertainty in situational awareness experienced by participants in military operations. The term seeks to capture the uncertainty regarding one’s own capability, adversary capability, and adversary intent during an engagement, operation, or campaign.

Of course, most of us of a certain age know this concept mainly from video games where it refers to enemy units, and often terrain, being hidden from the player until the area is explored. Here’s an example from Command & Conquer: Red Alert 2:

This concept—both in its military and gaming contexts—can be really helpful to guide our thinking about planning, prioritization, and execution. Let’s first look at the original meaning, and how the 3 uncertainties of the “fog of war” can effect our decision-making on planning and prioritization:

1. The uncertainty regarding one’s own capability. We are often worried that what we build might not be good enough to win over customers.
2. The uncertainty regarding adversary (competitor) capability. We are often worried that competitors might build something faster and better than we would (ChatGPT, anyone?) and that it will destroy us.
3. The uncertainty regarding adversary (competitor) intent during [a project]. We don’t know what our competitors are planning to build next.

These uncertainties can sometimes paralyze our decision-making—or worse, lead us down a path of making decisions based on our fear of the unknown. When we go into our planning cycles we have to make sure that we act only on what we know about our business and our users, and the information we have available to us. We cannot let the fog of war derail us to make prioritization decisions out of fear and uncertainty of what others might do.

That leads into what we can learn about execution from the gaming context of this concept. When I talk to our teams about project plans I often refer to our planning documents as “a road sign into the fog.” I encourage teams to make sure the direction and first few steps are known based on the information we have, and then to add and edit their plans as the fog starts to lift.

At Postmark we use a project plan template that you can view on Github here. I’ve written about this document a couple of times (see here and here), and the most important principle we live by is our commitment to these plans being “living documents”. We don’t fill out the whole thing up front (there’s too much fog out there!), we host it in Google Docs, and everyone on the team has full edit access. We truly work on it together—and as the fog lifts, we keep editing until we feel comfortable with the level of uncertainty that remains in the system.

The next time you enter a planning cycle I encourage you to think about the fog of war and how it might be influencing your decisions. When are you guided by uncertainty, despite all the things you do know about your business and customers? When are you trying to map out areas that no one has explored, and that you simply don’t have enough knowledge about yet? How can you focus just on “the next right thing” and trust that as you go, the fog of war will lift, and the road will become clear?

Mike Fisher argues that we should rebrand technical debt as “product debt”, and I think it’s a good argument! That said, I’d like to add some considerations to two of his points. First:

We usually think of refactoring as “cleaning up” code, where we change the code to be more easily understood, perform better (faster or more efficiently), or follow current conventions/standards. The goal of refactoring is to change the code without changing its functionality; it should continue to pass all unit and functional tests. 

I take a slightly different approach to refactoring, and how to prioritize the work. I believe it’s important for teams to have a stated and agreed-upon value of “leave the code better than I found it.” This means that refactoring shouldn’t be a separate activity, for its own sake, that needs to be scheduled. It should be a natural part of feature development.

If you’re creating a mechanism for add-ons on the product, spend a few extra days to refactor the billing code you’re already working on. If you are adding metrics to the dashboard in your UI, take the time needed to refactor the front-end code to make it more performant. Whatever code you’re touching while you’re working on a project, leave it better than you found it. It is way more efficient to extend a project by a week to refactor code you’re already working on than it is to create a separate project that needs to be planned, prioritized, and worked into the roadmap.

Second point:

So, how do we ensure we are paying down technical debt when there is so much pressure to ignore it until things really break? I think one part of the answer is to use a different term. Instead of tech debt, which implies it is the responsibility of the tech team, let’s call it product debt.

I think this is a good first step to getting more teams to care about technical debt—but it’s not enough. One of the issues with getting technical/product debt prioritized is that often “the business” doesn’t see the value in statements like “we’re going to clean up the code so that it doesn’t break a few months from now”. Instead, we need to frame the work in terms of the benefits to customers and/or the business.

For instance, we could make the case that refactoring this piece of code would significantly increase our deployment speed, which would mean faster time to market. Or we could argue that fixing our slow staging environments would result in happier, more productive engineering teams.

With technical debt—as with most things in software development—the thing you do is never the main thing. The main thing is what the thing you do enables. What value it brings to customers and the business. That’s the framing we need for working on technical debt.

There’s a sentiment I started to see in the agile development world that advocates for deleting old/stale items off a backlog completely. A good recent example is Jason Knight’s latest newsletter:

The backlog becomes a dumping ground for every single customer support query. Every account manager and every salesperson has something in there from conversations with customers and prospects. […]

It’s tempting to see “length of time in backlog” as some kind of vector for prioritisation, but it really isn’t. It’s quite the inverse, in fact. So let’s all try to get comfortable, embrace the idea of getting rid of old stuff in our backlogs, and give people a “no” rather than a “one day”.

I’m not trying to pick on Jason—his work is great and it’s another very good edition of his newsletter! I am just using it as an example that got me thinking about this a bit more deeply.

My take is that we should absolutely keep all customer feedback around in our backlogs, because that is continuous discovery data that would be a shame to lose. Instead, my proposal would be to normalize the backlog as a place to build organizational memory and a customer feedback knowledge base—not as a list of things that all have to get done.

Two tactics can help with this approach. First, a Now/Next/Later roadmap keeps the focus on the list of current priorities. The entire backlog doesn’t go into the “Later” column—only things that are currently prioritized to start within the next few months.

Second, have a standard process that the entire company (especially the customer success team) can use to collect user feedback and attach it to features. In our case that’s Productboard, and our success team can easily add and process customer feedback via a browser extension.

I guess our list of features in Productboard is technically our “backlog”, but it doesn’t cause us stress in terms of feeling like we need to work on everything that’s on there. However, as part of our planning cycle we can go through this list and figure out if anything is important enough to pull into the “Later” column of our roadmap. An added bonus: if/when we start to work on any of those features we have access to lots of customer data about each feature, and we can reach out to those customers to have more in-depth conversations with them about their needs.

So instead of deleting old issues off our backlogs, let’s rather remove the pressure and stigma around what backlogs are for (maybe we should rename it to “customer needs knowledge base”?). And then let’s use our actual roadmaps for the list of things we know we’re going to work on.