But that’s not the worst of it. The reality of some young SaaS companies is that many of the “customers” they sell fail with the product  and cancel or don’t “convert” within months of the initial sale. I’ve seen rates of 40% of new clients churning in the next quarter.

Let me be clear – this is failure, on a large scale. If you are actually “data driven”, you should be horrified by this development. Yet all around me I hear glib hustlers talking about how we’ve created a new sales and marketing model in the SaaS world. It’s time to wake up – the “best practices” on display at many young SaaS companies are not best practices at all. They don’t work well, are very expensive and in many cases hide real problems in strategy that need to be dealt with head-on. This is only possible via VC funded unreality, not in any business that is actually trying to build a profitable operation.

So, what is at the core of this problem? “Sales specialization” is the culprit. Fundamentally, what sales specialization does is allow you to be far too reductive about what good enterprise sales actually looks like. Incentives are created to generate numbers – but sales is not fundamentally a “numbers game”. You don’t manage a territory using conversion chains, you do so by building relationships. Via engagement. By  being seen as a trusted advisor, an ally and someone who “gets it”.

Don’t listen to me, go out and do your own research. What do customers/buyers have to say about dealing with your frenetic, amateurish “BDRs”? Let’s just take this very front edge of the funnel. Why on earth does it make sense to have the first contact with your company be the least skilled and knowledgeable person they could speak with?

Churn is often looked at as an isolated problem, and many times is attributed to product experiences. But in fact, it’s very likely that what’s happening is that many SaaS companies are pushing way too hard and reduce the threshold to a “sale” so low as to make it not really a sale at all.

So, the first thing you have to get is that the buyer is setting “the rules of the game”. In game theory parlance, that means they set out how many alternatives they may select from and what the next possible move is in the game – accept, counter, withdraw. Your sales stages and qualifying have no effect on how the client sees the game. Are you using the basic characteristics of this game to your advantage?

It’s axiomatic that by being on offense, by taking initiative, one can control an opponent by forcing them to take defensive actions. Being on offense is also a way of engaging a client, one of the “rules of the game” for me is to always be on offense. If I’m reacting instead of affecting, I’m usually losing. Example: The client insists I do a free pilot. I ask, “Who will be assigned to it?” And we find out this person’s time is already 80% committed to other work. I then ask, “What are we trying to prove?” And we discuss say a performance concern. Then I ask, “Will a pilot even prove that?” – which it usually doesn’t. At each step of the way I’m challenging their assumptions and getting at what matters most. If I’m not provocative, I never get to have that level of interchange and I’m not changing the client’s thinking, and if I’m not affecting the client’s thinking, I’m not winning.

I want you to get something here. You only affect how a client behaves and acts when you don’t comply with their framing of the game. If the client buys your re-framing from the outset, win rates go up dramatically. Put more bluntly, first you win an argument and then you win a sale – changing the narrative changes the rules of the game.

The game concept goes even deeper for the B2B sales rep. In fact, the game you are playing isn’t about winning any given deal, it’s about maximizing your possibility of winning more deals than you “should”. Example, if you are in deals where there are 3 other real competitors/substitutes/alternates and all other things were equal and it was a random draw, you should win 1 out of every 4 deals. If you adopt the above “disruptor” strategy in some percentage of the opps you work, would you win more than 1 in 4? It might not work out each time, but if it works half the time you are doubling your effectiveness versus a random draw. Winning 50% of opportunities you compete on is a great close rate – this is how a “game theory” point of view on sales helps you become improve win rates.

Focus on maximizing your probability of winning by understanding the “game” that you are in as a B2B sales rep rather than your “process”.

1. Accuracy counts in B2B – The best trick I’ve learned in the past couple of years is to use a tool like Kickbox.io to verify email addresses. While it only focuses on email addresses, this is the crucial bit to get right. Most lists, whether purchased or hand crafted have far too many bad email addresses. Also realize that if you are emailing from your own domain that too many bounces could get you on spam and blacklists

