Brittany gave this presentation at our Future of Sales Festival in December 2021.

If you didn't catch last year's edition, you can watch every minute of every SEC event OnDemand with an SEC membership.

And don't forget the latest edition is next month! Book your spot for free live access on June 7-8.

Why should you switch your project-based approach to a problem-based one?

At Yelp, we've been solving some unprecedented challenges within the business over the last 18 months, as I'm sure you all have as well and we've seen some pretty fantastic results.

SEC recognized that by awarding us with the Sales Enablement Team of the Year 2021.

While our onboarding training, our tech stack may look quite different, the approach we take to identifying problems, aligning resources and driving results in something that can be applied just about anywhere.

Here’s a breakdown of our main talking points :

  • What is “project-based” and why it’s holding you back
  • How to pivot to a “problem-based” approach (and get that $$$)
  • What this looks like in practice

But before we dive in, here's a bit of background on me and my role at Yelp.

About me and Yelp

My background

I started my career in sales and marketing strategy consulting. I pursued an MBA in the UK and wanted to pivot into tech and while I was living in the UK that I found Yelp.

I was hired at Yelp to be their first international b2b marketing hire, we were working to drive customer acquisition in Europe at the time. Those efforts led me back to the US where I spent several years scaling our B2B marketing efforts globally, from acquisition through to customer retention.

Three years ago, I was asked to transition into this role and at the time, it was just me in enablement. We hadn't yet had a centralized function of the business really supporting our revenue teams and at the time, we had 2,000 individuals needing that support.

I spent the last three years defining that function at Yelp, from hiring talent, establishing workflows and areas of focus, optimizing how we support revenue, not just in sales, but now also in our support, and our cross sell and upsell revenue teams.

If my career had a headline, it would be that I focus on solving problems between the business and its customers.

How we support our revenue organization

Firstly, I want to offer a little bit more information about the business that we support to set some context.

My team supports what we refer to as our local revenue organization, that includes sales, customer success and cross-sell/upsell teams.

We support that organization through a number of services. We're responsible for optimizing sales and support processes, supporting our go-to-market approach.

We're responsible for delivering robust learning and development curriculums to individuals at all levels of the business throughout their career journey.

We also have to support product efforts to test and launch new products and keep our org connected and engaged.

What is “project-based” and why it’s holding you back

What do I mean by “project-based”?

As I've made mistakes and grown in this role, and advised and mentored others that are solving similar problems, there's a clear theme in the way that enablement teams operate or approach their work that lead to success or failure, mine included.

Here's how I define a project-based approach:

  • Work is defined by many separate projects that are supporting many sub goals or initiatives and you might be inundated by requests from management or leadership and feel spread thin.
  • The reason for work is often following best practice vs being truly rooted in a defined need within the organization.
  • Work is mostly reactive, you are working to solve urgent issues that are appearing today but you are not necessarily allocating a lot of your resources towards building for the future.
  • You have limited visibility into trends in the organization beyond your immediate project list.

Red flags

Here's some red flag phrases I hear quite a bit which are signals to me that someone or a team may be operating in a project-based approach.

🚩  “It’s best practice” or “it’s industry standard”

This can be a trap, when you're building programmes or launching initiatives and you want to do so inclusive of proven methods within businesses solving problems. The trap is when it becomes the primary reason supporting the work.

When something is being prioritized because “it’s best practice”, it’s important to ask, is it going to be about the need? Is it defined? Do we have a clear measure of success? If we don't, I would really question its prioritization.

🚩  “We used this at my last company and everyone loved it”, or “our competitor has it/does it”

Experience is valuable and competitor intel can be valuable but what worked to solve a problem that one organization would work to solve another at yours is a really dangerous assumption to operate with.

It can leave you blind to the root of the problem you're trying to solve and exclude end user insights and their feedback as well as the simple fact that those assumptions could be incorrect.

🚩  “It's probably because…”

Probably implies that we don't yet have a clear enough understanding of the problem and we need more information.

This might not always be possible with hard data, but I would really encourage folks to pursue strong qualitative insights. It’s generally low effort and it can head you off from making a big mistake.

