Menu

Posts tagged “prioritization”

3 product management links for January 30, 2023

I have a few product-related articles that I wanted to reflect on and write more about, but I just don’t think I’m going to get to it. They’re all really good though, so instead of just archiving those notes I wanted to share them so you can check it out.

1.

Here’s some solid advice from Jason Knight on what to do when your product is a mess and you have to fix all the things all at once:

In a situation like this, you’re going to have to get super-pragmatic. You’ve got lots of fires all burning at the same time and you need to put them out before you can start prioritising ‘properly’. Your goal is to get back on track as soon as possible, and you’re going to have to do a bit of shovelling to get there. Do what you need to get done.

And:

What we’re doing here is looking to put out the fires, and get a variety of initiatives to a base level of quality. You’re very unlikely to be able to make 15 things amazing all at once. Your goal here is to make all ships rise together. This means working with your stakeholders to understand what the minimum viable solution to these issues is, getting brutal with scope, and expending as little precious development time as possible.

2.

Andy Nortrup writes about what he learned about product management from Bonsai:

Similarly, with software products, patience is an important skill to make sure we don’t push the team faster than they can write good code, or make changes to the product faster than you can learn from users’ response to the changes. Patience can help us be less frantic and pay attention to the work in front of us in this season rather than the whole roadmap.

3.

Rich Mironov talks about the differences between products and features, and I especially appreciated this point about what users care about:

Customers don’t care about how hard we worked. Our product either does what the customer needs, or it doesn’t. And it should be priced based on customer value, not recovering our expenses. Users don’t care how much we spent, how big (or great) our team is, margin demands from Finance, remote versus on-site teams, development velocity, scrum vs. kanban vs. XP vs. lean.

Collaborative Product Strategy Development: A Case Study

When I arrived at Wildbit in 2016 as Postmark’s first product manager, my initial job was to work with the team to create a formal vision and strategy for the product. I wrote about that process in How we built a product vision and roadmap so I’m not going to spend much time on that.

The focus of this post is on how and why we redeveloped and implemented our Product Strategy after 6 years, and how we used it to create a prioritized product plan. I hope this will be helpful as a guide for teams who need to do similar work. Let’s start with a bit of background…

How it started

As a small team (<30 people) working on a bootstrapped, profitable product we were lucky that the Product Strategy we came up with for Postmark in 2016 remained remarkably consistent over the next 6 years. We made some tweaks along the way, mostly to the ideal customer journey, but the fact is that it worked, so we didn’t need to keep revisiting and pivoting over and over. That, however, changed in 2022 when Postmark was acquired by ActiveCampaign. The entire Postmark team moved over to ActiveCampaign and we are still working on the product together.

For the most part Postmark operates as its own business, but we also recognized an opportunity and responsibility to revisit and update our Product Strategy to align better with the broader ActiveCampaign vision and goals—and include plans for integrating the two products. We knew that in order to plan and deliver the right products and features to our customers, we needed an updated Product Strategy to guide us.

We are a team that loves to work collaboratively and get input from everyone, so we really wanted to create this strategy together. To do that, we broke the process up into 3 phases:

  • We started with some async work to clarify the framework and goals, and gather feedback from everyone about the changes we needed to make to our current strategy.
  • We had an in-person retreat coming up in September 2022, so we planned to discuss each element of our strategy together and come up with some rough concepts that we could refine afterwards.
  • Our leadership team then had the responsibility to solidify the strategy and share it back with the team and ActiveCampaign leadership for final feedback before we could call it “good for now.”

There was another part to this. We are big fans of “working in the open”, so we we felt that we had an opportunity not just to do this work as a Postmark team in isolation, but also to share our journey with anyone in the larger ActiveCampaign team who might be interested. So we created a space in Confluence where we documented our process as we went along.