2. Purpose of the list – Are you a startup going to market for the first time? Go wide and shallow, meaning more companies, fewer contacts as you are looking for heat. But if you are an account exec, building a territory list? Go deep and get lots of extra data about contacts/companies and as many contacts as possible at each company.

3. Segmentation – Find subsegments that work for you. If you are selling CRM, don’t just pull VPs of sales across 30 industries, rather go after segments you believe there is opportunity as this is the foundation of experimental sales/marketing.

4. Make Sure Sales and Marketing are working off the same lists – If you have separate campaign management tools from your CRM, stop it! Sales needs to know what’s been done and marketing can use info from sales to target.

5. Buy versus build – Either can be productive but be careful with purchased lists, they always have lots of bad data and you’ll have to scrub them yourself. Remember, this isn’t consumer marketing, you don’t have 1 million contacts to work against and you can’t afford to have 30% bad information.

The list is the axis about which your campaigns revolve, so spend the time getting them right and all your sales and marketing efforts will benefit from it.

Enterprise Sales is Dead – Long Live Enterprise Sales! from Glenn Donovan on Vimeo.

Why Sales Coaching from Glenn Donovan on Vimeo.

My POV on why sales coaching is very helpful for enterprise tech entrepreneurs.

Fill out and submit the form below to get a FREE ONE HOUR SALES COACHING SESSION!

[contact-form][contact-field label=’Name’ type=’name’ required=’1’/][contact-field label=’Email’ type=’email’ required=’1’/][contact-field label=’Website’ type=’url’/][contact-field label=’Comment’ type=’textarea’ required=’1’/][/contact-form]

However, while discussing this with my friend, it became clear that one has to understand the history of integration servers, EAI, SOA, ESB, and WS standards to put into context the lessons that have been learned along the way regarding actual IT agility. But let me qualify myself before we jump in. My POV is based on being an enterprise tech sales rep who sold low latency middleware, and standards based middleware, EAI, a SOA grid-messaging bus as well as applications like CRM, BPM and firmwide market/credit risk management which have massive system integration requirements. While I did some university and goofing off coding in my life (did some small biz database consulting for a while), I’m not an architect, coder or even a systems analyst, but I saw up close and personal why these technologies were purchased, how they evolved over time, what clients got out of them and how our plans and aspirations played out. So, I’m trying to put together a narrative here that connects the dots for people other than middleware developers and CTO/Architect types. Okay, that said, buckle up.

The Terrain
Let’s define some terms – middleware is a generic a term – I’m using it to refer to message buses/ESBs and integration servers (EAI). The history of those domains led us to our current state and helps make clear where we need to go next, and why the old way of doing systems integration and building SOA is falling away in favor of RESTful web services micro-services based design in general.

Integration servers – Whether from IBM or challengers in those days like SeeBeyond (who I worked for), the point of an integration server was to stop the practice of hand writing code for each system/project to access data/systems. These were often referred to as “point to point” integrations in those days, and when building complex systems in large enterprises before integration servers, the data flows between systems often looked like a plate of spaghetti. One enterprise market risk project I worked on at Bank of New York always comes to mind when I think of this. The data flows of over 100 integration points from which the risk system consumed data had been laid out in one diagram and we actually laminated it on 11×17 paper, making a sort of placemat out of it. It became symbolic of this type of problem for me. It looked kind of like this:

(Image attribution to John Schmidt, recognized authority in the integration governance field and author of books on Integration Competency Centre and Lean Integration)

So, along came the “integration server”. The purpose was to provide a common interface and tools to use to connect systems without writing code from scratch so integrations between systems would be easy to build and maintain, while also being secure and performing well. Another major motivation was to loosely couple target systems and data consuming systems to isolate both from changes in the underlying code in either. The resulting service was available essentially as an API, they were proprietary systems, and in a sense they were ultimately black boxes from which you consumed or contributed data. They did the transforms, managed traffic, loaded the data efficiently etc. Of course, there were also those dedicated to bulk/batch data as well such as Informatica and later on Ab Initio, but it’s funny, these two very related worlds never came together into a unified offering successfully.

