Maybe 10 years ago I would’ve gotten upset about an article like Spencer Fry’s No PM, no problem: how we ship great products fast, in which he explains why they don’t have product managers at Podia and how great that is. Luckily I’m now too old to stay up late just because I think someone’s wrong on the internet. Instead, I approach articles like these—ones I viscerally disagree with right off the bat—with a bit more curiosity. What is the source of the author’s assumptions? What is the data that led them to this particular set of conclusions? What is the problem they’re trying to solve, and what led them to this viewpoint as the solution?

As it turns out, we get the answers to those questions pretty early on in Fry’s post:

Why shouldn’t the developers—or designers—be tasked to work through the problems, instead of being handed a set of solutions?

Every single project, a developer is assigned what we call a Champion role and it’s that person’s responsibility to act as the PM in addition to their work as an individual contributor. This approach, as opposed to handing off a spec to stitch together with code, makes for much more engaged developers who feel more ownership of the work.

Ah, see, this makes sense! I can see why Fry concluded that PMs are unnecessary if his experience is that they (1) “hand off a spec to stitch together with code”, and (2) don’t give developers ownership over their work. The problem is likely that he has never worked with a PM that understands their role and does it well, so of course the data would lead to the conclusion “no PM, no problem”.

So let’s talk about those two assumptions for a minute.

Handing off specs to developers

This is just 100% not what PMs should do. If designers, developers, QA, marketing, and customer success are not part of the planning and design process of a feature, it’s just bad practice. There should never be a handoff in software development, only collaboration. A developer should know exactly what they’re doing once they start coding because they have been intimately involved in the design decisions and trade-offs that go into a project right from the start.

The role of the PM during this phase is to bring all the right customer and business data to the table to help the team through their decision-making. It is rare for them to say “this is the decision,” but in some cases where teams can’t come to an agreement it’s also their responsibility to make that call, explain it well—and be accountable if it ends up being the wrong decision.

Ownership of work

Engaged team members (not just developers) who feel ownership over their work is an essential element of an empowered team. If the teams don’t have that and the PM “calls the shots” then that is, again, bad product management.

At Postmark we have a similar role to the Champion role Fry uses at Podia. We call it the Driver (part of the DACI model). The PM is sometimes the Driver on a project, but not always. In every case where it makes more sense (such as a deeply technical back-end improvement, or a pure front-end redesign) a developer or designer or marketer is the Driver. We define the role as follows:

The Driver is the project leader. This is the one person who will be driving the team through decisions. They’ll be responsible for making sure all stakeholders are aware of what’s happening, gathering information, getting questions answered, and action items completed. A Driver, for example, will schedule and run project meetings, gather and distribute ideas, coordinate tasks, and track the team’s progress.

Drivers ensure a decision is made but don’t necessarily make the decision.

The team has autonomy and ownership to drive the project and make decisions as they see fit. Each project has an Approver assigned, usually someone on the leadership team, but they are there to support, answer questions, provide context, and in rare occasions, help make a decision if the team is at an impasse. PMs shouldn’t “own” projects. Teams should own projects.

So what do PMs do, then?

Fry’s post does allude to an age-old question, though: Why do you need separate PMs? Why can’t someone on the implementation team just do it? The short answer is that what goes into good product development and successful features is so much broader than just the code being written and shipped. And if we require designers or developers to be responsible for all of it, they would simply never ship anything.

So what value should PMs bring to the team, whether or not they are the Driver/Champion on a project? In addition to input on design/scoping decisions they should be responsible for all the things that are not directly related to building the feature at hand, but essential for its success. Some possible examples:

• Customer input on what their needs are to help with the design and scoping of the feature.
• Revenue modeling to figure out pricing and packaging.
• ToS updates due to legal implications no one else thought of.
• Working with the marketing team to figure out the best positioning and launch activities based on what value customers can expect.
• Connecting the dots between this project and that failed one from 3 years ago as well as that thing the Lead Architect said in a meeting last month to ensure we don’t forget about an essential library dependency so that we actually build something that’s scalable and reusable in the future.

You get the picture.

There is enormous power in someone being around for the team as the person who’s got this so that they can focus on their work and relax in the knowledge that nothing will fall through the cracks. More than any other role in the organization, it is good product management that enables teams to work in a calm, empowered environment that produces consistently great software.

I have no doubt that Podia ships great products fast. They clearly have a culture of trust and empowerment, which is great. I do wonder how adding a good PM to the mix would enable them to go to even greater heights.

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.

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):

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:

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:

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:

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:

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:

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.)

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.