This is Part 2 in a 4-part series. Please read Part 1 before continuing:

• Part 1: Background and overall process

• Part 2 (this post): Product Strategy purpose, framework, and async pre-work

• Part 3: In-person collaborative Product Strategy work

• Part 4: Refining and publishing the Product Strategy, next steps

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.

And that’s where we’ll pick up Part 3 of the series next week. I’ll talk about how we ran those sessions, how it went, what we learned, and what outcomes we achieved. That will lead into Part 4, which will be all about how we refined and eventually published and communicated the updated strategy. See you then!

What I’m reading

Via Chris Coyier I found this great post by Karl Sutt on How to communicate effectively as a developer. His example of “low-resolution” vs. “high-resolution” writing is a useful reminder for all of us:

In both cases, the example on the left is what I call “low-resolution writing”. There is very little context, too much reliance on pronouns and unclear references. The writing is not emphatic —the reader has to spend extra energy to work out what is being said. The examples on the right, on the other hand, try to make the reader do less work, even though it is more effort for the writer. The writer clearly has thought about how the message will be read.

This idea is similar to what Erin Meyer refers to as “high-context” vs. “low-context” communication in her (excellent) book The Culture Map: Breaking Through the Invisible Boundaries of Global Business. She explains in this HBR article:

I compare cultures along the Communicating scale by measuring the degree to which they are high- or low-context, a metric developed by the American anthropologist Edward Hall. In low-context cultures, good communication is precise, simple, explicit, and clear. Messages are understood at face value. Repetition is appreciated for purposes of clarification, as is putting messages in writing. In high-context cultures, communication is sophisticated, nuanced, and layered. Messages are often implied but not plainly stated. Less is put in writing, more is left open to interpretation, and understanding may depend on reading between the lines.

Choosing the right communication style for the right context is an important skill for everyone, but especially product (and other) leaders. If we assume too much context is known, people will misinterpret what we mean with our words.

Ted Gioia has an interesting post about the Barnes & Noble comeback, in which he makes this important observation:

If you want to sell music, you must love those songs. If you want to succeed in journalism, you must love those newspapers. If you want to succeed in movies, you must love the cinema.

May I also add, for no particular reason at all: If you want to sell social media, you must love people and community.

I think I am really late on discovering Donella Meadows‘s writing on systems thinking, but now that I’ve read Dancing With Systems I’m going to seek out every word she ever wrote, starting with Thinking in Systems. I think I need a minute for this essay to sink in, and I’ll probably reflect on it more soon. For now, here are 8 quotes from Dancing With Systems that stood out to me.

Some stray links

• 🎺 This New York Times story about Rudy Van Gelder’s famous jazz recording studio (NYT 🎁 link) is just wonderful. Come for the story, stay for the photos. I wrote a couple more thoughts on the piece here.

• 🎵 Here are 3 albums that will, for me, forever be inextricably linked to the pandemic.

• 📚 I love this reminder tucked away towards the end of Austin Kleon's annual post about the books he read this year: “I hope you read widely and adventurously, but more importantly, I hope you read what you want to read! Life is short and time is precious, and any book that doesn’t have you turning the pages is not the book for you right now.”

• 📱This week’s useful app → Not technically an app, but close enough! “Lux Lavalier is a wearable 40mm battery powered pendant necklace with 64 LEDs surface mounted in a Fibonacci distribution and a Pixelblaze V3 Pico controller built in.”

• 🤨 This week’s WTF link → Kohler’s Numi 2.0 Smart Toilet Comes With A Built-In Alexa.

• 👴 This week’s Gen X link → Check out this incredible rotary keyboard.

• 📈 Last week’s most clicked link → How we built a product vision and roadmap at Wildbit.