This approach didn’t change how software systems were designed, developed or deployed in a radical way though. Rather, the point was to isolate integration requirements and do them better via a dedicated server and toolkit. This approach delivered a lot of value to enterprises in terms of building robust systems integrations, and also helped large firms adopt packaged software with a lot less code writing, but in the end it offered only marginal improvements in development efficiency, while injecting yet another system dependency (new tool, specialized staff, ongoing operations costs) into the “stack”. Sure you could build competency centers and “factories” but to this day, such approaches end up creating more bureaucracy, more dependencies and complexity while adding less and less value compared to what a developer can build him/herself with RESTful services/micro-services, and most things one wants to integrate with today already have well defined APIs so it’s often much easier to connect and share data anyway. Innovative ideas like “eventually consistent data” and the incredible cost advantages and computing advantages of open source versus proprietary technologies, in addition to public IaaS welcoming such computing workloads at the container level, well let’s just say there is much more changing than just integration. Smart people I talk to tell me that using an ESB as the backbone of a micro-services based system is contrary to the architecture.

Messaging bus/ESB – This is a system for managing messaging traffic on a general purpose bus from which a developer can publish, subscribe, broadcast and multi-cast messages from target and source services/systems. This platform predates the web, fyi, and was present in the late ‘80s and ‘90s in specialized high speed messaging systems for trading floors, as well as in manufacturing and other industrial settings where low latency was crucial and huge traffic spikes were the norm. Tibco’s early success in trading rooms was due to the fact they provided a services based architecture for consuming market data which scaled and also allowed them to build systems using services/message bus design. These allowed such systems to approach the near-real time requirements of such environments, but they were proprietary, hugely expensive and not at all applicable for general purpose computing. However, using a service and bus architecture with pub/sub, broadcast, multi-point and point to point communications available as services for developers was terrific for isolating apps from data dependencies and dealing with the traffic spikes of such data.

Over time, it became clear that building systems out of services had much general promise (inheriting basic ideas from object oriented design actually), and that’s when the idea of Web Services began to emerge. Entire standards bodies were formed and many open source and other projects spun off to support the standards based approach to web services system design and deployment. Service Oriented Architectures became all the rage – I worked on one project for Travelers Insurance while at SeeBeyond where we exposed many of their mainframe applications as web services. This approach was supposed to unleash agility in IT development.

But along the way, a problem became obvious. The cost, expertise, complexity and time involved in building such elegantly designed and governed systems frameworks ran counter to building systems fast. A good developer could get something done that worked and was high quality without resorting to using all those WS standardized services and conforming to its structure. Central problems included using XML to represent data because the processing power necessary for transforming these structures was always way too expensive for the payoff. SOAP was also a highly specialized protocol, injecting yet another layer of systems/knowledge/dependency/complexity to building systems with a high degree of integration.

The entire WS framework was too formalized, so enterprising developers said, ‘how could I use a service based architecture to my advantage when building a system without relying on all of that nonsense?’ This where RESTful web services come in, and then JSON, which changes everything. Suddenly, new, complex and sophisticated web services began to be callable just by HTTP. Creating and using such services became trivially easy in comparison to the old way. Performance and security could be managed in other ways. What was lost was the idea of operating with “open systems” standards from a systems design standpoint, but it turns out that it was less valuable in practice given all the overhead.

The IT View
IT leadership already suspects that the messaging bus frameworks did not give them the most important benefit they were seeking in the first place – agility – yet they have all this messaging infrastructure and all these incredibly well behaved web services running. In a way, you can see this all as part of how IT organizations are learning what real agility looks like when using services based architectures. I think many are ready to dump all that highly complex and expensive overhead which came along with messaging buses when an enterprise class platform comes along that enables them to do so.