When we're doing work based on what someone or a few people think, or what a group believes vs knows to be true, that's a red flag.

What does it feel like

What does it feel like to operate in a project based approach? Most likely, a lot of your work is reactive.

You have an assembly line of request coming through, you’re summoned after the problem has been identified by someone else (management or senior leadership) and they have specific requests.

Your adoption is low, maybe you're launching new programmes, new content, new tools, and it feels like you're having to pull teeth in order to get your reps to engage with it.

It could also feel like the Wild West. Reps and managers are creating their own materials, their own tools and processes and often these can be in conflict with what you are trying to reinforce.

At the end of the day, you're not seeing results, and there's no revenue impact which is not an empowering, rewarding or sustainable place to operate.

How to pivot to a “problem-based” approach (and get that $$$)

There are four pillars to a problem-based approach: truly understanding your customer, building a flexible team, leading with minimum viable products, and becoming a proactive thought partner.

Understand your “customer”

You can't excel in enablement, if you don't have a deep understanding of your business's customer but in this case I'm talking about enablement’s customer meaning reps.

Understanding your customer means you have a constant flow of qualitative and quantitative insights from reps and their voice is well represented in your work.

Some ways that you can ensure that happens include:

  • Consistent one on ones with directors, managers and reps
  • Architecting councils of top performers across the business
  • Facilitating weekly feedback sessions and surveys for pilot participants.
  • Staying plugged in wherever you can to the insights you have available such as engagement surveys, exit surveys, and even Glassdoor reviews can be hugely valuable to understanding the rep experience.

This is important because when you are so closely connected to frontline reps, you can begin to see the future. That means you're hearing about emerging problems or challenges before they even flow through clearly in the numbers.

You can use those opportunities to validate and start planning solutions you want to pilot. You're then able to have enthusiastic pilot participants because when you are prioritizing solving relevant and meaningful problems for reps, they want to participate.

Having these close enthusiastic participants, results in higher programme and tool adoption and smoother change management and launches.

Successful pilots sell themselves, you don't need to pull teeth to try and get people on board because word is likely already spread that the change or investment you want to be making has been proven effective on a pilot team and that leads to a smoother rollout.

Build a flexible team

A flexible team means you have individuals with core responsibilities and expertise who are enthusiastic consultants and support resources for other activities.

Some ways you can do this include:

  • Hiring people who are truly motivated by solving problems vs. tackling specific types of projects.
  • Creating healthy environments to collaborate
  • Giving them the autonomy to go and problem solve.

We all know business needs ebb and flow. You may have some quarters heavy on tool and process improvements vs. training or learning and development requests, and when you hire people that can be your subject matter expert on the team for a specific area of focus.

You can serve those at the highest level, but when those individuals also operate very flexibly, you can have those individuals jump in wherever needed.

This allows you to move fast, so you don't have bottlenecks to any urgent high impact work. The team can also begin to think more strategically about tackling problems or achieving growth objectives.

If you have individuals focus on learning and development then you have others that focus on enablement programmes. Collaborating together, they can start to understand how their specific areas accelerate or support others.

Then you have, hopefully a happy and high performing team, you're giving them greater visibility into the business, more visibility into how their work directly contributes, and also giving them opportunities for continuous learning and development of new skill sets.

Create minimum viable products

Tools and tech can accelerate behaviors that lead to revenue. They're also costly to buy, implement, and maintain and anyone who's ever had a failed tool or tech rollout can tell you it's definitely something you want to avoid. How do you avoid it?

My number one recommendation is thinking scrappy. Ask yourself can any part of this tool or technology be validated before we build it or buy it? Chances are, some of it can. It might be strung together with a spreadsheet and a type process and a lot of work for a couple folks but that's okay. What you are trying to do is validate the need and impact assumptions for that investment.

I would also urge you to continue to act scrappy. I have seen more than once these scrappy solutions take care of 80% of the problem. It's important to keep that mentality because investment in your tech stack is important and you need to think carefully about that investment, the need and maintaining that platform over time.

