Nancy Dong, CEO of Roster, on the rise of ops-centric tooling

I'll give you an example: one Sales Ops at a Series B company might be helping a team of 20-50 people with various activities to maximize their revenue potential. They’re building the forecasting and prepping business reviews to ensure board decks present coherent narratives. They’re designing the compensation plans, making sure account executives are properly incentivized and paid on time. They're maintaining infrastructure  like the systems around the CRM to make sure tools are  talking to each other. They're streamlining procedures and playbooks and automating pockets that they see are very manual for a sales rep to do. That's a sampling of some different activities. The idea is that with this sales ops person, this team will grow much more quickly and more profitably than one that doesn't have one. They are very much an unsung group.

How did this work get divorced from just the work of the sales team or a sales leader? Do you have a historical sense of how it became a separate skillset that’s also generalized across other domains like marketing?

Typically early stage companies are founder-led sales, where the founder's doing everything. You don’t need the sophisticated Ops set-up here.  

At Series A, there's one sales manager, maybe two sales reps, where the sales manager is actually doing the incentive design, like building the processes, setting up the Salesforce or HubSpot instance and building these automations. Around Series B, where there’s a clear shift from 0-1, to 1-100,  it becomes pretty clear that a dedicated Ops person is needed. 

Sales reps are actually picking up the phone and calling people, or emailing prospects. They’re setting up meetings and closing deals. But there needs to be someone who is thinking about the overarching system for the function, since driving repeatable success is the goal of scale. Historically, that’s what companies have learned is critical for a well-oiled sales machine. Post product-market fit, companies start thinking about efficiency as their sales org grows. The questions start becoming “How do I maintain productivity while adding headcount?”, or “how do I scale effectively?”

If you ask the majority of Sales Ops how they ended up at the job, they’d say it was an accident. It’s typically a very data-savvy, process-driven systems thinker. They often stumble into the role by coming from a strategy and planning function, or some finance function, or from a more general function like business ops. 

Let’s contextualize some of this within Roster and what you’re building. What does Roster replace in that workflow for a sales ops team?

The core problem that we're solving is around lack of internal visibility into who is doing what, when they're doing it, and what behaviors actually move the needle. If you don't do that properly, there are pretty profound consequences - lost revenue and efficiency. You can't improve what you can’t see in the first place. Our product, at its core, is data aggregation. We're pulling event logs across a pretty disparate  sales tech stack, like Salesforce, Gong, and Salesloft.

Event logs means event streams of user actions and behavior. Behaviors can include a Sales Manager frequently listening to their reps’ calls in Gong, or reps sending post-call recap emails in a timely manner. Tying these timestamped behaviors to a business process can be a path. For instance, a deal advancement path can include having a demo, engaging a Sales Engineer, updating the opportunity notes, launching this email sequence and making some personalized changes to the email before sending it off. We want to contextualize users’ workflows across fragmented  tools, and piece it together so that it's apples-to-apples.

At the very core, what we're building is data aggregation. It’s a really gnarly data modeling problem. We're mapping events with business processes, and then tying that to outcomes. Creating a universal event log is a really tough mapping categorization problem to crack. 

Permalink

Getting into the concrete functions, when someone logs in, what do they see on their dashboard? What do they see and what do they take action on?

We're building the MVP right now — iterating on prototypes quickly with design partner feedback. So depending on the day or week, this answer may be different. At a high level, we’re showing a very simple dashboard of what operational inputs we recommend an Ops user should take to drive a specific business outcome. One example is: ‘Hey your new SDR cohort is far less productive compared to prior cohorts of the same tenure. The issue is process compliance. They call outside recommended times, send far too many emails, and do not submit timely scorecards. If fixed, here’s the expected impact on ramp time and revenue.’

In the future, there'll be some very interesting auto-detection of execution playbooks. Figuring out where we see the biggest variance in behavior, or highlighting manual bottlenecks, detecting them and creating automation for that. Also, with richer data, we can surface more sophisticated recommendations: ‘Based on what we know about your business, this is actually a better way of running this process.’ Or ‘If you're starting from square one, here's a starter pack for setting up your initial sales engagement playbook’. But that's very, very far ahead. We have a much simpler visibility pain point to address first.

As far as other ops disciplines, to what extent is that expansion for Roster just a matter of swapping out different data on the dashboard? Is it just integrating with different software suites? Or is the work of marketing ops so different from sales ops and FinOps? What’s the degree of similarity and therefore ease of expansion for Roster?

At a higher level of product abstraction for Ops, everything is a funnel. And there are certain things you have to do in each stage of the funnel. The way that an SDR (sales development representative) engages with a prospect using LinkedIn Sales Navigator, Outreach—and all these different tools—is remarkably similar with how a recruiter engages with a candidate in outreach. We have a pretty ambitious goal to go horizontal, but we don't know what we don't know. We have a strong hypothesis after observing so many different functional Ops workflows that the way we model data to mirror operational reality, and serve insights to an Ops audience, can be pretty templatized to other functions.

How would you describe your positioning with respect to a few companies like Ramp, Rippling and AbstractOps? Do you see it as potentially competitive or potentially partnering?

Definitely partnering. We're customers of AbstractOps, Rippling and Ramp. The Ops nomenclature is tough because it’s referred to in many different  contexts. The nuances are actually really hard to parse out from a one-liner since the Ops role in organizations is rapidly evolving. All of these different companies need to get better at messaging and be more precise about it, ourselves included. 

A good analogy for what Roster wants to build is: what Salesforce built for sales, what Rippling is now building for HR/IT, we want to build that for functional Ops.

Rippling’s data schema is around employee records. On top of that, they have built a robust product portfolio that covers where all this employee info is deeply embedded. AbstractOps’ is around company records, an intelligent index for all company back-office items, including a vault of documents relating to stakeholders and company relationships with those stakeholders. 

