How the SPACER framework can align PMs & PMMs on the value of a feature
A detailed guide to how Product Managers & Marketers can develop shared understanding of an upcoming feature release and prevent rework later on.
“No, the feature doesn’t do that.”
That’s what my engineering manager said about a feature we were rolling out for our recruitment SaaS platform (called Talentera).
In my mind, the feature was going to enable recruiters to send customized offer letters to candidates AND capture acceptances through a button.
In reality, the feature would only allow them to send an email based on a pre-defined template with a few pre-populated placeholders.
But there were no plans to add a call-to-action button to allow candidates to accept the offer.
I was confused by this approach. The candidate receiving the offer letter would not have any next natural step, and we wouldn’t be able to report on acceptance rates.
But alas, the feature was scoped that way. Strangely enough, clients who initially requested it were content with that.
As a result, I had to change my sales decks and address some marketing debt. The narrative had to be pulled back as my messaging was a “stretch”.
Something had to change to prevent these misunderstandings.
If you’ve been following my recent editions, you’d know that I feel the PM and PMM relationship is broken.
Among the myriad of issues they face during collaboration, misalignment on the value proposition of feature takes the cake.
The resulting issues are apparent. Due to misalignment, Product Marketing might:
Oversell or undersell a feature.
Promote a capability that doesn’t exist.
Target the wrong end user or persona.
Fail to highlight the differentiating aspect in messaging.
Create ambiguity on which tier of users have access to the feature.
Thus, there’s a need for a mechanism to get PMs and PMMs on the same page.
The first thing we need to figure out is “what” should they align on.
This is where the SPACER framework comes in handy.
Overview of SPACER
Let me be clear: I’m not a fan of frameworks.
I have an acute disdain for short acronyms and often find frameworks flawed due to their subjectivity. Moreover, PMs and PMMs tend to become chained to them, and adherence to the “process” starts to overtake the greater good.
Therefore, I’d preface the idea with a disclaimer that one shouldn’t see this as something set in stone. Absorb and customize this model to your unique situation.
Alright, enough throat-clearing.
The SPACER framework
When planning the go-to-market plan for a key feature, PMs and PMMs need to sync up early on on six dimensions.
These are:
S = Story
There are two parts to this:
(a) Backstory: the context behind this feature's inspiration. This pertains to the insights and sequence of events that led to conceiving it, e.g., a customer pain point or anecdote.
(b) User story: this is a short description of the feature told from the perspective of the target user, showcasing the capability, the problem it’ll solve, and the outcome/benefit it will unlock.
When discussing the “story” aspect, PMs and PMMs should try to answer:
What customer feedback or data inspired this feature?
What specific problem does this feature solve for users?
How does this feature align with our product vision?
Can you provide a typical use case scenario?
What key benefits will users experience?
P = Pricing and Packaging
My Slack channels are inundated with pings from sales reps: “Are we charging for feature X? Is it an add-on?”
Pricing is often an afterthought. This confusion can deter sales reps from pitching new enhancements.
Therefore, the PM and PMM must discuss the feature's packaging and pricing.
Bear in mind - in many organizations, pricing decisions are led by another leader (e.g., the CEO, VP of Sales, CPO, etc.); thus, they need to be pitched proposals or looped into the discussion to get some direction.
Packaging it one way or another can also necessitate work items for engineering (e.g., feature-gating or email upgrade workflows), so it must be sorted out early.
Some questions to explore:
Which pricing tier will include this feature?
Is this a premium feature or included in the base package?
How does this feature impact our overall pricing strategy?
Will there be any introductory or promotional pricing?
How does this pricing compare to similar features in the market?
A = Abilities and Constraints
Next up is the “how” behind the feature.
When a SPACER discussion occurs, the PM should ideally have a mature PRD or wireframes explaining the user's step-by-step flow. The exact capabilities of the feature must be agreed on.
(It’s perfectly ok if the scope changes over time - the idea is to remain aligned on those iterative updates)
Moreover, constraints and limitations should also be explicitly discussed. I’ve been personally burned by assumptions about gray areas of a feature’s capability set.
If the feature can’t perform something that sounds obvious (or what competitive products offer), it needs to be called out.
The PM and PMM should, thus, explore answering:
What are the core functionalities of this feature?
Are there any technical limitations we should be aware of?
How does this feature integrate with our existing product?
What potential use cases might be outside its capabilities?
How scalable is this feature for future enhancements?
C = Competitive Differentiator
There are different classifications of features, and each can affect the choices one makes at the time of a product launch:
For example, if you’re building an ability to schedule an email campaign for a later date, that would be a fairly basic feature for an email marketing tool.
However, if you’re building an AI-powered module for hyper-personalizing every email dispatch based on the recipient’s preferences, that would be more of a new invention to attract new customers.
Regarding features that are not “table stakes”, it’s essential to agree on how the product fares better than the competition. Even though the feature parity might even out, the execution and design details might be vastly different and should be highlighted. Sometimes, a slightly additional attention to detail can make all the difference.
Thus, a PM and PMM should explore answering the following:
Which competitors offer similar features?
What unique aspects set our feature apart?
How does our implementation compare in terms of user experience?
Are there any areas where competitors outperform us?
How quickly can we expect competitors to replicate this feature?
E = End User
This part is easy to understand. Every feature has a primary user and use case. PMs and PMMs should be clear on who it’s meant for and to whom the messaging should be directed.
Of course, there can be multiple personas involved in each feature.
For example, Slack recently launched “lists” that help individual contributors project the status of their tasks and assist managers in gaining visibility on the status of key initiatives.
Therefore, a PM and PMM should discuss the following questions here:
Who is the primary target user for this feature?
What user segments will benefit most from this feature?
How does this feature address specific user pain points?
In what contexts or situations will users typically engage with this feature?
Are there any secondary user groups we should consider?
R = Roadmap
Finally, we come to the most volatile parameter: timelines.
This aspect covers the expected date the feature will hit production and what’s in store for the future (along with timeframes).
The feature's trajectory also needs to be aligned so that PMMs can plan their messaging accordingly to set the right expectations.
Moreover, the appetite for “pivoting” or enhancing the feature based on feedback must also be addressed early on.
Since timelines are part of this discussion, I’ve also found it helpful to unpack risks that could affect those release dates.
Thus, the PM and PMM should address these questions:
When is the feature due for release?
What enhancements are planned for the next 6-12 months?
How does this feature fit into our long-term product strategy?
What risks could change these timelines?
Are there any dependencies on other features or updates?
What potential expansions or iterations are being considered?
How flexible is the roadmap to accommodate user feedback post-launch?
Hang on. Isn’t all of this already in the PRD?
Yes, the functional aspects of a feature are usually captured well in the PRD.
However, the purpose of this sync is for a PMM to verbalize a preliminary value proposition for the feature that the PM can validate. Instead of being literal about the feature, the SPACER framework gives both parties a common vocabulary to articulate why the feature exists.
Let’s say the product is a CRM.
The PRD may describe the ability to manage users and their access as “role-based access control.” This is an apt descriptor for the engineering team as it’s a common construct in SaaS products.
However, the PMM may feel that’s too technical of a term for audiences and may re-label it to “User Permission Management”. When PMs and PMMs discuss the feature, they use this framing to make it more relatable in marketing collateral moving forward.
Moreover, aspects like pricing, the competitive edge, the back story, limitations, packaging, and feature evolution aren’t always explicitly mentioned in a PRD. Thus, it’s important for PMs and PMMs to hash these out.
The consequences of misalignment
I want to highlight what happens when alignment on these aspects is overlooked.
The points below will help explain why it’s critical to be thorough about these dimensions.
Without aligning on a clear STORY (S),
The lack of context behind the feature will hinder understanding.
Marketing messages may fail to resonate with the target audience.
The feature's purpose and value proposition could be misunderstood internally and externally.
Without aligning on PRICING (P),
The feature might be undervalued or overpriced, affecting adoption rates.
Sales and customer success remain confused about who to pitch the feature to.
The rollout strategy may be incomplete as certain user tiers may not be eligible.
Without aligning on ABILITY (A),
Overpromising and under-delivering on capabilities could disappoint users.
Marketing might misrepresent the feature's functionality.
Messaging may unintentionally showcase use cases where the feature fails.
Without aligning on COMPETITIVE edge (C),
Unique selling points might be overlooked in marketing and sales efforts.
PMMs won’t be able to educate sales to handle competitor-based objections.
Opportunities to outperform competitors may be missed.
Without aligning on END USER (E),
Marketing efforts will target the wrong audience.
Messaging could talk about imaginary use cases that don’t even apply.
Without aligning on ROADMAP (R),
Release timelines will be unclear, making it harder to plan launches.
Customer expectations for future enhancements might be mismanaged.
Example
How about we get our hands dirty with a concrete example?
Let’s assume the product = Descript (the audio and video editing tool)
The feature in question is "Remove repeated takes with AI" feature:
S = Story (hypothetical)
Backstory: Descript's product team observed content creators spending hours manually cutting out retakes from their recordings. This tedious process was a significant pain point, often cited in user feedback. The team realized that AI could automate this task, aligning with their vision of simplifying video editing.
User Story: As creators record their videos, they don’t have to stop if they stumble. They continue on recording till they have completed the intendend script. When they put the source in the Descript editor, they will have a 1-click action to automatically remove retakes from the video recordings to save time. With this feature, they can focus on crafting more content rather than spending hours on manual edits.
P = Pricing and Packaging
The feature will be included in Descript's Pro plan, which is priced at $30 per user per month. This adds value to the existing plan without requiring a separate subscription.
A = Abilities and Constraints
Here’s how the feature will work:
User uploads video to Descript
User clicks on the "Remove retakes" feature
AI analyzes the video for potential retakes
AI automatically cuts out identified retakes
User reviews the edited video
User can make manual adjustments if needed
Limitations: The feature may struggle with complex scenes or when retake markers are unclear. It works best with standard recording setups and may require user refinement for optimal results in challenging scenarios.
C = Competitive Differentiator
While some competitors offer audio editing tools, Descript's AI-powered retake removal is unique in its simplicity and efficiency. It sets Descript apart as a leader in AI-assisted audio editing.
E = End User
The feature is perfect for content creators, podcasters, and marketers who frequently record scripted audio and want to save time in the editing process.
R = Roadmap (hypothetical)
The "Remove repeated takes with AI" feature is launching in Q1 2024 as part of a larger AI-powered editing suite. Future iterations may include support for more complex audio scenarios and integration with video editing tools.
How would you operationalize this framework?
First, the PMM must be engaged far earlier in the product development cycle.
The PM and PMM need to establish a weekly sync. This specific alignment is best done when the next sprint is being finalized.
Does every work item in the sprint need this treatment? No. For example, bug fixes and minor enhancements don’t need extensive discussion. PMs and PMMs would focus more on innovations being positioned to fuel acquisition or significant feature updates that warrant customer and prospect attention.
Both parties need to reserve time to discuss the different aspects of SPACER and document them on a sheet.
Of course, this can also be input into Confluence, Asana, or any other task management tool of choice.
What happens after SPACER?
Alignment is a means to an end.
As a result of this conversation, PMMs become empowered to craft better go-to-market plans and feature messaging.
The document (especially the story aspect) allows PMs to validate PMMs' understanding of their feature and enables them to course-correct where needed.
Moreover, as PMs and PMMs sync every week, any changes to priorities, feature scope, or pricing decisions can be updated on the same sheet, creating a single source of truth.
SPACER is only a baseline
Depending on your product’s unique situation, there can be other aspects that PMs and PMMs must align on. You can adapt the model accordingly.
For example, when I worked on Talentera, we also considered the “strategic benefits” of features that were more inward-facing for the company.
One instance was when we offered a “Quick Apply” feature that captured applications with a few applicant details and filled the rest through smart integrations. The strategic benefit for us was that it would bump up our resume capture counts, giving us more data to power our industry benchmarking module.
Your company may have other aspects they’d like to optimize for. So, don’t get caught in protecting the acronym.
Key takeaways from today’s post:
There’s a dire need for PMs and PMMs to be on the same page about a feature.
There needs to be a shared understanding beyond the functional aspects.
This includes alignment on price, persona, competitive edge, and future roadmap.
The SPACER formula is a baseline model that’s supposed to be customized.
That’s all for today, folks. I hope you found today’s edition helpful.
Till next time,
Aatir
Thank you Aatir for sharing your in depth insights. I’m a novice Project Manager for tech projects (from a non tech background) and your content helps me understand the processes and principles of the industry.