A framework and method for developing a Product Strategy collaboratively (Part 4)

Also everything you didn’t know about The Shining

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

• Part 1: Background and overall process

• Part 2: Product Strategy purpose, framework, and async pre-work

• Part 3: In-person collaborative Product Strategy work

• Part 4 (this post): Refining and publishing our Product Strategy, next steps

---

Refining and publishing our Product Strategy

During the course of this series we talked about why our team needed to update our Product Strategy, the framework we settled on, and how we approached the async and in-person work to make it a truly collaborative process. For this concluding part I will focus on how it ended. How we refined the strategy, published it internally, and used it to guide our 2023 planning process.

As I mentioned in Part 3, 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 (see Part 2 for details on the framework). 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 (see Part 2), 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.

The thing I liked most about this process is the reason for the title I chose for the series: developing a Product Strategy collaboratively. 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 the series here. I really hope this has been helpful. I’d also love to know what questions/feedback you may have on this process—and if there’s anything you’d like me to write about next. Please let me know in the comments!

---

What I’m reading

Last weekend I finished the book Build: An Unorthodox Guide to Making Things Worth Making by Tony Fedell and the ending legit made me tear up:

In the end, there are two things that matter: products and people. What you build and who you build it with. The things you make—the ideas you chase and the ideas that chase you—will ultimately define your career. And the people you chase them with may define your life.

I got a little uncomfortable with some of the “hustle culture” bits in the book. But taken as a whole, this is wonderful read about having a meaningful career and life. Highly recommended.

→ (Also see my summary of Tony Fadell on the role, responsibilities, and importance of product management)

---

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.

---

I agree with Bruce Daisley in The Death of Hybrid Work Is Greatly Exaggerated:

The focus for organisations in 2023 shouldn’t be on mandating a return to the office, but on working out how to build strong cultures in a new, sustainable way. Some of that is about optimising the time that teams spend together, curating rather leaving it to chance. If we’re to get the best out of work culture then we all need to accept that this is the moment to reinvent the construction of it.

---

Some stray links

• 🎥 Everything you didn’t know about The Shining. “Kubrick had to change the original room number to Room 237 for a good reason.”

• 🎵 Amoeba Music asks, ‘What’s in your bag?’ and no algorithm can compete. This is such a great idea and I can’t believe it’s been going since 2008 and I’ve never heard of it. “Touring musicians drop by one of the store's three cavernous locations, prowl the labyrinthine sales floor, grab up records by the armful for an hour or so, then blab about their purchases on camera.”

• ✍️ This is a wonderful interview with James Patterson about creativity and ambition and I really think everyone should read it. “If you can write beginnings and ends, you can make a nice living as a writer. If you write middles, you win Pulitzers and Nobel Prizes and stuff. But with beginnings and ends, you’re going to do okay.”

• 📱This week’s useful app → Nova. How did I miss that Panic made a code editor after they sunsetted Coda?

• 🤨 This week’s WTF link → ‘Office Space’ Inspired Engineer’s Theft Scheme, Police Say.

• 👴 This week’s Gen X link → Remember the game Flight Control? “Flight Control arrived a mere eight months after the App Store itself debuted. Like the best early titles, it understood that the iPhone was unlike other hardware on which you could play games.”

• 📈 Last week’s most clicked link → How to Read More Books in 2023.