But IT still loves integration servers. I think they are eager for a legit, hybrid-cloud based integration server (iPaaS) that gives them an easy way to build and maintain interfaces for various projects at lower cost than on ESB-based solutions while running in the cloud and on-prem. It will need to provide the benefits of a service based architecture – contractual level relationships – without the complexity/overhead of messaging buses. It needs to leverage the flexibility of JSON while providing a meta-data level control over the services, along with a comprehensive operational governance and management framework. It also needs to scale massively, and be distributed in design in order to even be considered for this central role in enterprise systems.

The Real Driver of the Cloud
What gets lost sometimes with all of our technical focus is that economics are what is mostly driving cloud adoption. With the massive cost differentials opening up in public computing versus on-prem or even outsourced data centers due to the tens of billions IBM, Google, MSFT, AWS and others are pouring into their services, the public cloud will become the platform of choice for all computing going forward. All that’s up for debate inside any good IT organization is how long this transition is going to take.

Many large IT organizations clearly see the tipping point cost-wise is at hand already wrt IaaS and PaaS. This has happened in lots of cloud markets already – Salesforce didn’t really crush Siebel until its annual subscription fees were less than Siebel’s on prem maintenance fees. Remember, there was no functional advantage in Salesforce over Siebel. Hint: Since the economics are the driver, it’s not about having the most elegant solution rather than being able to actually do the job somehow, even if not pretty or involving tradeoffs.

Deeper hint: Give a good systems engineer a choice between navigating a nest of tools and standards and services, along with all the performance penalties, overhead, functional compromises and dependencies they bring along, versus having to write a bit more code and being mindful of systems management, and she/he will choose the latter every time. Another way of saying this is that complexity and abstraction are very expensive when building systems and the benefits have to be really large for the tradeoff to make sense, and I don’t believe that in the end, ESBs and WS standards for the backbone of SOA ever paid off in the way it needed to. And never will. The industry paid a lot to learn that lesson, yet it seems that there is a big reluctance to discuss this openly. The lesson? Simplicity = IT Agility.

The most important question is what core enterprise workloads can move to the public cloud feasibly, and that is still a work in progress. Platforms like Apprenda and other hybrid cloud solutions are crucial part of that mix as one has to be able to assign data and process to appropriate resources from a security/privacy and performance/cost POV. A future single “cloud” app built by an enterprise may have some of its data in servers on Azure in three different data centers to manage data residency, other data in on prem data stores, be accessing data from SaaS apps, and accessingstill other data in super cheap simple data stores on AWS. Essentially, this is a “policy” issue and I’d say that if a hybrid iPaaS like Snaplogic can fit into those policies, and behave well with them and facilitate connecting these systems, it has a great shot at being a central part of the great rebuild of core IT systems we are going to watch happen over the next 10 years. This is because it provides the enterprise with what it needs, an integration server while leveraging RESTful services, micro-services based architectures and JSON without an ESB.

This is all coming together now, so you will see growing interest in throwing out the old integration server/message bus architectures in organizations focused on transformation and agility as core values. I think the leadership of most IT organizations are ready to leave the old WS standards stuff behind, along with bus/message/service architectures, but their own technical organizations are still built around them so this will take some time. It’s also true that message buses will not be eliminated entirely, as there is a place for messaging services in systems development – just not as the glue for SOA. And of course, low latency buses will still apply to building near-real time apps in say engineering settings or on trading floors, but using message buses as a general purpose design pattern will just fade from view.

The bottom line is that IT leaders are just as frustrated they didn’t get the agility out of building systems using messaging bus/SOA patterns as business sponsors are about the costs and latency of these systems. All the constituencies are eager for the next paradigm and now is the time to engage in dialog about this new vision. To my thinking, this is one of the last crucial parts of IT infrastructure which needs to be modernized and cloud enabled to move the enterprise computing workloads to the cloud, and I think Snaplogic has a great shot at helping enterprises realize this vision.

