Product marketing and sales enablement teams play a crucial role in the success of a product or service. They are responsible for creating, communicating and delivering the value proposition of a product to target audiences, as well as equipping sales teams with the information and resources they need to effectively sell it.

However, many product marketing and sales enablement teams lack the structure and definition to get stuff done. Key symptoms:

• “Whiplash” of working on something one day, and getting pulled in another direction the next
• Getting ‘urgent’ inbound requests that need to immediately be responded to… multiple times a week
• Working really hard all the time, but feeling like you aren’t getting enough done

While the problems are many, oftentimes the simple (but powerful) solution is to adopt an Agile approach to PMM / SE. And while there are many Agile frameworks to choose from, In this article I’ll break down the keys to implementing an agile methodology using the scrum framework. This includes:

• The Agile Methodology, and Using Scrum for Product Marketing and Sales Enablement
• How to run product marketing and sales enablement teams in an agile fashion in the “scrum” framework
• The benefits of applying an agile methodology to product marketing and sales enablement
• Frequently Asked questions about scrum and agile for revenue teams

Table of Contents

What’s Agile For Product Marketing And Sales Enablement?

First things first - what’s Agile?

Although it is a high-level methodology, Agile actually has a very well defined history and definition. In lieu of rewriting what’s already out there, I’ll take it from some experts themselves:

Three box definition like we did for sales enablement from these three places:

Atlassian:

Agile is an iterative approach to project management and software development that helps teams deliver value to their customers faster and with fewer headaches. Instead of betting everything on a "big bang" launch, an agile team delivers work in small, but consumable, increments.

Agile Alliance:

Agile is the ability to create and respond to change. It is a way of dealing with, and ultimately succeeding in, an uncertain and turbulent environment.

Wrike:

The Agile methodology is a way to manage a project by breaking it up into several phases. It involves constant collaboration with stakeholders and continuous improvement at every stage.

Put simply, Agile is a methodology that guides how your team solves problems. The approach is characterized by its focus on delivering value quickly and adapting to change, making it well-suited for fast-paced and rapidly evolving industries such as technology and software development.

While it’s been popular in software development for some time, teams are beginning to realize its potential for guiding teams on the revenue side, which leads to interesting opportunities and challenges when applying agile to product marketing and sales enablement.

But what about Scrum? Again - going to rely on the experts here;

Scrum Alliance:

Scrum is "a lightweight framework that helps people, teams and organizations generate value through adaptive solutions for complex problems" Scrum is the most widely used and popular agile framework. The term agile describes a specific set of foundational principles and values for organizing and managing complex work.

Scrum.org:

Scrum is an empirical process, where decisions are based on observation, experience and experimentation. Scrum has three pillars: transparency, inspection and adaptation. This supports the concept of working iteratively.

Scrum is a framework involving specific processes and meetings that allows your team to be more agile. Again, having been used in software for years, there are a ton of benefits to applying scrum to sales enablement and product marketing.

Ok, so we know what Agile and Scrum are - but how do they apply in a PMM or SE context?

How To Run Product Marketing And Sales Enablement Teams In An Agile Fashion In The Scrum Framework​

As you might guess, there are different ways to approach changing how your team operates. That being said, let’s go through a high-level 5-step approach, when to move from step-to-step, and how to measure progress along the way.

Step 1: Get Everything on Paper

One of the main tenets of an Agile methodology is that the team has a clear understanding of everything that needs to be done - but in the spirit of crawling before we walk, step 1 is to record all of the items that the team is currently working on.

You need a solid understanding of where your team currently is and where your efforts are going. An easy way to start is to sign up for a free trial of a task management tool like trello or asana and begin to create tasks for everything that your team dedicates work to get done. No matter how trivial it seems - if something is taking longer than 15 minutes, create a task and get everything recorded in one spot.

It may feel silly - but the analogy I like to use here is that it’s like trying to lose weight or get into shape. It’s really hard to know what your expectations should be if you don’t know where you currently are. In the same way that you might log your meals in a calorie counter or meal tracker, it’s important to get an objective and measured sense of what your team is working on before you try to be more ‘agile’.

Part of getting visibility into the team’s work is to ensure that you’re taking proper inventory of outside requests. If you haven’t already, direct any inbound requests from other teams (sales, marketing, CS) into a single place. This could be a dedicated slack or Teams channel like #pmm-requests or #se-requests, or even giving access to your task management tool to the larger team. Putting all inbound requests into one place is going to make it much easier to see what requests are coming in and give additional visibility to other teams to see what’s on your plate.

Finally, when creating tasks to be done, try to note the things you are working on that were planned in advance (GTM collateral, sales training, webinars), and which ones came up last minute or were urgent requests from other teams. Could any of these requests have been put off? Could you have seen them coming?

With everything down on paper, we’re ready to begin putting a little bit of process together.

Step 2: The Stand-Up

You’re likely already having some sort of regular check in with your team - whether over zoom, in person, or over text - but with everyone able to clearly see the tasks they are working on, it’s time to start taking an agile approach to team meetings and introducing an Agile daily standup.

