As a technical founder / product person in this exact position, I think one of the biggest takeaways from this excellent article and the many others like it is the distinction between a customer and a partner. At enterprise-scale, all deals become partnerships, essentially, and getting used to thinking "how can I help these people?" instead of "how can I sell to these people?" was big eye-opener.
This is a great article and from experience the model is solid. It made me think it would be pretty easy to put together some sort of enterprise SaaS selling "Masters" course like we see come up so often for data science and the like.
As a product person in the enterprise space, I think there's a lot of good things in this article. BUT, there's a couple of things that I think reflect Steven's background at Microsoft and are common assumptions in the Enterprise space that no longer hold universally true.
- There's a lot of talk about "IT" as a group that you sell to, which by and large only still exists at the highest end of the market, and even then largely as a group whose buy-in you have to get past in order to complete the deal. Many technologies these days are sold directly to the LoB, and IT's only involvement is a security audit, data recovery strategy, and integrating the new app into SSO.
- The downside of this is that many, certainly not all, organizations are a lot less mature than they used to be when it comes to rolling out technology. After all, if all you have to do is log into a web portal and start doing things, what prep do you need? Consequently, your implementations will be a lot more successful if you can show up and tell prospects how to roll out your software, or migrate away from a competitor
- I find that a lot of these organizations are less mature when it comes to understanding "roadmap vision" - they're a lot more aligned to, "What can I do now?" and "What will I be able to do in six months?". There's nothing wrong with that, but selling vision that might represent an aspirational dream for three years out can conflict with the short-term vision of the stakeholder
In general, I think the disconnect comes from the fact that IT in a lot of organizations grew to a sufficient size that the justification for (some of) their existence was implementing and managing the implementation of enterprise software. To do this they built processes and procedures that mitigated risk, helped them plan, migrate effectively, train people, etc.
Those same processes also created jobs where the sole purpose was to justify their existence and increased overall complexity.
Do you write anywhere about this stuff? If not, I would love to read it if you did :-) In my minor experience with selling to enterprises, the three points you raise hit home.
I have a terrible, unmaintained blog at http://mzi.to that I keep promising to myself I will do something with. My bio isn't even accurate there at the moment.
So if I do start writing about it, it'll be there.
> Many technologies these days are sold directly to the LoB, and IT's only involvement is a security audit, data recovery strategy, and integrating the new app into SSO.
Don't forget "trying to deal with the fallout a businessperson buys something without consulting IT". Classic facepalm situation.
It's a good idea to make sure that all the stakeholders (including IT) are involved at an early stage, to make sure that any obstacles to deployment can be avoided (or, at least, spotted in advance). An engaged, friendly IT department can help grease the skids for an enterprise sale; a hostile one can scupper it.
> ..these organizations are less mature when it comes to understanding "roadmap vision" - they're a lot more aligned to, "What can I do now?" and "What will I be able to do in six months?"
I think this is partly down to a certain amount of skepticism regarding salespeople's promises.
> Those same processes also created jobs where the sole purpose was to justify their existence and increased overall complexity.
I think that's a little bit harsh (but not necessarily untrue!). Any organisation that grows above a certain size is going to have bureaucracy and red tape. For organisations of a certain age, the legacy IT infrastructure (and particulrly the extent to which business processes rely on it) presents a challenge to change (including deploying new products).
> It's a good idea to make sure that all the stakeholders (including IT) are involved at an early stage, to make sure that any obstacles to deployment can be avoided (or, at least, spotted in advance). An engaged, friendly IT department can help grease the skids for an enterprise sale; a hostile one can scupper it.
It's true, but I think it depends somewhat on the product and space, right? "Enterprise software" can encompass a wide variety of tech, from SAP on one end, to database and app platforms in another direction, to marketing tech in a third, and so on.
If you're running on-premise, IT has to be involved. If you're touching IT-provided services like email, file sharing, etc, IT has to be involved. But if you're not touching IT centrally, they're often not involved, beyond the validation points about security, etc. In the space in which I currently work, for example, IT is almost never involved. In a previous life selling application and infrastructure management products, IT was almost always the direct customer/implementor. There's a huge spread, so I think everyone has to be clear about which scenarios we're talking about.
> I think this is partly down to a certain amount of skepticism regarding salespeople's promises.
Sometimes I think it's skepticism, I think it's also that IT orgs tend to have a longer history with the concept of "partnering" with a vendor, which often involves a combination of skepticism, optimism, professional services, and a willingness to settle. When you deal with a different business unit that maybe has less experience with building and implementing Product, sometimes they don't see/embrace that approach.
> think that's a little bit harsh (but not necessarily untrue!). Any organisation that grows above a certain size is going to have bureaucracy and red tape. For organisations of a certain age, the legacy IT infrastructure
It was certainly more terse than I intended, I was running out of time before a meeting started.
> It's true, but I think it depends somewhat on the product and space, right?
I would (and my advice to anyone else would be to) reach out to the potential client's IT department as a matter of course, whether or not they're likely to be involved.
You don't know what you don't know, and establishing a friendly/collaborative relationship with them may help your case. It's all part of building a relationship (see the relevant paragraph in the article).
> I would (and my advice to anyone else would be to) reach out to the potential client's IT department as a matter of course, whether or not they're likely to be involved.
Ehhhh - I would maybe rephrase that to be, "Talk with your business sponsor about whether it makes sense to have IT involved - are there roadblocks they are likely ot throw up that you should get ahead of"
Because as a general rule of enterprise sales, I would say, "The more people that are involved in your deal, the more people that can screw it up. Only involve the right amount of stakeholders to insure the deal gets done"
Nothing is worse than watching a deal go sideways because a rep went wide and deep into an organization and suddenly you're trying to make everyone happy.
It is sometimes better to keep a deal size smaller and more focused to insure it closes sooner, and then you can deal with upselling other orgs or getting IT's buy-in on a broader implementation once it's up and running and working.
Great points. I am in exactly the same space (enterprise/B2B) and your last two points about IT resonated with me.
F500/1000 have IT teams that only specialize in managing vendors and ensuring compliance and governance.
IMHO, the lack of roadmap thinking comes down to IT not being able to translate the Business roadmap into technology terms. Too many CIOs still insist on seeing a product roadmap without first talking about business goals.
> Too many CIOs still insist on seeing a product roadmap without first talking about business goals.
Maybe because they have had too many experiences in which they articulated the business goals first, and then the product roadmap they hear about is magically a perfect match. Then 6 months into the deal they find out that--whoops--what they heard from the salesperson is not the real, or really achievable, product roadmap.
Yes, enterprise salespeople do not always tell the truth. It's rarely outright lying; usually more of an issue of selective emphasis, or making what they think are reasonable extrapolations from what they know.
That is correct. A product IS a capability to the user-buyer. What's more, certain types of products (CRM, sales, marketing, supply chain) are usually bought and implemented during certain business events. For e.g.: a company hires 100 new sales reps and now needs the capability to manage this new sales pipeline. Time for a vendor to pitch a CRM subscription!
I like the article BUT it doesn't articulate one important and pragmatic variable: price and how to move from your product price perspective to the enterprise price one. The same product you sell by unit for $ X can be sold for more than $ 20 * X (including support and etceteras) in the enterprise.
That is not so obvious for a product oriented person unexperienced in enterprise selling. For example, you should now that your one-click installation and easy configuration demands a lot of resources on a company.
Another variable not articulated is your cost of selling to these enterprises: salesman + pre-sales engineer + engineers working on the PoC, etc.
Glad to see articles like this here. Trying to build a startup in the enterprise space is really difficult, because the customer/sales cycle is so difficult. I'm coming at it from the perspective of an enterprise engineer turned founder, someone who used enterprise products but neither sold them nor made the final decision. I have a lot to learn!
Great discussion. I totally agree with @mattzito about the opportunity to sell at the business unit level. At the same time the points about getting IT buy-in remain critical. I've watched too many SaaS uses shut down or "banned" under the guise of security/compliance/etc for failing to engage IT.
The reality is that IT has always pushed to be more than the control point or network. Different organizations have different ways to execute on the use of ITs skills in business units. The complexities of large organizations (budgets, accountability) make this dynamic very localized to a company and why the role of the account manager is so critical.
My own experience at Microsoft was going from a consumer company to a business unit focused sales effort to a top down IT/C-suite sale. Office was a classic bottom up sale at the time which morphed into a strategic sale over the course of a decade. Many people forget that in the early 1990's Microsoft was always a big question mark in the world of the enterprise.
20 comments
[ 3.3 ms ] story [ 47.1 ms ] threadFor our key customers, everyone on the team knew as much about their product road map as our own.
- There's a lot of talk about "IT" as a group that you sell to, which by and large only still exists at the highest end of the market, and even then largely as a group whose buy-in you have to get past in order to complete the deal. Many technologies these days are sold directly to the LoB, and IT's only involvement is a security audit, data recovery strategy, and integrating the new app into SSO.
- The downside of this is that many, certainly not all, organizations are a lot less mature than they used to be when it comes to rolling out technology. After all, if all you have to do is log into a web portal and start doing things, what prep do you need? Consequently, your implementations will be a lot more successful if you can show up and tell prospects how to roll out your software, or migrate away from a competitor
- I find that a lot of these organizations are less mature when it comes to understanding "roadmap vision" - they're a lot more aligned to, "What can I do now?" and "What will I be able to do in six months?". There's nothing wrong with that, but selling vision that might represent an aspirational dream for three years out can conflict with the short-term vision of the stakeholder
In general, I think the disconnect comes from the fact that IT in a lot of organizations grew to a sufficient size that the justification for (some of) their existence was implementing and managing the implementation of enterprise software. To do this they built processes and procedures that mitigated risk, helped them plan, migrate effectively, train people, etc.
Those same processes also created jobs where the sole purpose was to justify their existence and increased overall complexity.
So if I do start writing about it, it'll be there.
Don't forget "trying to deal with the fallout a businessperson buys something without consulting IT". Classic facepalm situation.
It's a good idea to make sure that all the stakeholders (including IT) are involved at an early stage, to make sure that any obstacles to deployment can be avoided (or, at least, spotted in advance). An engaged, friendly IT department can help grease the skids for an enterprise sale; a hostile one can scupper it.
> ..these organizations are less mature when it comes to understanding "roadmap vision" - they're a lot more aligned to, "What can I do now?" and "What will I be able to do in six months?"
I think this is partly down to a certain amount of skepticism regarding salespeople's promises.
> Those same processes also created jobs where the sole purpose was to justify their existence and increased overall complexity.
I think that's a little bit harsh (but not necessarily untrue!). Any organisation that grows above a certain size is going to have bureaucracy and red tape. For organisations of a certain age, the legacy IT infrastructure (and particulrly the extent to which business processes rely on it) presents a challenge to change (including deploying new products).
It's true, but I think it depends somewhat on the product and space, right? "Enterprise software" can encompass a wide variety of tech, from SAP on one end, to database and app platforms in another direction, to marketing tech in a third, and so on.
If you're running on-premise, IT has to be involved. If you're touching IT-provided services like email, file sharing, etc, IT has to be involved. But if you're not touching IT centrally, they're often not involved, beyond the validation points about security, etc. In the space in which I currently work, for example, IT is almost never involved. In a previous life selling application and infrastructure management products, IT was almost always the direct customer/implementor. There's a huge spread, so I think everyone has to be clear about which scenarios we're talking about.
> I think this is partly down to a certain amount of skepticism regarding salespeople's promises.
Sometimes I think it's skepticism, I think it's also that IT orgs tend to have a longer history with the concept of "partnering" with a vendor, which often involves a combination of skepticism, optimism, professional services, and a willingness to settle. When you deal with a different business unit that maybe has less experience with building and implementing Product, sometimes they don't see/embrace that approach.
> think that's a little bit harsh (but not necessarily untrue!). Any organisation that grows above a certain size is going to have bureaucracy and red tape. For organisations of a certain age, the legacy IT infrastructure
It was certainly more terse than I intended, I was running out of time before a meeting started.
I would (and my advice to anyone else would be to) reach out to the potential client's IT department as a matter of course, whether or not they're likely to be involved.
You don't know what you don't know, and establishing a friendly/collaborative relationship with them may help your case. It's all part of building a relationship (see the relevant paragraph in the article).
Ehhhh - I would maybe rephrase that to be, "Talk with your business sponsor about whether it makes sense to have IT involved - are there roadblocks they are likely ot throw up that you should get ahead of"
Because as a general rule of enterprise sales, I would say, "The more people that are involved in your deal, the more people that can screw it up. Only involve the right amount of stakeholders to insure the deal gets done"
Nothing is worse than watching a deal go sideways because a rep went wide and deep into an organization and suddenly you're trying to make everyone happy.
It is sometimes better to keep a deal size smaller and more focused to insure it closes sooner, and then you can deal with upselling other orgs or getting IT's buy-in on a broader implementation once it's up and running and working.
F500/1000 have IT teams that only specialize in managing vendors and ensuring compliance and governance.
IMHO, the lack of roadmap thinking comes down to IT not being able to translate the Business roadmap into technology terms. Too many CIOs still insist on seeing a product roadmap without first talking about business goals.
Maybe because they have had too many experiences in which they articulated the business goals first, and then the product roadmap they hear about is magically a perfect match. Then 6 months into the deal they find out that--whoops--what they heard from the salesperson is not the real, or really achievable, product roadmap.
Yes, enterprise salespeople do not always tell the truth. It's rarely outright lying; usually more of an issue of selective emphasis, or making what they think are reasonable extrapolations from what they know.
That is not so obvious for a product oriented person unexperienced in enterprise selling. For example, you should now that your one-click installation and easy configuration demands a lot of resources on a company.
Another variable not articulated is your cost of selling to these enterprises: salesman + pre-sales engineer + engineers working on the PoC, etc.
The reality is that IT has always pushed to be more than the control point or network. Different organizations have different ways to execute on the use of ITs skills in business units. The complexities of large organizations (budgets, accountability) make this dynamic very localized to a company and why the role of the account manager is so critical.
My own experience at Microsoft was going from a consumer company to a business unit focused sales effort to a top down IT/C-suite sale. Office was a classic bottom up sale at the time which morphed into a strategic sale over the course of a decade. Many people forget that in the early 1990's Microsoft was always a big question mark in the world of the enterprise.
Regarding pricing, here's a post I did a while back on SaaS pricing. http://techcrunch.com/2014/05/16/the-price-is-right-for-earl...
--Steven