"My startup has grown and now has gatekeepers, how do I use them effectively?"
You mention that this is a playbook on making enterprise sales. I think that's slightly different, ie:
"My startup is selling to an enterprise that has gatekeepers, how do I work with them?"
Within your own organisation you have a relationship with the gatekeepers, but as an external startup / salesperson you don't. Do you have any extra tips or thoughts on that?
Does it mean you must simultaneously sell to both the gatekeepers and non-gatekeepers?
Or sell to the non-gatekeepers and show them how to cross-sell to the gatekeepers? Can they do that bottom-up or across their business, or does that need to come top-down within their business?
Teaching non-gatekeepers how to approach them is often a critical component - especially in highly-regulated markets like education, healthcare, finance.
While Eric's lense is on a startup, the strategies he recommends are great suggestions for customer executives.
For example, if you hear "we've got a budget cap or we have to put out a bid." A fairly standard policy for most organizations with some government funding.
What you might not know is that all of these policies have a "sole-sourcing" exception. If your champion will submit a statement on why you are the only vendor capable of fulfilling their specific requirements, the bid clause is waived.
I learned that by taking the initiative to contact the CFOs of organizations I was pursuing and letting them know I wanted to better understand the requirements/regulations their business units needed to follow.
I was also able to help a few internal champions summon the courage to ask their contacts within procurement by sharing "this is what we've seen at other orgs we've worked with, perhaps your policy is similar?"
In the end, helping champions reduce their fear of an internal regulatory smack down is often the key to creating permission for innovation. To some degree, most "back office" functions see themselves as a service unit, even if their business units don't.
We're making enterprise sales to mining companies, and while we see interest from the front-line users, they can sometimes struggle to get wider support within their company. In particular finance to get the budget to run a small experimental project without clear ROI, and IT to get access to internal data sources on a trial basis. And these non-gatekeepers are getting that response for their own internal initiatives as well, not just what we are trying to sell.
So sounds like we should make a two-pronged approach:
1) Do some customer dev type work with the gatekeepers, to find out what they want to see
2) Share what we learn from 1) with the non-gatekeepers, to help them get support internally
4 comments
[ 5.0 ms ] story [ 17.8 ms ] threadEric shows how to redefine the context around their work to make the entire organization more adaptive.
This is the most significant thing he's ever written.
If you sell to enterprise customers, this is a playbook on how to win deals faster and reduce the cost of Customer Success.
If you care about changing society's public institutions for the better, this is where your bright ideas will live or die.
"My startup has grown and now has gatekeepers, how do I use them effectively?"
You mention that this is a playbook on making enterprise sales. I think that's slightly different, ie:
"My startup is selling to an enterprise that has gatekeepers, how do I work with them?"
Within your own organisation you have a relationship with the gatekeepers, but as an external startup / salesperson you don't. Do you have any extra tips or thoughts on that?
Does it mean you must simultaneously sell to both the gatekeepers and non-gatekeepers?
Or sell to the non-gatekeepers and show them how to cross-sell to the gatekeepers? Can they do that bottom-up or across their business, or does that need to come top-down within their business?
Thanks.
While Eric's lense is on a startup, the strategies he recommends are great suggestions for customer executives.
For example, if you hear "we've got a budget cap or we have to put out a bid." A fairly standard policy for most organizations with some government funding.
What you might not know is that all of these policies have a "sole-sourcing" exception. If your champion will submit a statement on why you are the only vendor capable of fulfilling their specific requirements, the bid clause is waived.
I learned that by taking the initiative to contact the CFOs of organizations I was pursuing and letting them know I wanted to better understand the requirements/regulations their business units needed to follow.
I was also able to help a few internal champions summon the courage to ask their contacts within procurement by sharing "this is what we've seen at other orgs we've worked with, perhaps your policy is similar?"
In the end, helping champions reduce their fear of an internal regulatory smack down is often the key to creating permission for innovation. To some degree, most "back office" functions see themselves as a service unit, even if their business units don't.
Happy to answer any other questions on this!
We're making enterprise sales to mining companies, and while we see interest from the front-line users, they can sometimes struggle to get wider support within their company. In particular finance to get the budget to run a small experimental project without clear ROI, and IT to get access to internal data sources on a trial basis. And these non-gatekeepers are getting that response for their own internal initiatives as well, not just what we are trying to sell.
So sounds like we should make a two-pronged approach:
1) Do some customer dev type work with the gatekeepers, to find out what they want to see
2) Share what we learn from 1) with the non-gatekeepers, to help them get support internally
Thanks again!