While the term was initially used to describe the lamentable conditions of British common grazing fields, does it not also describe what is happening to the inboxes of decision-makers in enterprises today? And of course, with response rates of .1%, ( http://www.marketingcharts.com/traditional/direct-media-response-rate-cpa-and-roi-benchmarks-53645/ ) it’s easy to see how this entire approach is failing miserably for marketers as well.

Understanding why is easy – it’s about incentives. The marginal cost (the cost of sending the next email) is next to nothing for email marketing, so why not do an “8×3” campaign that sends 8 emails to a ‘prospect’? Sure, there are diminishing returns on each email sent but it does drive up response rates and hey, you are compensated on getting results so that’s just the reality of our world today, right? The fact that it’s just getting harder and harder to get results just means you need a larger list, right?

Wrong. As I described, it’s a race to the bottom (B2B Demand Gen – A Race to the Bottom?), and it’s also true that the limited digital behavior of our email campaign targets is less valuable than you think. An open doesn’t indicate interest in your product or service, it just means the subject line hit home. Even 3 opens means very little. A click through to a link – often it’s just idle curiosity. As a B2B marketing gadfly myself, I can’t tell you how many lists I get on where an “SDR” calls me or emails me multiple times as a follow up – I’m never a prospect for any of them. A simple web search would tell them that.

Structured Web research

It’s also going to keep getting worse – see the attached chart (sorry I couldn’t find a more recent one but the trend is clear). A CEO/Founder of a SaaS company that I know recently told me that it takes a list of 2000 companies to get one customer from a demand generation POV. He is a brilliant, hardworking guy and an engineer by training. I responded by noting that any process which yielded so little must be broken, but he just moved along. It was 1000 3 years ago. It will likely be 4000 in another 3 years.

My point? Rethink “demand generation” utterly.

So much “demand generation” reduces our interactions to an ‘offer-response’ dyad in which clever marketers use techniques to drive opens and clicks at the cost of richness and real value. I’m told constantly that emails much be short, that content must be punchy and heaven forbid you don’t title a post or email with wording that isn’t optimized. If that’s the approach, why don’t we just start using titles and subject lines like “Add more length and girth to your CRM” or “Get the hottest girls by using our PaaS”. Hey, you’ll get a lot of “opens” right? That’s the goal isn’t it?

As I write this, I’m thinking, “I’d better go find some data to stick in here”. It’s at this point in a “good” blog post that I’m supposed to insert a good graphic, right? Sure, I’ll do so but if you think that’s all it takes for content marketing success, you are kidding yourself.

Digital offers the possibility of engaging your prospect accounts in thoughtful and deep ways with your thought leadership and value proposition. Yet it seems that most of B2B marketing is about opens and clicks rather than the client’s issues, aspirations and problems. And of course, buyers are simply responding less and less to this superficial approach to engagement.
Email to prospects is now getting a .1% response rate according the Direct Marketing Association. Is this what your marketing team calls success? If so, perhaps it’s time to rethink B2B Digital.

Yet all around me I see various people hawking their “formula for success” for startups. Some have small amounts of data that might indicate they are onto something – at best – while others seem to have taken what worked at their first and last startup, and now project it as the “path to success”. I’m not hostile to any of it, and try to keep up as I’m open to anything that works. But over time, I can’t help but become a bit skeptical about many of the claims made. Fyi, I’m not going to name names here as I’m not trying to drum up a flame war, rather, I just want to share a couple of thoughts with you all.

Every successful startup that I’ve been with had one thing in common: A coherent and valid narrative about why their product/service was groundbreaking or game-changing or a big functional improvement or a significantly better cost/value eversus the alternatives their target market had available to them. They knew when “they were in the right meeting” in the sense that they had a keen understanding of who they were helping out with their technology. GitHub? They were all about developers, they really didn’t care about the enterprise. Genius – and now they are clobbering traditional SCCS in the enterprise, because they understood developers.

Salesforce.com? They understood CFOs and the executive suite in general. Many people seem to not realize that all Salesforce did for a long time was replace big SFA systems sold by Siebel and others in the enterprise at 1/10th the ongoing cost of ownership compared to say Siebel  (SMB was different). The product and features/functionality were not better, in fact they were inferior for a long time. They also went after midmarket in a way those big “enterprise software sales” modeled companies could not do nimbly or cost effectively. But in the enterprise, they sold to executive leadership in terms of total cost of ownership, yet it was with the same old features SFA systems had been delivering for 10+ years already. The product innovation was about it being in the cloud, but in reality what that did was make a much lower cost of ownership – there wasn’t a single functional breakthrough in Salesforce’s product in terms of user experience.

I could go on but here’s the point. The question you need to ask yourself is this: What is your big idea? Why does it make a difference? What do my users really need? What would thrill them? Who are the other stakeholders and what do they care about? It seems to me that some startups seem to feel that there focus should be on building a “sales machine” when that is a relatively easy thing to do once you’ve got something worth selling. Having something worth selling in the first place is the hard part to figure out and should be your total focus until you get there (achieve product-market fit first).

I realize this isn’t exactly a newsflash, but I think for early phase startups who are struggling to win early sales, this lesson needs to be deeply internalized. In many ways, the lure of the latest email template or tips on “CXO selling” or ideas on how to set goals for SDRs or how one can “scale” are a distraction from the most important issue an early phase tech company faces. A hint to founders who get distracted by this – most of you don’t know much about sales to begin with, so don’t try to build a sales organization. Instead, try to build a product that is good enough that people actually want to buy it – and then hire sales leadership that has real experience to build out your sales team. You’ll know when its time – it’s when you are getting leads coming at you, and you are being pulled into deals instead of pushing every day.

At what point should an enterprise tech startup begin scaling up a sales team? At what point should it expand into new verticals or adjacent markets?

I happen to quite like the ideas embedded in “Lean Startup” techniques, particularly the concept of “product-market fit”. While not a new idea, the term neatly encapsulates that tipping point a vendor of enterprise tech gets to when it moves from having a good idea to actually selling and delivering a product that makes a real difference for customers.

So, what does that moment look like? Simple – it’s when prospects start pulling you through sales cycles instead of you pushing them the entire time. It’s when prospects email you without you reaching out first. It’s when prospects expose you to the other stakeholders in their organizations without you asking. It’s when customers make referrals to their peers and others in their network without you asking.

What’s really going on is this. You are actually doing something that supports a strategic initiative in the business. The client doesn’t want data governance – they want to make sure they can do business easily and manage privacy and cross-border data issues. The client doesn’t want a new CRM system – they want to improve/change their sales processes so they can improve their close rate. You will get “pulled” when the client actually sees you as a helpful asset to them in achieving their goals, in comparison to the competitors, alternatives and substitutes available to them.

What? You don’t have a clear idea how your prospect sees your company versus the competition and alternate or substitute approaches they have available to them? Hint: This is the place to start if you are not getting “pull”. If you cannot clearly express why you are a better approach than these others, you will not win. Good hustle and lots of pitching will get action and initial sales calls etc, but if your value proposition isn’t strong enough, these “leads” will fizzle halfway through. You will be sending “check-in” emails that don’t get answered and suddenly that prospect who was so nice now has you on permanent ignore. It’s not because the prospect is a jerk, it’s because what you do isn’t compelling enough. Also get that prospects will not bother to explain this to you – but that is the lesson you have to take if you find your “leads” fizzling after an initial call or two.

The simple truth is that if the prospect isn’t pulling, you will not win. And they won’t pull unless what you are doing makes a real difference in what is important to them. This seems basic, but I think many enterprise tech startups don’t fully actualize this understanding in how they go to market.