I highly recommend this approach because it has the added benefit of building up “organizational memory.” If we were to come back a year from now and go “wait, why did we decide to do that?”, we will have a record not just of our decisions, but also the context and the journey that led to those decisions. This is often severely lacking in strategy work, and I believe it’s one of the main reasons why strategies seem to change so often in some organizations. If no one knows why a decision was made, the next person to come along can very easily change a strategy or a direction without having the necessary context about the work that has already been done. In short, learn to love documentation! But I digress. Let’s get back on track.

For this post, I cover each phase of our process separately:

  • Phase 1: Product Strategy purpose, framework, and async pre-work.
  • Phase 2: In-person collaborative Product Strategy work.
  • Phase 3: Refining and publishing the Product Strategy, next steps.

One more thing before we get going… I talk about “black hole words” in more detail below, but there is one term we had to define right upfront. Since the “Product” in Product Strategy can mean so many different things to people, we wanted to be clear on the definition right from the start. Postmark is heavily focused on product-led growth, so we clarified in our documentation that when we use the term “Product Strategy” we don’t mean only design and product experience. We mean everything that goes along with that as well: product marketing, growth marketing, sales, customer success, scaling and reliability… the whole deal.

And with that… let’s start by talking about the Product Strategy framework we chose to use, and how we collaborated asynchronously to lay a solid foundation for our in-person retreat work.

Product Strategy purpose, framework, and async pre-work

I am pretty familiar with the landscape of Product Strategy frameworks, but in preparation for our work I decided to do another deep dive into all the writing that’s out there. It is… well, a lot. Everyone approaches strategy so differently—and besides, you can’t just blindly adopt a model or framework for a team. Every team’s principles, values, and work styles are different, so whatever we used, I knew it had to fit us. I also wanted to make sure the team had at least 2 weeks to get involved in our asynchronous work, and with our September retreat fast approaching I started to get increasingly nervous.

Things finally started to come together when I decided to combine a couple of concepts into a way that made sense both for the Postmark team in isolation, as well as our work within the larger context of ActiveCampaign. The framework I proposed to the team is a combination of an adaptation of Reforge’s Product Strategy Stack, and Melissa Perri’s Product Strategy Canvas.

Here’s how I presented the framework to the team (it helps to know that ActiveCampaign’s primary brand color is blue, and Postmark’s is yellow):

Postmark Product Strategy Framework

I like the basics of the Reforge model because of how well it ties both the “blue boxes” and the “yellow boxes” together:

Each layer of the stack builds on the previous layer. Put another way, each layer is a prerequisite for the successive layer. We cannot have a company strategy without knowing our company’s mission. We cannot have product goals without knowing our product strategy. Given this relationship between the layers, Product Strategy serves a critical role—it is the connective tissue between the objectives of the company and the product delivery work of the product team.

For us this means that ActiveCampaign leadership is responsible for defining the blue boxes (which they did!), and our team is responsible for coming up with the yellow boxes. This gives us clear areas of responsibility as well as a tight connection to the goals of the larger organization.

The biggest change I made to the model was to replace the Reforge layer of Product Roadmap (“The sequence of features that implement the product strategy”) with Product Plan (“Prioritized set of problems/opportunities that implement the product strategy”). This is important because I believe this framework is too high-level for feature details and sequencing. This is especially relevant since we follow the Now/Next/Later format for roadmapping, and I was worried about the unrealistic expectations that might come with a “sequence of features”.

This framework also gave us a structured process for our work. We focused our async and in-person work on the components of the Product Strategy, and we would use our regular planning cycle (a post for another time!) to create the Product Plan.

In terms of the actual elements of the strategy, I proposed an adaptation and expansion of Melissa’s Canvas:

Product Strategy statement

I really liked where this was headed. We had a clear path towards an updated strategy. We had a few weeks to work asynchronously on documenting the current (read pre-acquisition) state of Postmark as it related to each of those Product Strategy components. We would then use our in-person retreat time to articulate the following for each of the components of the Product Strategy:

  • Where we are today (this was the async pre-work)
  • What our ideal future state should be
  • What we need to do first to get to our ideal future state
  • Our hopes and fears about the future state

