Read Time: 12 minutes
A HUGE thank you to our newsletter sponsors for moving this newsletter to free for our readers. PAID subscribers will continue to receive access to the templates from this newsletter. If you're reading this but haven't subscribed, join our community of over 966 crazy smart Revenue leaders.
This week’s Newsletter is brought to you by Growblocks where you can manage your full revenue engine from traffic to churn. We allow you to apply data-driven and scientific methods to grow revenue predictably and efficiently. Watch a 5 min demo of how it works here or listen in to our podcast here.
And brought to you by Coefficient which offers 18+ Google Sheets data connectors for platforms like Salesforce and Hubspot, catered to RevOps pros like us. Thanks to Coefficient, I’ve eliminated the need to copy-paste data into sheets, and blending data from multiple systems is a breeze. Click here to unlock automated reporting, snapshots, and deeper analytics in your spreadsheets.
_________________________________________________________________________
So you've been asked “what should our tech stack look like?” If you follow the noise that is LinkedIn you'll be inundated with opinions with vested interests. Systems integrators telling you to implement Salesforce because it's more suited for the enterprise. Hubspot consultants telling you to go with Big Orange (aka Hubspot) because it's a better value and that it's up-and-coming. I love these arguments don't get me wrong. But how about building a technical stack that's best suited for your business regardless of what the pundits say.
Today I'd like to attempt to give you a framework of how to think about your stack. I won't be giving you an answer. That's your job.
I’m here to provide you a mental model you could use. The very first thing I like to do is to break down the customer lifecycle. After doing that, the role of Revenue Operations concerning a technical stack is to define capabilities. Those capabilities are either fulfilled manually or through automation. Remember, the purpose of tools is to allow you to shift internal administrative time to external selling time within the confines of the resources available to us.
Given unlimited budget and time I would go and get every tool under the sun and staff the company one-to-one with an operator. Oh what a luxury that would be!
Lastly, I'll walk you through high level requirements framework which will allow you to do a bottoms up matching between your desired requirements and the vendor's offering.
But first, let's dive into the customer lifecycle.
The Customer Lifecycle
There are many frameworks for describing the customer lifecycle. One model I have come to appreciate is from Winning by Design. Their lifecycle consists of five stages:
Awareness: The customer becomes aware of your company and the products or services you offer.
Education: The customer starts to research and consider your product or service as a potential solution.
Selection/Conversion: The customer decides to purchase your product or service.
Onboard: The customer successfully begins using your product or service.
Use: The customer uses your product or service without assistance from your onboarding team.
Expansion: The customer continues to use and expand their use of your product or service.
Mapping Capabilities
Now that you have your lifecycle mapped out it's time to assess our capabilities. I've outlined a few questions to assess where we are.
Does this process exist? Yes or no.
From 1-10, is this process automated or manual? 10 is fully automated, 1 is manual. This score is very important because it should look at whether it handles every single edge case you can throw at it. Generally, the most customizable tool will be your 10 but also potentially the most expensive and difficult to administer.
Does this system integrate into our system of record for this lifecycle stage? Rank from either Low (no connection, offline process), Medium (one-way connection or requires manual imports), and High (bi-directional) sync. You may have multiple systems of record. For example, in the Awareness stage Marketo or Hubspot maybe be your SOR. For Consideration and Acquisition it's your CRM.
Is this a standalone or bundle solution? Bundling means the capability is lumped with other capabilities from the same tool.
To help visualize the lifecycle and capabilities I've added a sample capacity calibration template for paid subscribers below. However you do this, it helps to boost your stakeholders' understanding of how the systems serve up your processes.
Gathering systems requirements
Developing system requirements for revenue operations typically involves several steps.
Define the scope
Gather requirements
Prioritize requirements
Define functional and technical requirements
Validate requirements
Document requirements
Review and improve
Implement and test
Let's dive into each one.
Define the scope
Determine what business processes and systems are involved in generating revenue and identify the specific areas where improvements or new requirements are needed. For example, let's say you have been tasked with developing a lead routing capability.
Gather requirements
Collect information on the business processes and systems that impact revenue operations. This can be done through interviews with stakeholders, surveys, or other methods.
Here is a sample of requirements for our example:
Ability to scan reps calendars to serve up availability
Conditional logic to determine who to route leads to
Update information within our systems of record based on lead routing logic
Ability to deduplicate
Round robin based on availability
Access external APIs for enrichment purposes
Prioritize requirements
Evaluate the gathered requirements and prioritize them based on their impact on revenue generation and the feasibility of implementation.
One of the most important requirements for our example is the ability to round robin a lead to a teammate if the owner is on vacation.
Define functional and technical requirements
For each requirement, define the functional and technical specifications needed to meet the business needs. Functional requirements specify what the system needs to do, while technical requirements specify how the system will do it.
Validate your functional design with a sales leader. They'll likely trust your judgement but it doesn't hurt to include them. For your technical requirements bring in a peer or your technical account manager if you've purchased a solution.
The more eyes on the solution the better.
Validate requirements
Review the requirements with stakeholders to ensure they meet the business needs and are technically feasible.
Get your stakeholders to sign in blood. Just kidding. But seriously, get their approval in writing.
Document requirements
Document the requirements in a clear and concise manner, including use cases, process flows, and acceptance criteria.
Review and approve
Review the requirements with stakeholders and obtain formal approval to proceed with system development.
Implement and test
Develop the system based on the approved requirements and test it thoroughly to ensure it meets the business needs and technical specifications.
Roll out and monitor
Deploy the system and monitor its performance to ensure it continues to meet the business needs and generates the desired revenue.
Developing system requirements for revenue operations requires a thorough understanding of the business processes and systems involved, as well as collaboration and communication among stakeholders to ensure the final system meets the business needs and generates revenue effectively.
Risks of failing to define proper requirements
Failing to define proper requirements can lead to several risks. Overall, failing to define proper requirements can result in significant risks, including increased costs, delays, lower quality, disengaged stakeholders, scope creep, and regulatory issues.
Cost Overruns: Without clearly defined requirements, it can be challenging to estimate the time and resources required to develop a system, which can result in cost overruns as development progresses.
Delayed Timelines: Poorly defined requirements can lead to a lack of clarity and confusion during the development process, which can cause delays in the timeline and result in missed opportunities or revenue.
Lower Quality: Without proper requirements, it can be challenging to develop a system that meets the business needs or operates effectively, which can lead to lower quality, more bugs, and reduced reliability.
Disengaged Stakeholders: Failing to involve stakeholders in the requirements process can result in a lack of engagement and commitment to the project, which can lead to lower adoption and slower ROI.
Scope Creep: Without clear requirements, it can be easy for the project scope to expand beyond the original vision, leading to scope creep, increased complexity, and more significant risks.
Regulatory and Compliance Issues: Failing to define proper requirements can lead to issues with compliance and regulatory requirements, which can result in legal or financial penalties.
Using prioritization frameworks to decide what to do next
I’ve long been a fan using an Impact vs Effort Matrix to decide which direction to go. In Revenue Operations you’ll receive inquiries from across the business, at the same time. I don’t think I’m exaggerating when it feels like accomplishing your job is IMPOSSIBLE.
I’m a fan of creating incredible focus within the business. It’s too easy to say yes to all the requests within the business. By leveraging a prioritization framework it'll allow you to attack your chips in the areas that matter.
The first option before is my preferred choice but check out a few other well known frameworks you can adopt and adapt.
Value vs. Effort Matrix (my preferred choice because it’s simple): This framework involves dividing tasks or requirements into four categories - High Value, Low Effort; High Value, High Effort; Low Value, Low Effort; and Low Value, High Effort. This helps to prioritize tasks based on their potential value and the effort required to complete them.
MoSCoW Method: This framework involves dividing requirements or tasks into four categories - Must have, Should have, Could have, and Won't have. This helps to prioritize tasks based on their importance and urgency.
Eisenhower Matrix: This framework involves dividing tasks into four categories - Urgent and Important, Important but not Urgent, Urgent but not Important, and Neither Urgent nor Important. This helps to prioritize tasks based on their level of urgency and importance.
Cost of Delay: This framework involves calculating the cost of delaying a particular task or requirement and prioritizing tasks based on their cost of delay. This helps to prioritize tasks based on their potential impact on revenue, customer satisfaction, or other critical business metrics.
Kano Model: This framework involves categorizing requirements or features into three categories - Must-have, Performance, and Delighter. This helps to prioritize requirements based on their ability to meet basic needs, improve performance, or provide unexpected delight to customers.
Whenever you're ready, there are 2 ways I can help you:
1/ If you’re looking to further develop your Revenue Operations knowledge sign up for my courses in partnership with the RevOps Co-Op.
→ Unleashing ROI course. A ten-week virtual, live instruction RevOps course designed to level up your RevOps Impact (R.O.I.). Lessons from my career scaling from $10M to $100M+. Join 50+ alumni. https://www.revopscoop.com/learn/unleashing-roi-course
→ Sales Ops Masterclass. A six-week virtual, live instruction SalesOps course designed to take your sales operations skills to the next level. https://www.revopscoop.com/learn/salesops-masterclass
2/ Promote your Revenue focused startup to a newsletter with over 900 tenacious revenue leaders. My eventual goal is to shift this to a completely free newsletter for my readers through sponsored ads. Reply to this email if you’re interested in receiving a media kit to learn more.
Paid subscriber access 👇
Lifecycle and capabilities tool
Keep reading with a 7-day free trial
Subscribe to RevOps Impact Newsletter to keep reading this post and get 7 days of free access to the full post archives.