As Atlassian explains really well, an Agile standup is less about planning and more about understanding everyone’s expectations for what is going to get done today. It may seem small, but beginning to think less in big-project terms and more in achievable little bits is an important mental hurdle to overcome as a team. Not only that, but with all of the tasks in a single place, it can give focus to what the team is accomplishing and get everyone on the same page as far as what the team will be able to achieve.

And this shouldn’t take a lot of time! If you feel like your team is already in too many meetings, use a digital tool like mycheckins to automate the process and have it done through instant messaging. During this step you are getting more visibility into the current workflows, and starting to introduce the processes that will help you track progress. This is also a great time to double check that any task currently being worked on is in the task management system to make sure everything is there.

Now that you’re having daily repeatable check-ins and have all of your tasks in front of you, you can begin Agile Planning.

Step 3: Plan for the future

The next step is to review the data you have and get a sense for what your team can get done during a specific amount of time, and try to plan for specifically what your team will accomplish in that time.

Whether you’ve been at it for 2 weeks or 2 months, take a look at the historic task data you’ve amassed and use it to ‘predict’ what your team is going to do over a predictable upcoming time frame - I like to start with two weeks. This is known as a ‘sprint’ and will be the way that you plan for tasks and measure success over time. Don’t worry about getting it perfect the first time, but try to create the next two weeks of tasks and assign them to team members. Talk about it with your team, see if everyone can agree on what can be done and stick to that list.

It’s likely during this sprint that new requests will come in from the sales team, or important tasks will come up during this time - that’s ok! If things pop up, make note of them and ensure the team is working towards the most important task at any given time.

Now, at the end of your two-week sprint, review. As a team, ask yourselves:

• How much of what you planned to get done got done?
• How much of what you got done was planned?
• Could you have anticipated outside requests coming in? Could you have said ‘no’?
• Do you feel like you achieved more by being agile?

Continue to rinse and repeat until you feel comfortable planning and creating any two week sprint. At this point, you’re pretty Agile, but if you’d like to be more official and have a better forecast for how your team will perform, follow Step 4 to begin the scrum processes.

Step 4: Fold in process

For larger organizations or PMM/SE teams that want to more formally showcase their value to the organization, folding in additional process can go a long way to demonstrating ROI and getting even more work done. The following is a high-level list of steps to consider when adoption the scrum framework - but keep in mind there are many agile frameworks to choose from! Don’t feel boxed in by one - adopt the one that makes most sense for your team.

Keys to implementing the Scrum framework:

Identify the scrum master and product owner.

In scrum, the product owner is the person that decides what gets done, and the scrum master helps the team determine how much gets done. It’s important to separate these tasks, as conflicting interests could lead to bosses pushing the team too hard in too many directions without a counter-balance.

The product owner will likely be the head of PMM or team lead - their job is to create a prioritized backlog of tasks and decide which requests that come in during the sprint are urgent enough to be done. The scrum master will be the one conducting sprint meetings and ensuring the team doesn’t over- or under-commit to each spring. The scrum master can be anyone (and different team members can even take turns!), but should be held accountable for maintaining the sprint.

Begin Story Pointing

Simply put, story points are a really effective way to understand team output and begin to answer questions like “are we getting more done than we were 6 months ago?”

Story pointing in revenue-facing roles can be tricky, but there are a few easy ways to start. For starters, deem anything that would take a full day of effort as some number - maybe 3, or 5. That’s now your hard cap on how long an issue can take. If something takes more effort than a full day of work, it needs to be split into further issues.

Determine reference stories for different task areas and begin to point as a team - either digitally through IM or in a meeting. Having a story point estimate for each sprint is going to be invaluable to leadership to understanding your team output.

Image by Scrum.org

Conduct proper retrospectives and sprint kickoff meetings

Until now, sprint kickoffs have been unstructured time for the team to decide on what has to get done. In this phase, we’re going to put structure around these ceremonies for a more productive and repeatable sprint cycle. This includes formalizing a time for the team to look back on the previous sprint and discuss how things went and what could go better (the sprint retrospective) and having a more formal approach to planning the upcoming sprint (sprint kickoff).

Entire compendiums have been written on the best way to conduct these meetings on their own - all of which can neatly apply to revenue roles. That being said, the major difference between traditional scrum for software development and this approach is the need for flexibility.

Sales and CS requests are going to pop up through time that need an immediate response. Things like showcasing new product features to a brand new lead, or making an impact on a late-stage deal by an in-person demo. During these ceremonies, make an effort to discuss these points to make sure you aren’t over- or under-committing based on the potential upcoming requests.

Step 5: show off your work

After the first four steps, your team should be an engine - whether tackling SE issues like training or PMM issues like go-to-market, you’ll be more productive than you ever have been and have a lot of solid work to show for it.. So show it off!

The sprint demo is a time to get external shareholders to see the great work your team has done over the last two weeks and speak to the business impact of the work you’ve done. This can be a single 30-minute meeting every two weeks where the team’s product owner invites relevant stakeholders to view and discuss new work and progress - this can be anyone from leadership to individual reps that have requested material.