A pilot will be the way to get a truest read on the potential impact and also the barriers to launch. When you pilot, hosting frequent feedback sessions with your users to get qualitative insight helps ensure you have a full understanding of potential opportunities and also problems that could arise.

When you're taking on a scrappy mentality, you're pulling things together and the user experience may be suboptimal and it's important to set that expectation with the pilot team. Pitch it as an opportunity for them to help evolve how that solution rolls out to the business if there is an opportunity there.

What does this create for you? It means you can get buy-in on new investments from the org more easily because they’re seeing the results. There's also less pushback on budget requests.

Even if it's a scrappy solution, you've already proven ROI to the business and the execs making the decision on where to spend those dollars are more inclined to put those chips on something we feel more confident about.

Become a proactive thought partner

If you have customer insights, a flexible team, and an approach for proving ROI of your tools, tech and other investments, you can now pivot from being reactive to a proactive thought partner.

This looks like being a canary in the coal mine. Being so well connected to the business and reps that you're raising your hand to say “there's a growing problem” or “I see an opportunity”.

You might have some strong customer feedback channels on the enablement team but you might not have the full picture of the business and you should make it your job to ensure you do.

It's important you understand org performance, KPI trends, and progress behind any strategic initiatives. You can use all that to validate what you're hearing from reps and in turn, go to reps to learn more about what you're seeing in the data.

In a project-based world folks often operate off of requests and these requests come from conversations happening amongst management or leadership. If you're not in these conversations, insist on being in the room.

Requests are often someone's interpretation of a problem, a good example of this is the more training request. When you have the full picture, you can drive more impactful solutions.

Ensure you're focused on solving the problem vs. just checking the box. This leads you to develop more holistic solutions to impactful problems.

It's very rare that we are solving a problem in which only one of the services we provide can solve, often it's training plus a change to process, or a tool investment, it's training plus a strategic communications plan and so on.

When you have a full picture, you can start to recommend these more robust and holistic solutions that address all aspects of the problem.

You're now operating as a strategic vs. service role within the business and you're earning trust of the exec team. They're turning to you to say “what should we be worried about?”, “What should we be thinking about prioritizing for the next quarter, or the next year”.

What this looks like in practice

Let's talk a little bit about what this looks like in practice. Here are three different projects my team tackled over the past 12 months, and the pillars that are most applicable for the work we did and the results that we saw.

Remote onboarding

The problem

In September of 2020, our team got a couple weeks' notice to architect a remote hiring program for the very first time to achieve the same objectives.

That meant taking our robust in person and office curriculum and making it a best in class virtual experience.

This is a good example of the importance of a flexible team and understanding your customer.

The approach

The team dove straight in and began auditing the existing curriculum to see what to keep, modify, throw away and took the initiative to dive into materials around virtual training best practices.

Build

They then entered build mode, we had individuals that had to operate outside of their core expertise or responsibilities to pitch in, it was really all hands on deck to deliver something truly great.

People who weren't normally creating content, we're now creating it and a part of piloting it. To ensure it was going to be a great experience we got it in front of teams before it was live with new hires for the very first time.

Flex

Going back to the importance of having a flexible team, the team also questioned the status quo. In a remote environment, it feels like we could operate very differently and the result was that we ended up opening up some resources.

There's a reorg and the team was able to make space for subbing for session, sprint work that needed to get done and other support activities that otherwise would have had to wait until each onboarding class was over before we could support it.

Optimize

We set up some strong feedback channels with new hires and their managers to ensure that when we were making additions to the curriculum, or iterating, it was rooted in those qualitative and quantitative insights.

The results

The result was that actually our remote hires were SOMETHING quicker than they did in office, which is a fantastic result for a team that had never trained virtually before.

It also increased the efficiency of the team, because we reorged and thought a little differently and more flexibly about how we executed we were able to take on even more.

Project shoutout

The problem

This is about motivating reps in a remote environment. We found that reps were feeling under recognized working from home, they no longer had that office buzz and visibility in the office to motivate them.

This is a good example of the importance of understanding your customer, and becoming a proactive thought partner and then creating MBPs.

The approach

Quantitative and qualitative insights