We created a Google Doc where we broke out those questions for each component of the strategy, and we asked the team to start filling out what they believed our current state was.

But before we could do that there was one more thing. I mentioned “black hole words” in Part 1, but we realized that each of the components of the Product Strategy will probably be interpreted very differently by each person on the team. So our Head of Marketing and I worked together to add a glossary at the top of the Google Doc with some definitions of the most important concepts that kept coming up in our discussions. We also asked the team for feedback on those definitions, and adapted quite a few based on the input we received. Here’s where we ended up:

  • Product Strategy. How we intend to meet our business goals through product-led growth, as driven by software, marketing, and customer success.
  • Go to Market (GTM) Strategy. How we identify the right problems Postmark is solving, who we’re solving for (ICP), how we position Postmark to the ICP, our key messages, and the channels we’ll use to generate awareness and encourage product adoption.
  • Our purpose. The reason we exist as a Postmark team.
  • Problem we’re Solving. The specific issue we are solving for the market.
  • Target Audience. The narrowest relevant set of users for our product.
  • Value Proposition. The specific benefits or value we provide to our audience to solve their problem.
  • Strategic Differentiation. The unique attributes Postmark have that make it more compelling than the leading alternatives.
  • Growth Strategy. The set of practices, rituals, and processes that we use to understand our audience that ultimately results in sustainable, repeatable growth for Postmark.
  • Monetization + Segmentation Strategy. Our business model, how we identify sub-groups in our audience and align to their needs, and how we build our product to drive growth and revenue.
  • Channel Strategy. The tactics we employ to reach our audience, and how we build our product to support acquisition from those sources.

And with that, we got going! The team all started adding details to the Google Doc, asked questions, debated where we really stood on each of the components, and so much more. By the time we got to the retreat we felt ready to make good use of our in-person sessions. So let’s talk about how we ran those sessions, how it went, what we learned, and what outcomes we achieved.

In-person collaborative Product Strategy work

First, I should say that being together as a team for the first time in three years was fantastic, and definitely my highlight of 2022. At Wildbit we had annual retreats, but for ✌️reasons✌️ we obviously couldn’t get together for the past 3 years. The in-person time was universally wonderful and I am confident it will sustain another year of remote work.

But let’s get back to the strategy work. The way we structured our sessions was not necessarily conventional. I don’t know if it was the best way to do it, but we made a few intentional decisions about the structure that felt important.

First, we had the discussions together with all ~30 team members. We didn’t do the usual workshop thing where you break up into smaller groups and then report back to the larger group. This was a deliberate decision because we really wanted this to be a full team effort. It likely meant that fewer people spoke up, but it also meant everyone had all the context of our discussions at all times. I loved it. A comment from someone in customer success could spark a marketing idea from someone in engineering that got everyone excited… and that felt magical.

So, we all took live notes in a Google Doc while using the structured outline to guide our discussion. It was a little chaos at times, but the good kind of chaos. The kind of chaos that gets people excited about the product and our customers. I won’t be able to share too much of what the document ended up looking like, but here’s an excerpt from one section:

Our Purpose

We could’ve done this in many different ways. We could’ve used sticky notes and affinity diagramming. We could’ve done small group work with readouts from each team. We could’ve tried to make the conversations more structured. But in the end I really like where this ended up. It was kind of exhausting (especially for the facilitators), but the energy of having everyone together in one room dreaming about the future of the product just felt so good.

Which leads me to the “what didn’t go so well” bit… We just didn’t have enough time! We mostly got to a good place with our ideal future state for each component, but we didn’t quite get to the “hopes and fears about the future state” question. I wish we had more time to discuss that because I think we would’ve gotten some really good insights out of that reflective question. That said, I believe that the outcomes we did achieve—and the way we got there—outweighed the potential drawbacks.

So what did we come out of the retreat with? We had a vision statement we all believed in. We had a long Google Doc with the raw notes from our sessions. We had enough discussion to have a common understanding of and agreement on some of the strategy components that we weren’t so sure about when we entered the sessions—such as how to think about an expansion in our target market due to the acquisition. In short, our Product Strategy was starting to come together nicely as we began to flesh out the different sections:

Product Strategy

We also had a clear understanding of the next steps: the leads team would consolidate the document into a first draft of a coherent strategy that we can share with the team for another round of async feedback before we finalize.

Refining and publishing our Product Strategy

We came out of our retreat with a messy but comprehensive Google Doc with our raw discussion notes about each component of the Product Strategy. Our next step was to refine it, finalize it, share it, and then most importantly, use it (why is it that so many Product Strategies sit on a shelf and never get referenced?).

Once we got back from retreat, our Head of Marketing and I started collaborating on a first, cleaned-up draft of the Product Strategy (consider this a tip: product strategy isn’t just “product”, it’s everything around the product as well—that’s why we collaborated). We took each of the strategy components that we defined earlier, and consolidated our notes into a draft that we could share with the team:

Strategy doc

After sharing this we asked the team (as well as our leaders) for a final round of feedback: What works, what doesn’t, what’s missing, what’s confusing? Even though I can’t share the details of it all, you can see that there were lots of questions and comments (the yellow highlights), which helped us clarify some of the final details.

We were ready to go! No strategy is every “done”, but we felt we were at a point where we accomplished our goals for this work. We had a strategy that:

  • Reflected our new reality and goals as part of the larger ActiveCampaign organization.
  • Gave the organization and our team the strategic context we needed to move into more detailed product planning in a cohesive way.

So we published the strategy internally and shared it around. And that’s the end of it and we lived happily every after, right? Well, no, of course not. A strategy is only as good as the extent to which it influences practical, day-to-day planning and delivery. So even though we felt good (and to a big extent, relieved to be aligned on a bunch of stuff we needed to figure out), the next step was to turn the strategy into an actual plan.

We’ve been using W Planning as a team for a long time as a way to enable our empowered teams to plan collaboratively:

W Planning

I plan to write about our approach to W Planning in more detail in the future. For now, that article is an excellent reference. Since it’s a cycle we are all familiar with, and that we know works well, we used that framework for adjusting our product plans based on the new/adapted Product Strategy as well.

Phase 1: Context

The leads team got together to work on the business goals that align with the Product Strategy. We then shared this strategic context with the entire team so that everyone would be on the same page.

Phase 2: Plans

Teams took those goals and strategic context, and got together separately (product, engineering, marketing, customer success) to discuss the biggest opportunities they see for meeting those goals.

Phase 3: Integration

The leads team got together again to discuss the opportunities that the teams came up with, how it all fits together, and any trade-offs that needed to be made.

Phase 4: Buy-in

We then went back to the teams with a proposal for our main focus areas for the year. This was a particularly fun meeting because we discussed our Now/Next/Later roadmap together, dragged things around, and got alignment on the most important opportunities we wanted to address next. (We use Productboard for our planning and roadmapping—I’ve written about our usage of Productboard before but a lot has changed since then so this should probably also be a topic for an upcoming post.)

Now Next Later

After this the teams started working on their project plans (I wrote about the project plan template we use here). And just like that, we were off to the races with detailed planning and delivery on customer and business value.

How it’s ending

The thing I liked most about this process is the reason for the title I chose for this post: Collaborative Product Strategy. This wasn’t a situation where our leaders sat in a room and came up with stuff. Via each team member we stayed close to our customers and our business throughout the process. And we didn’t do this because it feels better (although it does!). We believe that we get better outcomes when decisions are made by the people who are closest to the data (i.e. customer needs, industry knowledge, etc.). That means that if a Product Strategy is not set in a way that ensures you have all the relevant data, it is more likely to fail. So I guess if I have any advice about Product Strategy, it would come down to this: don’t do it alone.

There’s probably a lot more to say, but I’m going to end it here. I really hope this has been helpful. I’d also love to know what questions/feedback you may have on this process! Please let me know via Linkedin, or on Mastodon.

How to manage work that is always “in progress”