Ramp's is around all spend transactions  that your company has done. And they’ve built expense management, bill pay, and vendor negotiations on top of that.

Permalink

If Ramp is the ledger of every transaction your company makes, for Roster translation that to ops, would it be every action that sales reps take?

It’s every action that internal employees take. Take what Heap, Amplitude and Mixpanel are doing in the product analytics category. What they do for capturing interactions between the customer and your product externally—think of Roster as mirroring that internally. Every single interaction that an employee team member does in their day-to-day tools, that's our ledger.

Permalink

Are there other names that come to mind, companies that are doing operations well, or are relying on other products or companies?

The best ops people I've ever met are robust users of Google Sheets and Google Docs. That's part of the reason why we're building Roster, because all the documents I've seen from different ops at different companies are all trying to structure the same content. That can include: process maps with desired outcomes, moving from this step to that step, what different users or teams are supposed to do at each step, an execution playbook, how systems are set up, how this CRM should talk to these other tools, how data should be piped through the data warehouse and then back up through some BI (Business Intelligence) tool, etc.

It's all the same content with the same goal in mind —  they're just doing it in very different formats, some  combo of Google Sheets, Google Docs, Lucidchart, and Figma. But everything they're producing, and all the tangible artifacts that are associated with doing Ops  work, is essentially the same. If we take sales, there’s a pretty clear set of tools that they rely on, centered around primarily Salesforce, Gong, Outreach or Salesloft. But from my perspective, there's no clear stack that overlaps all excellent ops leaders, aside from Google Sheets.

Permalink

When it comes to the usage of Google Sheets and Google Docs, is it important that those are in the cloud and can be collaborative? Or is it primarily one person's view of this data and organizing the chaos? Are those process setups collaborative documents?

Yes, because the inputs and outputs require  different individuals and teams. For example, if a sales ops person is putting together an effective prospecting playbook, and it ends up being used in training, a good chunk of the input comes from  anecdotes. Ops people have to hunt down best practices and approach people on the sales team: ‘You're a really good sales rep, what do you do?’ It's essentially a series of Slack pings and regurgitation from someone's memory of what they think they do. Then that is structured into some sequence: ‘Here’s what you should optimally click on and this should be the result.’

How do you think about Roster’s positioning with respect to Looker, Tableau and other BI tools? What are some limitations of those BI tools?

Roster is complementary to those traditional BI tools. Taking a sales use case, a BI tool may tell you how your quarter will end. Are you going to meet revenue targets? Here's some high-level business metrics. Whereas Roster would come in and analyze, tactically, how you fix something if it's not going the direction that you want. A BI tool will be like, ‘this is red.’ But Roster would be like, ‘How do we make this red a green? Let's talk about action.’ 

It’s addressing the specificity or double-click into actions, so companies can actually influence change instead of just reading out more high-level cuts of data.

The reason this hasn't existed or been built into BI tools is because the internal teams that typically build these views and are tasked with maintaining them don't have the operational context. The data analyst is not the one running the business. For a ramp time analysis, you need more business context to understand the mechanics of when a bunch of new hire classes started on Monday and they need to be ramped by month three, what they should be doing in order to get to that ramped state at month three, and what are leading indicators to show if that’s at-risk at month one.

Permalink

Is the data warehouse a conceptually important thing to integrate with and a source of data for what you're building? Do you consider Roster part of that modern data stack?

There’s a lot that’s TBD at this point, so I’ll describe what I think is going to happen. My view is Roster is another part of the stack sitting on top of a warehouse. Our software is going to aggregate and model the data for you, because the alternative is data that's trapped behind all these different third-party siloed tools, or you hire a bunch of BI resources.

Ideally, we have a bidirectional relationship with warehouses where Roster is both a product of data stored within warehouses and a potential input into the warehouse itself. In the best case scenario, Roster both uses and supplies data into a warehouse. The raw component objects that Roster uses are ideally stored in a warehouse, and an API like Snowflake.

You mentioned previously that operations have historically been hard to measure. Can you expand on that? Because it sounds measurable when you talk about increasing efficiency of sales reps, which we can track with Sheets. What makes it hard to measure and is that an obstacle for Roster or something for you guys to figure out a way around, or prove the value proposition for?

I’ll give you an example of a typical internal dynamic. Sales Ops oftentimes report to the CRO. What the sales ops person is doing or advocating for is hard to measure because they don't own metrics, all their metrics ultimately roll up into the CRO. A common tension that we see is a sales ops will tell the sales manager that they need to properly maintain Salesforce hygiene. But the sales manager will rebut that because it takes time away from them talking to customers. They see it as a waste of time because they need to close deals.

There's this constant friction. Sales ops, because they don't have the behavior data that ties to outcomes—which is ideally where we would plug in—can't say, ‘well, you should do this because this directly impacts your velocity and quota attainment. We can prove it..’ The interaction today is this empty like, ‘well, just keep it up-to-date.’ Essentially, ops lack a  data-driven way to back themselves up when they say, ‘please follow this process or please adhere to these things because it impacts us in X, Y Z way.’ They also can’t measure if a process they put up is bad, and actually create a new set of problems.

This transcript is for information purposes only and does not constitute advice of any type or trade recommendation and should not form the basis of any investment decision. Sacra accepts no liability for the transcript or for any errors, omissions or inaccuracies in respect of it. The views of the experts expressed in the transcript are those of the experts and they are not endorsed by, nor do they represent the opinion of Sacra. Sacra reserves all copyright, intellectual property rights in the transcript. Any modification, copying, displaying, distributing, transmitting, publishing, licensing, creating derivative works from, or selling any transcript is strictly prohibited.