Many years ago, I chose to pursue a career in tech rather than in the theater world. I am happy with this decision, and I love what I do, but I miss acting more and more recently. 

And so, I decided to bring it back into my life and joined a professional theater workshop.

In this workshop, unlike in previous groups that I attended, each participant creates their own show based on their own life story. I’m not sure I fully understood what it meant when I joined, but I felt I had enough substance to work with.

So, how do you create a show based on your life story?

My hunch was to write the story and then work on presenting it.

But the director I work with thought otherwise.

I showed him what I had, and he was intrigued. His feedback was that he was curious to see where I would take it and what it would look like eventually.

I wasn’t sure what he meant. For me, this was it. I wrote the story already, and now it’s a matter of bringing it to life on stage. 

But he insisted that I keep exploring. He said he was sure that by doing so, the story would get additional angles and be more complete.

And he was right. I was surprised to see how many additional layers had revealed themselves as I kept working. The story wasn’t done when I finished writing. It was the work beyond the words that created it to be what it is.

Of course, it also changed the words that were initially written.

When I think about it, though, it shouldn’t have surprised me that much since I use the same technique for product strategy and roadmap. I keep telling my clients and academy participants that they need to be willing to ponder, live with unclarity for a while, and keep exploring until everything falls into place. 

I have seen it happening time and again in my professional world and have now witnessed it firsthand in a completely different domain.

But it’s not always that easy to stay in these “higher spheres” and leave things undetermined. 

When it comes to roadmap building, I often hear from product leaders what they have decided to do. That’s always the default – to bring it down to earth and talk about the bottom line.

However, a roadmap that is built this way is missing a critical aspect: the connection to strategy and how it would help us meet our goals. 

At this point, when I insist that they explain the reasoning behind their choices, the story often changes significantly, and so do the specific decisions that were already made.

So, instead of building it once and changing it later when you need to start sharing it with others, I created a simplified framework that would help you build the story right from the get-go.

It includes five parts: Goals, Original plan and assumptions, Status, Position, and Action plan. You can call it GOSPA for short. 

Here is what each part means and how they all connect to create the roadmap you want.

How to Use the Framework

A roadmap is not a list of features—it’s a story about how your product will help the company achieve its goals. The GOSPA framework helps you build that story systematically. But like any good story, it isn’t written in one sitting.

There are two ways to apply this framework:

1. Hierarchically – Start with a high-level version for the entire roadmap, then apply it again for each strategic pillar.
2. Goal-Driven – Break down your roadmap by goals or focus areas and use the framework directly on each one.

The implementation has slight differences depending on whether you are embarking on a new goal or continuing where you left off previously. I’ll address these where relevant.

Regardless of your approach, the key is iteration. A roadmap isn’t a one-way path from decision to execution. You’ll need to move back and forth between the different parts of the framework, refining your story until everything aligns. Often, as you clarify one part, you’ll realize another needs adjustment.

And finally, once you have a complete version, take a step back and read it as a narrative. Does it hold together? Do the goals make sense? Is the likely outcome what you actually want? If not, keep iterating until the story is as strong as the strategy behind it.

Now, let’s dive into the first part: Goals.

Goals

We start with the goals since that determines your roadmap’s overall direction.

Many roadmaps simply list a collection of initiatives rather than a coherent story about where the product is headed, why, and how it will help the company and its customers.

And that’s exactly why your goals should not be product-oriented. If you want to drive business outcomes, your goals need to express that. 

For example, instead of setting goals like “develop new AI-powered analytics,” ask yourself why it is important and set the goal accordingly. It could be to maintain a leadership position in a certain market, increase POC conversion rates, address a new persona, and so on.

If you are working on a new area, set the goals from scratch. If you are working on an area that was previously defined and pursued, state the goal that you originally had. 

For completeness, it’s worth including goals that were previously defined, even if they were fully met already. It will give you the foundation on which the new goals will be built.