I enjoyed this post by Yuhki Yamashita (CPO at Figma) about how design is always “Work in Progress,” and how to deal with that:

Our work never feels done because it isn’t. Our collaborators jump in and out of files, leaving feedback and iterating on designs while we’re creating them. Many of us can ship whenever, so it’s hard to know when new designs are actually ready. It’s the chaotic reality of modern product design and development.

He gives some really good recommendations for how to work in this type of world where nothing is ever quite “done”. The post also introduced me to the concept of flashtags, which I quite like. It comes from Hubspot (See FlashTags: A Simple Hack For Conveying Context Without Confusion), and it’s a way for leaders to indicate how strongly they feel about the feedback they’re giving:

  • #fyi means there’s no hill to die on.
  • #suggestion means they’ve seen the hill but don’t feel strongly enough to commit the energy to climb it. Take it or leave it.
  • #recommendation means the hill was climbed. They thought about dying on it, but walked back down.
  • And finally, #plea means that they do, in fact, want to die on the hill. So if you see this flashtag, you better make sure it’s prioritized!

And finally, speaking of Yuhki… I am not really a podcast person, but I really enjoyed his recent interview on Lenny’s Podcast: An inside look at how Figma builds product.

Slack vs. Microsoft Teams, and the forces at work when choosing a product

John Gruber has some strong B2B product management analysis in Was Salesforce’s Acquisition of Slack a Bust?

I think Slack is to Teams today where Mac OS was to Windows in the mid-1990s: better designed, for sure, but not in a way that makes a difference to the corporate IT decision makers who are making the call on which platform to use.

The key is not merely to be better, on some vectors. The key is to be better on the vectors that people with purchasing power care about. Missing this has been the death knell for many good products.

To use Jobs-to-be-Done language, there are strong forces at work when choosing a product. If the progress-making forces (“Slack is better designed!”) are not stronger than the progress-hindering forces (“Well we already use Microsoft, so we might as well stick with Teams”), people/companies simply won’t switch.

How to make the move away from “feature factory” successful

Itamar Gilad recently published a good post on Feature Factories vs. Value Generators. It starts off with some basic definitions that should be familiar to most readers, but the second half expands on the responsibilities product orgs have to ensure a successful transition away from feature factories. We can’t just sit back and hope the rest of the organization goes along—there’s a very important organizational change element here:

The product org needs to stop viewing itself as a production unit (you’d be surprised how many do). Our job is no longer just to work heads-down developing features per a spec. The product org needs to produce traction towards the goals, and this traction needs to be communicated clearly to the rest of the company (which helps in creating trust). Testing and evidence play a major role.

This bit about what to measure also stood out to me:

I see a lot of OKRs about boosting efficiency and improving productivity. Many CTOs see having developers work at 100% capacity as the prime goal and push their teams to deliver more story points per sprint. While there’s nothing wrong with any of these per se, they are at best second-order optimizations, and at worst major waste generators. The better optimization is pursuing a higher ratio of positive-value launches. If you embrace this goal, a lot of things that you do today will no longer make sense. It’s a long journey, but with persistence and hard work you’ll be able to put the antiquated feature factory model to rest.

The goal for product teams is not “stop being a feature factory,” it’s “provide more value to customers and the business.” Moving away from “the build trap” is just one of many tactics for making that goal a reality.

Use “survival metrics” to determine the right project status

I like Adam Thomas’s idea of identifying “survival metrics” at the start of a project. It’s a way to help teams stay grounded throughout the project and ask themselves whether they should stop the project, pivot in a different direction, or continue to invest in completing the project. From What Are Survival Metrics & How Do They Work?:

Survival metrics help a product team determine if an initiative is worth investing in more, pivoting or stopping completely. They are a forcing function to prevent product teams from suffering due to the sunk cost fallacy. Survival metrics put resource allocation and company incentives, both implied (think politics) and direct (think data), in front of the team before a project begins and again at regular intervals, giving permission to act quickly.

