Collaborative Product Strategy Development: A Case Study

In 2022, our eight-person product team at Resilinc hit a pivotal moment. I had just been promoted into the team from Customer Success. My "unfair advantage" wasn't traditional product training—it was the fact that I knew every single edge case of the product and had built deep trust with customers who knew I fought for their development needs.

At the same time, the market shifted. A major competitor had just released their own Business Continuity product, and we needed to respond fast. I was assigned to lead the BCP (Business Continuity Planning) product promotion, which included four assessment variations and a dedicated analytics dashboard.

We realized that to beat the competition and scale effectively, we couldn't just build features in a vacuum. We needed a strategy that aligned our deep customer knowledge with Resilinc's broader goals of accountability and pace. We needed to bridge the gap between what I knew customers loved and what the platform needed to become to win the market.

To do that, we broke our process into three distinct phases:

• Phase 1: Async Alignment. We started with asynchronous work to clarify our framework and gather feedback from the field—specifically leveraging my CS background to identify the friction points in the existing BCP flow.

• Phase 2: Collaborative Refinement. We held intensive sessions to map out how the "Free Assessment" model would feed into the "Paid Management" service, ensuring the Product Strategy supported the business's revenue goals.

• Phase 3: Solidifying and Socializing. Our leadership team finalized the strategy, ensuring it was "good for now" so we could begin the rapid execution of the BCP analytics dashboard.

  
  

At my company, we value accountability and delivering at pace, so we practiced “working in the open.” We documented every decision in a centralized space. I’m a huge believer in this because it builds “organizational memory.” When we delivered 22 features in that first year, no one had to ask why we prioritized the dashboard over other requests—the context and the journey were already there. If you don't document the "why," the strategy can be changed by anyone who lacks the context of the work already done. Learn to love documentation!

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

• Phase 1: Product Strategy purpose, framework, and async pre-work.

• Phase 2: Collaborative Product Strategy work (The BCP Pivot).

• Phase 3: Refining and publishing the strategy to drive the 37% usage surge.

One more thing: we had to define what "Product" meant for this BCP project. To us, Product Strategy wasn't just UI/UX. It meant the whole deal: the integration of REST APIs, the Dataflow logic, and how Customer Success would sell the extra management services.

Let’s look at the framework that allowed us to keep everyone aligned while we outpaced the competition.

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 the companies 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 state 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 SharePoint locations 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 Product and I worked together to add a glossary at the top of the Doc in SharePoint 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 our company is solving, who we’re solving for (ICP), how we position our company 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 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 we 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 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 my company 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 years 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 ~8 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 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:

Refining and publishing our Product Strategy

We came out of our retreat with a messy but comprehensive 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 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:

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.

Summary: How we turned a competitive threat into a 37% usage surge

The transition from Customer Success to Product Management isn't just about changing titles; it’s about translating deep customer empathy into a structured, scalable strategy. By applying this framework to the BCP project, we moved from "guessing" what features to build to "knowing" how to win the market.

The Winning Formula:

• Empathy as an Asset: I used my knowledge of customer "edge cases" to identify that the cost of initial assessments was the primary barrier to entry.

• Strategic Pivot: We shifted the Company Product Strategy to make BCP assessments free, which removed friction and drove a 37% increase in usage almost immediately.

• Value-Driven Monetization: By delivering 22 high-impact features on the BCP analytics dashboard within the first year, we gave customers a reason to stay. This led to 60% of customers purchasing extra management services.

• Radical Alignment: Despite the pressure of a competitor’s new launch, the framework kept our 8-man team perfectly aligned. This transparency allowed us to renew 23 out of 39 customers well ahead of schedule.

The Bottom Line

Execution is easy; alignment is hard. By "working in the open" and mapping every feature back to a Company Objective, we didn't just survive a competitor's launch—we outpaced them. The BCP project proved that when you lead with accountability and deliver at pace, you don't just build a product; you build a resilient business.