Erol Toker is an expert in the field of RevOps (with plenty of experience doing things the hard way) and he's passionate about helping others finding new ways to tackle common challenges and gain real power in this supporting role.
He is a technical founder with over 10 years of experience in the enterprise software space. He graduated from Penn/Wharton and has had success as a Product Manager at Invite Media (acquired by Google) and as a solo founder x2. His current company, Truly.co, is a a robotics platform for revenue teams that automates away all the processes your reps hate and never do right.
We're also kicking off a new course with him in the community - Product Management Fundamentals for RevOps.
In this AMA, Erol will be answering all of your questions around:
Leading the charge with your previously submitted questions, and some of his own is Austin Johnson, Automation Architect at Tray.io.
Austin
Happy to be chatting with Erol Toker who seems to be everywhere all at once! Hope everyone is having a nice day.
It might be nice to start with an easy one as people join in and before heading to some of our more detailed q's that were submitted by folks ahead of this session.
Erol, what are you reading / watching / consuming that helps keep your brain sharp for all the work you are doing?
Newsletters? Blogs? Specific people you follow that are pushing you to new places?
Erol Toker
Hi Everyone !
So excited to be here and talking about my two passions, product and RevOps.
That's a fun one.... so i probably spend 30mins a day with AI trying to crack a problem that I had the day before, not with any expectation of solving it but just to learn the subject matter better. So that could be just dumping support tickets in, or a sales problem.
Example: tomorrow I'm going to dump all the Q&A questions from here to compare how ChatGPT will answer these questions to see if i actually have anything unique to add, or if I'm not that special, and then i'll publish the results on Linkedin.
If I need something totally outside my work domain, I'm reading Bobby Fischer teaches chess to try something new.
Austin
Keeping you humble, eh? Good stuff.
i know Erin posted the link to your shOps talk. Great convo there. That was well over a year ago when you were platforming the idea that RevOps needs more product management…have we gotten closer or do you think there is still a large gap here?
Erol Toker
So the Product Management/RevOps conversation starts with a core assumption, and that is that you are as an Ops team focused on serving customers instead of internal stakeholders (the way siloed sales ops or mops teams did).
A year ago that assumption was more in the sky 'idealistic' thinking, with today's market reality it's definitely now come front and center.
Change was hard, but now it's necessary, so people are approaching that with an open mind.
Now the question is more:
So I think we are in a place where Product Management COULD become a core concept in RevOps, but it's really about how people answer those three questions that will determine the direction.
Austin
Can we get examples of how two different people would answer those first two core questions (one without product management exp, and one who is integrating product management principles):
Which problems do we tackle:
How do we think about tackling them:
Erol Toker
Yeah so the canonical one I use to differentiate old vs. new thinking is this.
Let's say you have a contract process, and it sucks.
So what do you do with that?
99% of people would say: "We need a better CPQ" or "We need follow up automation".
The way we thought of this here @ my company Truly.co was, how does this work elsewhere and how do I think about this from a buyer's perspective, not the seller's perspective.
So we said:
Why are reps doing the customer's checkout? That's weird.
And so then you work backwards to solutions that have nothing to do with CPQ... things like:
Kevin Heraly
For this topic, are we talking about how we can take a product management system and apply it to how we operate/execute on our RevOps mission?
(Agile, sprints, etc?)
Erol Toker
Kevin, product management is simple at its core:
Within those two bullet points, you can have people who are 'gifted' but just like in sales, there are well known techniques that can be taught that make you a lot better. So think about how sales reps are taught to talk about pricing: "Say the price then shut up". That type of thing exists in PM as well.
Austin
Yeah, i love that example - it's a pretty radical take in terms of how much of a reworking this is of the way GTM is set up these days - would love to circle back on it if we have time!
Do you have a Product example of something as clean and clear as that sales advice?
Erol Toker
"Since we've established that this doesn't directly map to {{priority VP made clear}}, do you still think it's worth detouring on this, knowing that {{priority thing}} might not get done?"
or a simpler one
"Do you think {{thing we just discussed}} is more important than {{other thing we're working on}} in terms of {{result that VP is talking about}}?"
Austin
Love those.
Erol Toker
if you want a primer on where my focus is, this post might sum it up
AndrewPaul McIntosh
What do you think are some of the gravest misconceptions people have about Operations and RevOps?
Erol Toker (Truly.co)
Andrew, If you look to the post above, it says it.
I think ops is viewed as "IT" and I believe it should be viewed as "engineering". I wouldn't say it's a misconception that MOST RevOps teams operate but i do think it's a misconception about what it COULD BE.
Liv
Agreed. Over the past quarter, I moved my team to working in Continuous Delivery Lean from Disciplined Agile, and it was rough at times but eventually stakeholders got used to it and started working with us in a different way.
Austin
To piggy back on those answers, Erol, we have a question from David H:
“How do you handle sales stakeholders that waffle back and forth on process every quarter? My lead process has seen significant changes often enough it's difficult to even measure success.
I think having both of those quotes you mentioned as templates in our minds can help - do you have other advice on that front?”
Erol Toker
Yeah, so this is what the course we're running is all about.
Great product management starts with the Job To Be Done.
Your lead process is a 'how', not a 'what'. And likely the reason it's missing is that there is no good 'WHY'.
When it comes to Sales Ops, the WHY is often "help me solve this logistical problem" and those logistics are highly volatile because it's usually some bureaucratic thing that is constantly in flux.
So to get past the 'waffling', Job to Be Done framework tells you 'what am I REALLY solving'. Is it:
Once you know that, it's about figuring out how to take control of the conversation (or just learn to realize it's a lose-lose situation and cover your own a$$).
Where things get bad is when you are listening to what people are saying, being this positive person who wants to make people happy and you see yourself as an enabler of other people, and they don't know what they want and they trample all over you.
That is exactly what bad engineering teams look like and another place where Product Management can help.
Winson Liu
One big "blocker" I see with RevOps becoming adopted truly like PM besides the gap in skillsets that we're trying to bridge is the compensation. I typically describe RevOps to people as the combination of PM, BizOps, and SalesOps.
My question here is do you see any organizations starting to adopt the PM compensation structure for RevOps? It won't draw in that level of talent if PMs are making higher cash and equity comp, so you're essentially relying on PMs to become interested (while forgoing the higher comp) or RevOps people becoming PMs (where RevOps are a lot of systems folks, traditional SalesOps, or consultants).
Erol Toker
Winson, I do see that yes, and i think the start of it is seeing more VP of RevOps roles being posted. When I talk to those people they are typically coming from non-Ops roles - with backgrounds in management consulting for example, or people who led 'growth' teams which look a lot more like product/engineering teams.
So i think it is happening. It's a slow start, but we literally were NOWHERE 18 months ago.
In 2000 engineers got paid very little overall and had no respect. Then the web came out and Google set a precedent, then the labor market got tight and everyone had to follow.
I think that's what we'll see in the next 5 years.
Austin
Great question, Winson.
I’m going to add in a question submitted ahead of time that plays very closely with that (with a focus on large companies). This comes from Al Paz-Yener:
“For a maturing RevOps org at a high growth company, how do you feel about a dedicated program manager to own the project management of all growth initiatives + RevOps roadmap? Or do you think Sales Enablement can / should handle that?”
Erol Toker
Al - drawing a parallel to product/engineering, I think there are many ways to do this and none of them are right. But I will ask, "what does Sales Enablement do exactly again?"
I say that because they have a really tough role -- SDR Success is standardized everywhere as "meetings". For AE's it's "sales". For CSMs it's "renewals".
What is the same thing that's consistent for Enablement, I'm not sure I know. So that's the only thing I'd say it that it's hard to answer your question concretely. Feel free to clarify if you like. BTW, i noticed the name change, congrats on getting married
Phyllis Lee
Hi Erol! What's your POV on the RevOps talent gap?
PM went through something similar in its earlier days and a lot of APM programs were born, starting with Google. There are also other ways to successfully pick up PM skills either as an ex-founder, hackathons or building your own MVP (even easier with no code tools these days).
I find that the RevOps skill gap is more challenging for a few reasons, including it being a newer practice, but also people who want to learn and transition can't exactly learn RevOps in a vacuum the way that someone could just decide to identify a business problem and create a prototype on a weekend. I also don't necessarily see it being a candidate for a rotational APM type training program either.
Erol Toker
Phyllis - of course another problem is, at least PM orgs have real engineers on payroll and in Ops you have 'do it all' admins. If they want to elevate their role, they have to get budget to do the actual execution. And then, you also need them to be good.
The starting point for all this is resources and what I know is that resources follow customer-facing initiatives. If you can map RevOp's activity to customer delight, the story changes completely. And once there's resources, then you have the talent gap.
The problem is people in Ops are still attached to this "I'M A FORCE MULTIPLIER OF OTHER PEOPLE" mantra because that's how it’s worked for 15 years. There is just no future growth there. If you want to be a high ROI individual contributor who can do everything and you like that, then great. But just realize, that's not where things appear to be headed and growth potential will be less.
Austin
I know i have been guilty of that one in the past saying "revenue operations amplifies the results of the teams we work with" and it was always SO hard to get resourced that way.
Phyllis Lee
If I'm understanding, do you think we are too early to even talk about the talent gap? RevOps is still in the stage of being able to justify their value and extra headcount?
Erol Toker
I think there are something like 3% of companies that are in the right frame of mind/leadership to start having a proper conversation about that. What I would look to is a CEO who is really customer obsessed. Like, 'willing to give up revenue' to do right by the customer type situation. There the value is clear and I think you'll see the resources to hire what you need.
Phyllis Lee
Yes, I strongly agree! I think my earliest question about the talent gap was moreso around the idea that RevOps is a role that is difficult to hire for.
I'm seeing a lot of RevOps Managers or more senior roles sit open for a while or the people who fill these roles don't necessarily have a comprehensive enough skillset experience for the role.
A number of RevOps folks really have more of a Sales Ops background and have a gap in connecting everything under the RevOps umbrella even if they are trying to think in that direction due to lack of exposure to Marketing Ops, CS Ops, etc.
And then tying that back to whether we can learn anything from the way that Product Management was able to fill their "talent gap" through APM programs, hackathons, etc.
Erol Toker
I think that says more about the people hiring not knowing what they want than anything else. If I needed product managers for the role, I might just change the job title to Product Manager and then eventually transform it into a RevOps function, or something like that. Talent is there. The problem is more I think describing what you need the role/function to be.
Tyson Hartnett
What's the main difference between Sales Ops and Revenue Ops, or is there a difference?
Erol Toker
Tyson - right so "what is RevOps".
First let's talk WHY nobody can agree to it. We saw this same thing happen with product/engineering when it came to the cloud vs. on-premise.
Is "cloud" about "you no longer need to host the software?" Most people would say yes, but most importantly, all the people who spent their careers building on-premise software. They get to say "yup I'm the master of my domain, I have 20 years experience and I'm going to be a thought leader in this cloud thing".
Then startups like Google come along and say, no, "cloud" is more than that. It means we can build in an agile way, we can beta test products, we can A|B search results. We can completely change HOW we operate. And then these 30-year-olds with 5 years of experience eventually go kick the on-premise guys’ butts.
RevOps is the same. I see all these loud thought leaders with "15 years experience in RevOps" and it's like... RevOps didn't exist until something like 2 years ago!. They're loud because they're prominent and they confuse people.
So that's why nobody can agree on what it is or how it works.
Where I focus on is, is there a fundamental change in dynamics present like the cloud transition?
All the things are screaming that B2B is becoming more like B2C; it's all about the buyer, sales is losing its dominance AND now there is this whole no-code movement that allows Ops people to be builders and innovators. If they can just create value for customers, that is the starting point of the revolution.
So that's my thoughts on it.
Tyson Hartnett
Wow, love it! Thanks for the long overview.
Erol Toker
My opinion on this is just one opinion. I don't know where this all goes. I am 110% convinced that there is a secular shift, but I have no crystal ball.
My view is:
By the way, for what it’s worth, if this is interesting I write about this on Linkedin everyday. You can give me a follow.
Austin
You are definitely one of the people I love to see posts from on LinkedIn.
We have a question from Ryan Waldorf, which I'll quote and then try to zoom out a bit because it seems to be a bit deep in the weeds. You can take it as you see fit, Erol.
“We sell on behalf of many different clients which means we are constantly pushing and pulling data across different platforms. Are there any recommendations on tools, process, templates, ect. for managing the constant sync of data across multiple databases? (We use Salesforce and typically import client data into google sheets before manipulating and mapping to Salesforce).”
Do you have some tactical advice for RevOps folks who might be inheriting something that they don't yet have enough influence to start over from zero (and do it the right way with PM principles in mind)? Where part of their big break might come from taming the beast that they walked into and took over? Or their promotion might rely on getting something under control?
Erol Toker
Everywhere else, they just see RevOps as a synergy play. So you can have the conversation but I think it's just trying to go through the wall head first.
Ryan, this is why Job To Be Done is key.
Most of my success hasn't been in "rebuilds" but rather just "can we throw this in the trash". So the question is how can you lead a conversation that lets you say "why do we do this? Why is that important" etc, without coming across as juvenile, condescending or difficult. Again, kind of like that sales training.
And that's what our course is about. Being able to identify those Jobs To Be Done and then lead people to where you need them to be.
Austin
Erol, What have you learned in the process of creating the Product Management Fundamentals for RevOps course?
Erol Toker
i wouldn't say it's what I've learned and more what other people say they've learned. And the two things they really focus on is me asking questions on really basic things we all do and take for granted. Which opens their minds up to 'hmmmmm, what else is like this'?
The other one is how to talk people through prioritization. Like my backlog philosophy is "if it won't be done in 2 quarters it goes in the bin". And it works because I don't do the thing where I "value all feedback" and "take it down to make people feel heard". I remove myself from the judgement equation and get others to throw it in the bin for me, and then I don't have to deal with it.
H Dan Irwin
Piggybacking off Phyllis Lee's questions earlier, from the perspective of someone early on their journey of working in the RevOps field, what do you think is the best way to keep growing?
Traditionally, it seems like the way has been through a deep knowledge of Salesforce and SalesOps, but is that really the best route to becoming well-rounded and will it continue to be?
Erol Toker
H Dan Irwin, this is subjective to what you think RevOps is.
I think RevOps is about solving customer problems in the buyer's journey. Nobody expects PMs to code, so why expect the RevOps person to build?
We can be resourceful and prototype and get upworkers, I don't know.
Personally I think being 'super deep' in Sales Ops knowledge may make it harder to think outside the box. Going back to that "on-premise" example.
Austin
Erol, that point answers Al Paz-Yener’s question even better as well and it might not require the org to be a large RevOps function. Maybe you hire a Product Manager early out of the gate who's asked to work on RevOps opportunities that have direct customer impact.
Erol Toker
Here's another example about "thinking different".
Cisco made its entire business on building high quality hardware. It charged a massive premium and got all these customers locked in forever.
Then Google comes and says "give me the cheapest storage you got". We'll use software to intelligently back it up in three copies across the world so if storage fails, we don't care and the system can recover.
Cisco cries.
That's how you should think about RevOps.
If you came from a storage background, it probably never would have occurred to you to tackle that problem that way.
Austin
We are at time - I want to leave space for you to sign off with any final thoughts!
Thanks for all the thoughtful answers - I’m happy to get a look towards what the new course will be teaching.
Erol Toker
This was fun, thanks for having me! I have this conversation on Linkedin all the time and would love to continue it there: https://linkedin.com/in/eroltoker
Appreciate the very thoughtful questions.
Austin
Thanks to Erin O’Neill and the RevOps Co-op team!
Erin O'Neill (RevOps Co-op)
Thanks everyone for coming and asking such great questions today and thank you to Austin for MC'ing and Erol for fastest typing speed of the day!
Erol Toker
Thanks, Austin, for all that you do!
Looking for more great content? Check out our blog and join the community.
Interested in Joining our Creator Guild? Sign up here to start contributing!
.png)
