What KPIs should I own and not own being the first revenue operations hire at a start-up?

You should own all of the KPIs/metrics if you are the first revenue operations hire. Initially, you'll need to validate the data sources and availability, put a system (and potentially tools) in place to capture them and do the calculations and visulization yourselIf the first few times. I once worked at a company that did not look at any metrics in their weekly executive staff meeting. I made it my mission to develop a simple executive dashboard with operational metrics that was reviewed by leadership at the start of the call. It helped galvanize the teams in the facts and drove better decision-making. And by establishing myself as the data expert with finger on the pulse of the business, I utlimately earned a seat at the table.

As the first revenue operations hire at a start-up, you own all of the KPIs across the functions you support, but at the same time, you don't necessarily have direct influence over any of them. Similar to my answer for another question, you are the glue that holds these functions together and your responsibility is making sure there is strong collaboration and connection between the people working in those functions and the KPIs that they are all supporting. How do your sales and marketing team KPIs (the big ones and the secondary ones) lead to revenue? Make sure you map that out and communicate it clearly across the team to for example, understand how decisions that Marketing makes influence Sales KPIs.

That being said, if you are also responsible for key systems like your CRM, Marketing software, etc., a key KPI for revenue operations needs to be around usage, adoption, and effectiveness of systems and processes that drive the business forward.

Here are some red flags for KPis that you are asked to own:

• There is not support for the KPI

• The KPI definition is not clear and well defined

• The levers for achieving the KPI are unclear

1. Lack of Support - adoption of KPIs and achieving their targets is extremely difficult if you don't have buy-in from the parties responsible for doing the work required to meet the KPI. Say you're tasked with a KPI to drive AE adoption of a new account planning SaaS software, but the AEs weren't consulted on the selection of the tool and largely prefer another tool. Without buy-in from the AEs on the tool itself, you're set-up for a large uphill battle.

2. Unclear KPI Definition - do not ever agree to owning a KPI which is ambiguously worded or does not have a clear way to measure. Doing so is like signing a contract for which the terms of agreement are like a black box. For example, if the KPI is defined as "Improving customer sentiment of feature X", obtain exact clarity on what customer sentiment means and what is used to measure it. How would you measure customer sentiment (e.g. customer survey, feature usage, feature purchase rate, etc). You need to fully understand the KPI definition and how it will be measured to understand how feasible it is, whether you have enough data points to measure the KPI, and whether it aligns to a company priority.

3. Unclear Levers for Success - if the parties responsible for driving attainment of the KPI don't know what are the mechanisms for achieving the KPI, you are not set-up for success. For example, say you're asked to own a KPI related to driving the inclusion of delivery partners on contracts (% of total closed contracts w/delivery partners). If your AEs don't know the rules of engaging delivery partners (e.g. which contracts are eligible for delivery partners, when and how delivery partners can be engaged and sold into the contract) then setting reasonable KPI targets and reaching them will be a challenge.

If you take on KPIs that avoid the red flags above, you'll have KPIs that have greater impact on the business and a greater likelihood of achieving their targets.

I think there are two ways to think about "owning" a KPI when you're in RevOps. For many business performance metrics, you can "own" the KPIs in the sense of providing the data, reporting, and insights that enable other teams to be assessed against. These are things you are responsible for measuring but don't do directly in RevOps. There's a long list of these but the ones top of mind for me would be:

• New business pipeline metrics: things like marketing attribution, MQLs, qualified pipeline (volume and value), conversion rates between stages, deal cycle times, ACVs, ARR, self-serve account volumes and revenue, etc.

• Existing business performance: churn and contraction amounts and rates, expansion pipeline and rates, NRR, GRR, etc.

• Profitability metrics (probably with Finance help) like LTV:CAC, SaaS Magic Number, payback periods, etc.

• Productivity and rep performance metrics like attainment distributions, revenue and pipeline per rep, etc.

Then there are KPIs that RevOps can "own" in the sense of having direct or at least strong influence over the performance. The right set for your company will depend on a lot of factors (and if you're the first hire you may have limited time on these). Here are a few ideas:

• Quality outcomes such as forecast accuracy, quota setting accuracy (e.g., if you have a target of getting 80% of reps to 80%+ attainment, did you do it?), lead and account routing accuracy, and others that assess if you are running a clean process around these things

• Responsiveness outcomes around SLA attainment on deal approvals if you run deal desk, ticket resolution rates and times for other issues from sales people

• Maybe more OKRs than KPIs, but project completion outcomes can also be useful. For example, did we get quotas delivered on time, were new territories assigned within the targeted week at the start of the fiscal year, did we launch a new sales tool on time, etc.?

● Own: Pipeline coverage, sales cycle length, win rates, lead conversion by source, and conversion by contributor. 

● Not Own: Product KPIs, customer success metrics. 

Own everything your CRO owns and nothing he/she doesn't. If you follow this you will do ensure that you are focusing on the things that will drive the business, and deferring things that will not. The projects, the tech stack build, the process streamlining should all flow from this. There is no better way I have seen to ensure alignment to your CRO, and also ensure at the end of each quarter/each year you can look your CRO in the eyes and tell him/her how you and your team has contributed.