Adam goes on to discuss three questions that help teams identify those survival metrics.

A framework to identify issues to unblock growth

Here’s a good analogy from Josephine Conneely to help figure out why growth might be stalling:

Imagine each of the 3 criteria pillars, Product, GTM and Org, as legs of a stool. Ideally each leg is of even height. This allows it to sturdily hold whatever is needed (in this case it’s increasing user volumes). Each leg can continue to grow (perhaps this is some sort of stool tree), and as long as the legs grow in tandem the success metrics of choice are safe. However, there may at times be an imbalance. Imagine an organisation with a great sales and marketing team who have created such demand that the product is struggling with performance issues as it scales to meet increased usage volumes. This leads to a lopsided stool, which while functioning, is not operating in manner which enables the org to capitalise on growth potential. If the product issues are not rectified, this could result in churn, reputational damage and a negative growth trajectory. Imbalance leads to lost opportunities.

Read the whole article for an illustration of the concept, and also how to use the framework in practice.

Create awareness of reality through bottom-up strategy

Tim Casasola’s post Create awareness of reality through bottom-up strategy points to an issue that we often see in teams—the work that they are doing is disconnected from the company’s core strategy:

There is often a difference between what an organization says its strategy is and what customer/project teams do on a day-to-day. When this dissonance is present, customer/project teams share with the org that their reality isn’t aligned with the organization’s vision. “It’s great that we want to pursue this new customer segment, but most of our engineers are focused on improving the experience of our current customer segment… and we’re far from where we want to be there.”

And yet, the org still says they have a “strategy.” The org turns a blind eye when customer/project teams describe their reality and relies on its existing narrative when feeling challenged.

The organization needs to be aware of when this dissonance takes place. So that they can learn from it, and come up with an actionable strategy.

Tim points to John Cutler’s “Bet Up” activity as a useful exercise to make this disconnect clear:

This seems like a really useful exercise for teams to undertake. It might also be really interesting to ask the executive team to fill out row 4 of the above, and see how their answers differ from what the teams come up with. Exposing a big strategy mismatch in such a clear way could be a really powerful tool to move the organization in a direction where a team’s day-to-day work is reflected in the overall product strategy.

Measure product teams by value created, not number of features launched

In his post Why Feature FOMO Stalls Product Innovation Brian Crofts discusses the many reasons why product teams tend to add a slew unnecessary features to a product. This issue hit close to home:

Pendo’s recent State of Product Leadership survey found that 77% of product teams are evaluated based on the number of features they ship. This gives product teams an implied incentive to add more, regardless of whether those features are being used and adopted.

I can only trust that this has changed by now, but when I worked at eBay product managers were measured by how many PRDs they wrote. The things didn’t even have to ship. The measure was literally “How many Word templates did you fill out this quarter?”

Instead, Brian proposes a better way:

Technology brands should hold their product teams accountable for metrics that have the greatest impact on success. Instead of the raw number of features shipped or revenue driven, metrics such as feature adoption, customer happiness, and customer engagement are critical. These measures point to which features are working now and help form longer-term rollout strategy.

How to deal with uncertainty in product development: discovery and assumption mapping

Philipp Krehl has a very thorough, practical article up on Mind the Product called Product Discovery or Product Delivery: How do you Decide? His main thesis is that figuring out when it’s safe to move to the build/delivery phase of a project is all about your level of certainty about the problem you’re solving. He proposes a simple rubric to calculate your comfort level with different product risks:

If you and your team have marked every answer a 3 or below, it confirms that you have a high degree of certainty about your path, and you can start building. You will probably still discover new information but you can just adapt to it — this is why we work with Agile methodologies like scrum or Kanban.

Answers marked with 4 or above indicate areas where you should invest and do product discovery to reduce your uncertainty. At this stage, it’s better to figure out the right thing to do rather than commit to an outcome.

Once you have identified areas which require more understanding you can use an effective technique called Assumption Mapping.

He also provides a good overview of the value and practical aspects of Assumption Mapping, a method I am keen to try out.