We have made it to Episode 50! We can't believe it! Thank you for tuning in every week and listening (or watching) the show. It means so much to us, and we can't wait to give you another 50 episodes!
For those of you who don’t know, we decided to do away with Mondays, so we decided to rename them first Tuesday.
All jokes aside Jess is planning her next trip to Disneyland since she has never been before. She’s heard they have great food so if you have any recommendations for her let us know!
On another note today we are getting into the meaning of the business process must drive the technology. Today it’s all about our prime directive.
Audio:
Video:
Additional Resources:
[RevOps Show} Episode 48: The Impact of Sales Methodologies
[RevOps Show] Episode 49: Beware the Hidden Dangers of Automation
[Blog] What Is System Design & Why It's Crucial For Smart Growth
Show Notes:
What is the full prime directive?
We have a prime directive whenever we touch any technology or do any type of implementation. And that is the business process must drive the technology. The technology should never dictate the business process. To know how serious this is, Doug says this statement at least 50 times a week.
This statement has a tremendous impact when we are talking to someone who’s beginning to think about what’s needed, especially when we’re talking to their IT team. Today we’re going to talk about what the business process must drive the technology really means. Doug has come to realize that people love the concept and love the idea but don’t put it into practice when they get in the driver's seat.
What sites having the business process drive the technology look like?
It follows The Revenue Acceleration Framework which is a framework we’ve been working on.
We created this framework about five years ago. Part of why it was created was to try and really articulate the need, requirement and focus of revenue operations. There is a chasm between the strategy of an organization and its execution between the intent of the strategy. Part of the problem is that people misapply strategy. Strategy is a clear guiding policy that enables decisions to be made in a way that aligns the vectors of the decisions across multiple people in real time.
As this relates to your go-to-market motions, your go-to-market strategy really needs to frame out everything. What’s your economic model? What’s your go-to-market positioning? What’s your messaging? That drives your structure. Your structure is your system design. The tools you use, your tech stack and your scoreboard all drive your approach. Your approach is what is your modus operandi? It’s the playbooks, the methodologies, and the processes you have. Whether you have documented playbooks, processes and methodologies or not, you have them. That structure and approach is guided by your go-to-market strategy. The business process is tied into that.
In a previous episode we talked about methodologies. Business processes are mixed with these methodologies to maximize the opportunities and probabilities of having successful outcomes.
Is there a core part to making sure the business process drives the technology? Is that starting to document and outline those things?
Doug would say if it’s not documented, then there’s no way that you can make sure the business process is driving the technology. You have a process, but your process is varying. The difficulty there is that the process is bad and you can’t learn from bad process. Bad processes produce very unpredictable outcomes.
It’s like playing poker. On any individual hand, luck plays a really heavy role, but as you add more and more hands, luck becomes less and less of a contributor. Over the course of the year playing poker, luck accounts for 5-10% of your results in a particular hand. It probably accounts for about 95-98% of your results. What enables you to get from luck playing 95-98% to 5% over time is your ability to learn. You’re able to make adjustments to continue to increase your probability, increase your decision quality, and improve the actions you take. If everything is different, it would be like A/B testing. Without there being a stable element, you won’t be clear on what you’re doing. If you try to play to luck it will only drive your decision quality down.
If you don’t have your process documented, you won’t execute the process of the methodology precisely every time. If you have it documented, you can realize where you deviated from the process.
What the process does is manage the trade-offs you’re making. To make something easy, you have to make something else hard. More than 90% of the time when someone tells Doug that their CRM isn’t working, we find the issue is really in the business process.
People don’t adopt technology. People don’t adopt CRM, they adopt business processes. They adopt methodology, so if we don’t know what we’re trying to do and if we don’t have a clear process in place for how to win, how do you win? There’s nothing to adopt.
What is the definition of a good implementation? One that gets the job done with the least amount of stress. But what’s the job?
One of the biggest complaints we hear about CRM implementation is the company bought the platform to free their salespeople and the problem is they spend more time in the CRM than they do talking to customers. Where it loses focus is there’s a bill they’re paying for the CRM and they want to get their reps in and fast. They don’t want to think through the business process pieces because of that. They are not thinking about the cost long-term. There is no such thing as successful tech implementation because there’s no objective, no outcome and no win to achieve.
Where the CRM is most powerful is that it can nudge and restrain so that people are following the process without having to think about it. If there is no process defined, then there’s nothing to nudge or to go against. You’re playing a game of six-dimensional whack-a-mole. The other difficulty here is you can never get to complete. When you change your CRM, you’re changing behavior. If the behavior change isn’t in alignment with the process to guide that behavior, then what’s guiding the behavior?
Good business process does not mean the process has to be good. It means there is a clear hypothesis. You will have ambiguities in your business process if it has not been refined over the course of years. Technology will fill in the gaps and that’s where havoc occurs. If the system isn’t working like you want it to, where’s the business process? The business process means that you say yes to some actions and you say no to others. A choice and a trade-off.
For people that don’t have a documented business process, do they not know how to apply that business process to technology? Or is it just a hard concept to understand?
The hard thing about that is it is hard. The worst thing we can do is try to make them easy. It’s less about business processes and about documenting than it is about defining the business process. Making hypotheses are hard especially when you’re initially developing a business process. There’s a lot of uncertainty in it, and technology gives you certainty.
Jess’s Takeaways:
- The rationale is business process.
- You’re not a sales organization without standardization.
- Your CRM does not close business. That’s a misconception. Everyone thinks they’re going to get a new CRM and close a lot of business and that’s not how it works.
Next Steps:
-
Follow Jess, Doug & Imagine on socials for updates on the show or other insights:
-
Doug Davidoff: Twitter - @dougdavidoff | LinkedIn
-
Jess Cardenas: Twitter - @JessDCardenas | LinkedIn
-
Imagine Business Development: Twitter - @DemandCreator | LinkedIn
-
-
Subscribe to the show on Spotify & Apple Podcasts
-
Check out Let's Play RevOps on Twitch for more commentary on this topic
-
Listen to Episode 51: How RevOps can Best Utilize Revenue Intelligence