Hosting a sprint demo is a GREAT way to showcase your team’s value to the organization, and cement your team as a direct contributor to revenue. With economic uncertainty on the horizon, this step will be huge in getting your team a seat at the table when it comes to changes or shifts that your company be taking with regards to go-to-market or strategy planning.

A key to a successful sprint demo is going to be understanding that every sprint is different, so the stakeholders you invite to the demo should be different. Don’t include parties if what you’ve worked on in that sprint is irrelevant to them (e.g. inviting marketing leadership to a sprint demo where you mainly focused on sales training). Keep in mind that people’s schedules are packed, so feel free to only invite them for 5 or 10 minutes before continuing on as a team.

Download The Full Guide

Revenue and sales enablement aren't the same thing. Which approach is right for you?

The Benefits Of Applying Agile And Scrum To Product Marketing And Sales Enablement

1. Faster time-to-market: By prioritizing initiatives that deliver value quickly, product marketing and sales enablement teams can get their products and services to market faster. This can be especially important in fast-paced industries where time is of the essence.
2. Increased collaboration: The collaborative approach of agile methodology can help product marketing and sales enablement teams work more effectively together, leading to better results and stronger relationships between team members.
3. Better alignment with customer needs: By working closely with cross-functional teams and constantly adapting to changes in the market, product marketing and sales enablement teams can ensure that their products and services are aligned with the needs of their target audience.
4. Improved efficiency: The continuous improvement focus of agile methodology can help product marketing and sales enablement teams become more efficient and effective over time.
5. Obvious team ROI: Many revenue-adjacent teams struggle to “prove” their worth to upper management, especially when companies miss their revenue targets. Holding demos and displaying the great continuous work the team is doing with the rationale behind each decision is a great way to showcase ROI for your team

Getting Started With Agile

1. Adopt the right mindset

The first step in implementing an agile approach for product marketing and sales enablement teams is to adopt the right mindset. This means embracing the principles of collaboration, flexibility and continuous improvement.

2. Choose the right framework

There are several agile frameworks to choose from, including Scrum, Kanban, and Lean. It's important to choose the one that is best suited for your team and the specific needs of your organization.

3. Form cross-functional teams

In order to effectively implement agile methodology, it's important to form cross-functional teams that include members from product marketing, sales, and other disciplines

FAQ

How do i know if agile is right for my team?

Let’s be honest - Agile and specific Agile frameworks are not for everyone. While we generally recommend Agile for everyone, there are teams that may not operate the best with a strict framework. Signs you may not be ready for Agile/scrum:

• You are unable to meaningfully affect change or working patterns due to being in a large environment
• You cannot meaningfully predict the work that you will need to do in a week due to the business changing so rapidly
• You have greater than 20, or fewer than 3, people on a single team - the cross-functional nature of scrum needs teams of 3-10 to really be effective

what is the best timeline for implementing agile for revenue teams?

We purposefully left timeline out of this piece for a major reason: it totally depends on your team. Team size, function, and willingness to change are all going to impact your timeline, and it’s as important not to rush things as it is to ensure you’re showing progress.

In general, you can expect this process to take anywhere from 1-3 months, and expect to see significant progress in moving to an agile mind frame by month 2. If you find that it’s taking your team a lot more time to get used to tracking tasks or getting out of the habit of immediately responding to every outside request, try to understand why it may not be in their best interest to do so, and realign to why your team is going agile.

What is the best way to story point?

Story pointing and estimating tasks can be as simple or as complicated as you like - and will definitely come down to the scope of work your team takes on. Planning Poker using the fibonacci scoring system is a fantastic way to get started and make sure that estimates are spaced out enough to avoid confusion while making it easy for the team to assign estimates.

In general - if you have members of the team that are too many points away from each other, pause and discuss why. Are some members less familiar with a task? Is the definition unclear? In an ideal scenario, the team will largely agree on each task’s effort, with any minor disagreements coming down to task definition.

how do i handle testing or verification of tasks?

Verifying tasks is an essential part of many agile frameworks, and is a step in the workflow where a team member verifies that the work done for a task meets the acceptance criteria for that task. While it seems boring, task verification is actually your secret to creating cross-functional PMM teams.

I’ll say that again for emphasis: Task verification is your secret weapon to creating cross-functional teams.

When you’ve reached step 4 of switching to Agile, begin to have teammates ‘verify’ each other’s work when possible - things like reviewing one-pagers, walking through training courses, and discussing fact sheets. These interactions will cross-pollinate your team and get exposure to different functional areas that they may not be familiar with, but know well enough to verify.

This will potentially slow your team down in the near-term, but will make your team much more powerful in the future as more team members gain the capability to tackle different problems. In the end, you should have a relatively flexible team of powerful generalists with specific areas of focus instead of a team of specialists working alongside each other.

And remember - Agile is about people over processes. Keep your team in mind at all times, and if any part of this guide isn’t working, change it!