Menu
Search

Posts tagged “product strategy”

9 April 2023

4 effective product team structures

Ravi Mehta’s 4 Effective Product Team Structures is a helpful framework for leaders to figure out how to organize product teams:

Because of the nature of product work, there are two vectors that product teams need to be organized around: area of focus and level of accountability.

  1. For area of focus, product teams can align their work with either business outcomes or feature development.
  2. When considering the level of accountability part of the structure, product managers either act as fully responsible owners of the work or as facilitators of the work, where they share metrics responsibilities with cross-functional partners.

In the article he goes through the pros and cons of each of the 4 structures.

8 April 2023

12 metrics to track for B2B SaaS companies

Elena Verna has a great summary of leading metrics for B2B SaaS companies, including some really useful benchmarks. Also a good reminder that revenue is a lagging metric:

Many leaders obsess over revenue. And rightfully so, because revenue is the outcome of any business. But revenue is a lousy metric to goal the team against because it assesses past performance instead of predicting the future.

If you want to dig a little deeper on the best metrics to choose for SaaS companies, here are a few more resources:

29 March 2023

There’s more to life than OKRs: using EOS and W Planning for effective goal-setting in empowered teams

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. ↩
22 March 2023

Product Management and The Fog of War

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?

20 March 2023

How your product is discovered and adopted is part of the product

Shift left on go-to-market to build better products is a great post by Frank Tisellano on why product managers have to consider Go to Market efforts while they are still deep in the understanding/planning phase of a project:

Great PMs recognize that building a good product is table stakes and that the way to truly differentiate themselves is by taking a strategic approach to how customers or users find and adopt their products.

In other words, great PMs shift left on go to market, considering and developing their distribution strategy while they’re still prioritizing problems to solve, long before a PRD is written, let alone a line of code.

He goes on to give some practical tips—and examples—on how to make GTM a bigger part of the PM process.

20 March 2023

Hyper-growth, and the power of doing more with less

David Poblador writes about The Pitfalls of Hyper-Growth: How Companies Can Do More with Less. Startups tend to operate more with a scarcity mindset at the onset, but as they grow…

As businesses grow, they often rely on flawed indicators of success that do not necessarily correlate with sustainability. One of the most common measures of success is headcount growth. Unfortunately, hiring lots of new employees can create inefficiencies, harm company culture, and reduce productivity. When hiring becomes the only tool to get the job done, it can detract from the most important things, like focusing on priorities and managing the company’s lifecycle.

David’s post led me to a fascinating interview with Jesper Kouthoofd, who is the founder of music-tech company Teenage Engineering. In the interview he talks about why they specifically avoid running after hyper-growth:

We only want to make great products and when you don’t focus only on making money and have reached a certain level, everything becomes about quality. Right now, there is a certain cultural fascination with fast growth, IPOs and so on, but I want to go slow, really slow and think long-term. It takes time to do good things. You see, this cultural phenomenon of speed and growth at all costs is displayed in every startup, they all look the same, it’s like fast food: it looks good, its taste is consistent but then you feel horrible afterwards.

This is obviously not desirable or true for all companies, but it’s worth noticing that there is more than one way to run a business.

19 March 2023

Taylor Swift, Fender Guitars, and Product Management walk into a bar

I recently came across two articles that combine the topics of music and product management. That is basically catnip for me, so I have to share.

First, I know “What X Can Teach Us About Y” articles have become a bit of a trope, but trust me on this one. What Taylor Swift Can Teach Us About Business by Rex Woodbury is an excellent case study on what good product management is all about. I’ve always been impressed by Taylor’s business strategy, and this is the first article I’ve seen that really digs into it. On Taylor’s decision not to sign with RCA because they wanted to pigeonhole her into being a country singer:

The key insight here is that RCA underestimated the market. Yes, country listenership was declining among young people. But great products revitalize stale markets and ultimately expand their markets. Swift did both, first proving that there was an opportunity in country music, and later growing beyond country to become a bona fide pop star. Swift’s story reminds me of a fatal error in startups: underestimating market size.