Since your previous roadmap might not have followed this framework, the goals weren’t necessarily well defined. You might need to uncover the original goal behind the features listed or rephrase the goal to the one the company had in mind but didn’t tell anyone at the time. Feel free to dig in and refine whatever needs refinement until you feel that it describes what you had in mind when you started. If it needs to change, we will do so later.

Original Plan and Assumptions

Before we make any decisions and future plans, we need to understand our starting point. Since most roadmaps aren’t entirely new (because most products aren’t), at least some of your goals are ones you have attempted before.

To tell a complete story, share how you planned to reach each goal and what the reasoning behind the original plan was. 

For example, if your goal was to establish leadership in a new market, your plan might have been to give minimal value but broadly to gain market share and awareness and upsell from there. The same goal could have had an opposite plan that would make sense, too: deliver a lot of value for a small number of customers and expand to additional segments once the first one is established. It’s all about the reasoning behind choosing one plan or another.

If you are working on a new goal, we want to use this part to define the playing field for this new goal or area. List the assumptions that we can rely on as we embark on this effort. Focus on defining boundaries first – where you choose to play and what can be left aside. Discussing these will often uncover additional assumptions that are often worth listing.

Status

Now that we’ve defined the goal and the thinking behind it, it’s time to assess the current state.

If you’re working toward an existing goal, don’t just check whether you delivered what was planned. Ask if you actually met the goal or how much progress was made outcome-wise. Did your effort do the work? Has the problem been solved, or the opportunity realized? How far along are you if not? It’s easy to mistake execution for progress, but a roadmap is about impact, not just delivery.

If this is a new goal, there’s still a status to capture. What’s been done so far that relates to this goal? Have you already taken steps—intentionally or not—that impact it? Have you tested any ideas, gathered insights, or explored potential solutions?

This part lays the groundwork for the next one, which is where decisions begin to be made.

Position

So far, we have discussed what we know, but how does this help us in the future?

Before making any decisions, you first need to reflect on what the status reveals. What do you think about the situation? Was the original plan sound? Did unexpected challenges emerge? Are there signals that suggest a shift in approach is needed?

Remember that you have the freedom to decide (or suggest if the decision is not entirely yours) on the direction and how you go about reaching the goals, not just about how you will bring the direction to life.

For example, you might recommend to:

• Stay the course – If things are progressing well, continue as planned.
• Double down – If the goal is more important than expected or needs more investment, commit additional resources.
• Adjust the approach – If the goal is still relevant but the current path isn’t working, try a different angle.
• Change the goal – If the insights suggest a different opportunity or need, redefine your focus.
• Abandon the goal – If it no longer makes sense, stop pursuing it and shift priorities.

This part is called position because it requires you to say what you think about everything listed so far and how you suggest moving on. This might be tricky because of the complexity of options and unknowns – remember that it’s part of the deal, and don’t let it paralyze you.

Action Plan

With a clear position, the next step is to define what we’re actually going to do. What initiatives will we invest in to move forward? Which ones will we abandon or avoid?

This, again, goes beyond product features and into the all-around actions needed to achieve the goal, whether in product development, marketing, sales, customer success, or operations.

The action plan should logically follow from the position. If you decide to stay the course, what are the next concrete steps? If you’re shifting strategy, what specific changes are required? If you’re doubling down, where will additional resources go, and where do they come from?

For example, if your position is to pivot retention efforts, the action plan could involve:

• Prioritizing proactive customer success initiatives.
• Improving reporting and insights for better in-app engagement.
• Offering strategic consulting to high-risk customers rather than just onboarding support.
• Solving major product-related pain points that prevent customers from getting ongoing value

Note that each of these could lead to a whole new GOSPA analysis focusing solely on it. That’s the nature of this framework – you do it once for the bigger picture and can then apply it one level down at a time.If we add the Level Down to the framework, it will now become GOSPAL instead of GOSPA. What do you think? Will it catch?