We were able to raise our hand and identify problems because of our access to these rich, continuous feedback loops from the floor (rep interviews and focus groups, engagement surveys, exit surveys) and propose to get together and explore some solutions.

Explore solutions

Our next step was brainstorming what that could look like. We had to ensure we had the right people in the room to explore what potential solutions could look like, and then decide what to move forward with based on the work and the resources that we had available.

Build MVP

This is when we created that MVP.

To us, that looked like standing up a solution in Salesforce that would alert users once they reached a certain milestone, call out progress, improvements to KPIs week over week and share that with their peers or their director group.

We started small, we had a pilot team working really closely with us, we started with one or two metrics only and we worked closely with them week over week to add takeaway, move, change and ensure that what we were really building was having the impact that we wanted to have.

Expand and ship

As we became more sure of those results, we expanded that pilot. We had validated the results with the initial pilot team, kept the org informed this work was happening, expanded to more teams and then when we felt sure that what we were seeing was real, we launched to great feedback from the business.

The results

We reached the goal that we had, which was driving rep productivity and rep retention.

Yelp “TV”

The problem

In a remote environment, reps felt less connected to Yelp and had less visibility and interaction with top performing reps.

We needed to find a way to break down silos, connect remote hires to our mission, and share best practices from top reformers.

This is a good example of becoming a proactive thought partner, creating MBPs and the importance of understanding your customer.

The approach

Create MVP

We brainstormed and decided to just stand up a couple of what we referred to as TV sessions. These were getting top performers to come and speak, panels, guest speakers from across the business.

Expanded

It’s not about production value but getting something out there for the org to respond to and based on their feedback, we actually spun this up into a series of recurring sessions.

Optimized

We invested in being able to measure attendance, also spun up some post session surveys, and then had some continuous iteration of session types.

The results

The results of this one are also strong. Attendance is strongly correlated to rep performance and we've also seen a large increase in rep confidence in Yelp’s direction over the next several years.

To wrap up: the four pillars

To wrap up, there are four pillars for operating in a problem based approach, understanding your customer, building a flexible team, creating minimum viable products and then becoming a proactive thought partner.

What this should feel like is that stakeholders are leaning on you to see around the corner, reps aren't just adopting but they're reaching for and clamoring for what you create.

At the end of the day, you have a happy and motivated team, you're seeing results and there's revenue impact.

Common Questions

Q: What advice would you have for someone who's struggling to get buy-in for enablement? Especially when getting sales leaders to buy into the function.

A: When you are focused on solving a problem, can you agree on what the problem is in the measure of success?

That's where the alignment should start. If there's great skepticism around certain programmes, or tools you're interested in adopting, I would lean on pilots and they aren't just for technology, we do it for training.

Anytime we're interested in rolling out a new programme, for example a support bootcamp that addresses a specific KPI, we're testing at first and we're always going back to leadership whenever possible with the results that we're driving and the feedback.

Q: How do you think the success of sales enablement should be measured?

A: I get this question a lot. Your work should be very closely exactly aligned to the businesses OKRs that you're supporting. Depending on the size of your business, how concrete you can pilot for and measure real results is very much dependent on that.

Yelp has the luxury of volume, we can stand up 12 pilots across the org and in 30 days have a very clear read on revenue impact.

You may be looking at more directional insights, if you have a longer sales cycle, 90, 120 days, you probably do have some leading indicators that you can tie your specific work to, especially if you're piloting or testing.

Q: How do I get sales leadership to see the value in sales enablement?

A: When I started in enablement, we had a lot of confusion over the process for product rollouts. We had 2000 individuals on the phone, and reps were finding out about product experiments talking to customers.

I would say look to where it seems to hurt the most and see if you can identify some low hanging fruit, to tackle that and start to help them see what the world could look like.

I know when I came into the role some of this work was getting done but it was shared across 25 different individuals.

I think when you can show them what it looks like when someone can truly take ownership of it end to end, you can see results from that and it can be really helpful.

Enjoyed this article? With an SEC membership, get exclusive member content like this delivered straight to your inbox.

And that's not all: you'll get exclusive discounts, templates and frameworks, and OnDemand access to event replays.