There’s too much goodness to quote here, so just read it.

The second one is an older piece that I found via Jeff Gothelf’s blog. It’s an interview with Fender CEO Andy Mooney on the company’s mission, and once again it showcases some excellent product management principles. In the example below, Andy talks about the creation of the Fender Play app. I am breaking the quote up with some of my notes, since it encapsulates the process so well:

The marketing is tied around creating the emotional connection, being ‘why should I do this?’.

Note the focus on Jobs to be Done. Their research showed that people pick up the guitar mostly because they want to play and sing along to their favorite songs—not because they want to be rock stars. That’s the emotional connection they are going after.

Again, with Play, we felt that it was a milestone to get people to commit if they were able to master their first song. So we teach the skills that you need in Play around doing exactly that. You come into the product, you declare your genre and that gives you a potential setlist.

Note here how they identified their activation metric / a-ha moment and built the product around getting users to that moment as quickly as possible.

Then you get taught the skills to master those songs rather than the other way round. I taught when I was very much younger. You know, are you going to teach somebody to play major minor scales or are you going to teach them how to play House Of The Rising Sun? My approach—which I’m glad was all intuitive back then—was a song-based approach because you were teaching them how to play the chords within the context of the song.

Again, note how they focus on the how music makes you feel, not on the theory behind it. We are all used to this kind of marketing now but it’s worth remembering that until the iPhone came along, phone marketing was all focused on storage space and RAM, not on here’s what you can do with it.

There’s much more in the article about the extensive customer research that Fender did, and how they used those insights to create Fender Play.

7 March 2023

Using “steel threads” to reduce product delivery risk

Jade Rubick resurrects an old engineering concept (and dead Wikipedia page!) in Steel threads are a technique that will make you a better engineer:

A steel thread is a very thin slice of functionality that threads through a software system. They are called a “thread” because they weave through the various parts of the software system and implement an important use case. They are called “steel” because the thread becomes a solid foundation for later improvements.

With a Steel Thread approach, you build the thinnest possible version that crosses the boundaries of the system and covers an important use case.

He explains this in detail in the full post, with lots of helpful examples.

6 March 2023

Product team principles for focusing on short-term growth

We’re shipping rafts this year, not boats is a sobering read from Nate Jones that covers 8 principles for product teams who had to make a shift to short-term growth projects in 2023. An example:

It’s long-term if it’s short-term. That’s two principles for the price of one. First, realize that building to keep the business going today is long-term. That can help product teams recognize they have a long-term role to play. Second, any product plays with long-term payoff have to also include short-term revenue potential. You need both-and this year to innovate.

You might not agree with everything he says in this post, but at the very least it will get you thinking about your own team’s principles and priorities as we continue to navigate this… “complicated” year.

6 March 2023

The 4-subfunctions of growth marketing, and a good Figma example

In How to organize your B2B growth marketing team Emily Kramer explains growth marketing in a way that I think I finally understand:

To support full-funnel marketing, multiple GTM motions, and all of the data and tools available, 4 sub-functions of growth-marketing are needed: Demand Gen, Inbound & Web, Lifecycle Marketing, and Ops & Analytics.

Emily also touches on the many ways that this team ideally works with Product and Engineering. It’s a highly recommended overview of this critical function in an organization.

And speaking of growth marketing… In Figma and product-led sales Jesus Requena, former head of growth marketing at Figma, shares some really interesting details on how Figma’s Growth team works with their Sales team:

We wanted to take this to the next level and learn what exact product behavior correlated with an upgrade. We partnered with our data product team, sales ops and sales leaders and created a model that surfaced around 10 data points. When two or more of these were triggered, there was a high likelihood for the account to upgrade. We showed sales and sales leaders the data and got their interest, then we tested it in a small group. Endgame, the product-led sales software, helped us display the data at account level and user-within-account level.