Every single day I have multiple conversations and emails from CEOs and people at companies I work with about how to work with Big Tech Companies. You know – Google, Apple, Microsoft, Oracle, IBM, Amazon, Facebook, Twitter, Salesforce, SAP, LinkedIn, Cisco, Yahoo, HP, AT&T, Verizon, Icouldkeepgoingforalongtime.
But this conversation is not limited to just the gigantic tech companies. They include all the up and comers andtheabunchmoreyouprobablydontthinkarethatbigbutare, including a long list of newly public companies or still private but mega-funded companies.
This conversation comes from two different directions.
– BigCo reaches out to LittleCo and has a classic “happy ears meeting” where BigCo talks a great game about all the great things the two companies can do together and how it’s going to be awesome and LittleCo hears what they want to hear, not what has been actually said. And then the giant black time suck hole of the “let’s work together dance” begins. In the typical case, this goes one for months and months without any resolution or action. Eventually everyone gets tired of each other.
– LittleCo reaches out to me and says “Hey – I really think we could be strategic to BigCo. Can you make an introduction.”
My response to each of these is NO NO NO NO NO NO. After I say NO a few more times, I state “You are thinking about it wrong.”
Instead of expecting BigCo to react to you in any way, start from the perspective that if you want a relationship with BigCo, your only goal in life should be to help BigCo be successful.
Start by coming up with a hypothesis about what you are going to do to help BigCo be successful. Then, test this hypothesis. The Lean Startup approach is super helpful here. Test, ship, iterate – just keep trying and keep learning. Use what you are creating to get the attention of BigCo. Don’t spend six months developing a business development relationship. Don’t spend months trying to get the decision maker on the phone before you’ve done anything. Don’t wine and dine endlessly the people you know, or get connected to. And never, ever go single threaded with one person at BigCo, or one BigCo, hoping something good will happen.
Simply go do some shit for BigCo. Be precise. Execute well. Communicate it to the people you know at BigCo. Do it without any formal arrangement. Show BigCo why they care and why you are the one that will move the meter for them.
Then you can start having the business conversation.
As a bonus, this works for sales also. But you probably figured that out already.
On Monday we had a Foundry Group portfolio company sales summit. We are fortunate in that we’ve got a bunch of amazing sales execs in our portfolio, including several CEOs like Howard Diamond of MobileDay and Matthew Bellows of Yesware who have long histories selling and building sales organizations.
The “enterprise sales software ROI analysis” as a selling tool comes up over and over and over again. And most people blow it, or try to bullshit their way through it, or put together something that is clearly not credible.
So I asked Matthew how he did it at Yesware. Following is his story. Oh, and if you are a Gmail user, check out Yesware.
After spending nearly 20 years selling startup software and services to big companies, I can safely say I’ve seen thousands of “Return on Investment” (ROI) slides. It’s the go-to slide for every enterprise technology salesperson, illustrated with a 4-8 table row, predictably showing that the service in question will pay back the required investment in 6-12 months. Never more (who can wait?), never less (unbelievable).
And like most startup business plans, ROI slides are almost always fake.
The salesperson or their marketing department has no experience to draw on or data from which to extrapolate. Moreover, there’s no accounting for the time value of money, the customer time required to deploy the service, or the risk of time wasted if the deployment doesn’t go well.
Occasionally, a few of the numbers on an ROI slide are based on a previous deployment of the technology. In the rarest cases, the slide has relevant and reference-able data that a potential customer can apply to their situation.
Because of the problems associated with software ROI analyses, we waited a long time to build one at Yesware. And we still failed the first two times we tried. Along the way, we learned that a decent, defensible and compelling ROI analysis requires two key components:
1. Reputable, reference-able customers: The first time we tried to build an ROI slide at Yesware, we anonymously evaluated the data of 40,000 salespeople across a six-month time frame. We were looking for evidence that the people who were using Yesware more actively were making more money than inactive users. Although we found out some great stuff about email open rates and times, and our ROI results looked great to us internally, when we talked to prospects, they were skeptical. Companies, products and industries are so different. No one felt good about applying a broad survey to their specific situation. Lesson learned: Unless a reasonably well-known company is willing to publicly testify to the specific numbers you are showing, you are skating on ice that’s too thin.
2. Identifiable benefits: The second time we tried to build an ROI slide, we worked with one well-known company, analyzing their email and Salesforce.com data. We were blown away by the results – a 40% increase in sales productivity between the active and the inactive Yesware users. It was almost too good to be true.
When we presented the findings to the partner company, they were ecstatic. Not because of our results, but because they just had the best quarter in their company history. They were happy to acknowledge that Yesware had something to do with their success, but a successful product launch also played a big role the 40% increase. Lesson learned: Accounting for your benefits should be easy for both the purchasing manager and the finance evaluator to measure. There shouldn’t be too many variables baked into the results.
We tried again, and this time we got it right.
In our most recent ROI efforts we compiled data from three separate companies to uncover the specific benefits their sales teams have achieved using Yesware. These are all well-known companies that our prospective customers can call to learn more – Acquia,Mimeo, Dyn, and WeddingWire. Each is a leader in building modern sales teams, and has offered to be a reference for Yesware.
With this kind of dataset, a simple survey can reveal incredible results. We discovered that on average, sales teams using Yesware:
- Grew new business (including upsells) by 25%
- Improved response rate by 32%
- Improved overall call connection rate by 32%
There are certainly ways to make our ROI analysis better: We will continue to gather a bigger dataset both in terms of customers and salespeople. We will get data from companies outside the USA. And we will keep trying to better tease apart the various contributing factors to changes in productivity.
But overall, we’ve finally cracked the code on a decent, defensible and compelling Return on Investment analysis. I hope this guide helps you create your own.
I get demos every day. Multiple times a day. I don’t want to see a powerpoint deck – I want to play with something. I don’t want to hear a description of what you do – I want to see a demo. I don’t want you to tell me your background, where you went to school, or where your grew up. I want to see what you are working on.
I still remember my first meeting with Bre Pettis at MakerBot. I walked into the Botcave in Brooklyn and was confronted with a long, narrow Brooklyn-style industrial building where I could see people working away in the back. But before I got to them, I had to walk through a 1000 sq. ft. area of MakerBot Thing-O-Matics printing away. This was an early “bot farm” and it probably took 15 minutes before I walked the gantlet. They were printing all kinds of things, there were display cases of other stuff that had been printed, and a vending machine for Thing-O-Matic parts.
When I got to the back where people were working, I totally understood what MakerBot did and what was possible with 3D printing.
We are lucky to be investors in a bunch of companies creating amazing new products. One of them, Oblong, as been working on spacial computing since John Underkoffler’s early research in the 1990’s at the MIT Media Lab. For a number of years they were described the “Minority Report” technology (John was the science/tech advisor to Spielberg and came up with all the tech in the movie.) The following video is John showing off and explaining the core G-Speak technology.
The demo is iconic and amazing, but it takes too long and is too abstract for their corporate customers buying Oblong’s Mezzanine product. The short five minute “overview video” follows.
While this gives you a feel for things, it’s still showing the “features and functionality” of the tech, applying a general use case. For several months, I kept banging on them to set up a simple use case, which is the how I use the Mezzanine system in our office. I use it every day and it’s been a huge factor for me in eliminating all of my travel.
A few months ago, Oblong had a sales off-site to go through the progress they’ve made this year and to focus on the balance of the year. They’ve had a great year, with a strong quarter-over-quarter sales ramp for Mezzanine on both a dollar and unit basis. The customer list is incredible, their classical enterprise land and expand strategy is working great, and new high-value use cases are being defined with each customer. So I smiled when I the following slide popped up on my Mezzanine during our weekly leadership team call.
While a little abstract in writing (I don’t expect you to understand the first three bullet points unless you know how Mezzanine works), when it’s shown in the first five minutes of a demo it simply blows your mind. And you totally get all three of the core technologies that Oblong has incorporated in Mezzanine (spatial computing, pixel virtualization, and data pipelining.) Your next reaction is “I want one.” And then you are ready for the feature / function discussion, which can easily go on for 30 minutes.
There is endless talk about product development and getting “personas developed” while you figure out how to build your product for them. This approach is equally useful for demos, but it is so often overlooked. I can’t tell you the number of times people start just showing me stuff, rather than saying “here’s the problem I’m going to solve for you that I know you have” – BOOM – and then I’m totally captured for the next 30 minutes.
Try it. The first five minutes is the most important with someone like me. Don’t waste it.
I got an email today from an exec at a company who I was with at a recent board meeting. I thought it was a powerful summary of part of our discussion, specifically around the sales pipeline for Q4 and overall sales execution. I’ve been in something like 91,293 pipeline reviews in my life and it continues to baffle me that experienced sales execs manage to snow the CEO and the board with “probability weighted sales pipeline.” I hung in there in this case and continued to make my point about playing offense on sales forecasting.
Rather than trying to summarize it, I got permission to just reprint the email. It follows.
One of the larger take aways for me was your insight on our attitude towards how we were predicting revenue. Prior to our meeting, we thought we were doing a good job of predicting revenue. We are working on 10 deals and we explained to you that we thought that 75% of these deals would close within the next 60 days or so.
You asked specifically, “which of those deals would close?”
Our answer, was “we feel confident that each of these deals has a 75% chance of closing”.
You pushed us and asked “which of these 10 deals has a 100% chance of closing?”
Our exec team looked at each other in silence.
We were hard pressed to answer that specific question. We couldn’t answer that question.
The takeaway for me was that we need to take the offense when it comes to predicting revenue. We need to change our mentality from Defense to Offense.
Defense was: Us allowing FATE to play a large factor in whether or not a deal closed. We accepted the fact that 75% of these deals will close, but couldn’t point to WHICH 75%. We were in “wait and see” mode and allowing fate to decide our monthly revenue.
Offense is: We feel good about these 5 specific companies signing and we are going to commit to them closing as a sales team and a company. We are going to keep on top of them, be proactive, and make sure they close. Fate will have VERY LITTLE to do with whether these deals close or not.
It is a subtle adjustment, almost semantic, but one that will make a very large difference in how we act, how we talk, how we think, and ultimately how much revenue we book.
One of the companies I’m an investor in has a gong in the office. They bang it every time they sign up a new customer. They also have a virtual gong – an email that goes out to the entire company and board that starts with GONG: (Client Name). The salesperson who closed the deal gets to send the email out and write whatever he or she wants. Everyone in the company then piles on with Reply-All commentary.
It’s just awesome. I know many companies that ring bells or make some kind of other noise in the office when they close a sale. But it’s not very noisy if you have multiple offices, people on the road, or board members who don’t work out of your office.
Now, if you have a self-serve, high velocity model you may not want an email going out with every signup. So how about a daily gong at the end of the day that the system automatically emails out. I’ve written about email robots in the past – many of the companies I’m an investor in have an email robot that sends out the sales summary for the day at 12:01am the following day. The formats vary, but they are all short and consumable by all. No fancy graphs. No complicated analysis. Just raw data every day that informs everyone in the company how many new customers we got yesterday.
So ring that gong loudly. Take a page from my friends’ playbook and get that email out every time a new deal closes.
In December, I wrote a post titled Give Your Sales People All The Knives. While I let you draw whatever conclusions you wanted from the post, I thought I’d follow through and give you a little more detail about what I meant by the statement.
I framed the problem with the struggle many software companies have been going through over the past few years (or decades – depending on who’s version of history you believe) around selling perpetual licenses vs. subscriptions. I inadvertently included the construct of the deployment model (desktop, server, or SaaS / hosted) which, while a key part of the evolution of the software business, was not the part of the problem I was referring to when I suggested you should give your sales people all the knives.
A few people wrote me concerned that I was suggesting that the sales organization should determine the deployment model and that I was suggesting a company shouldn’t differentiate between desktop, server, or SaaS. Don’t be concerned about this – it isn’t my argument or suggestion.
Instead, I’m focused entirely on the licensing and pricing model (which I’ll simply refer to as the “licensing” model – which includes price.) I’ve been in more conversations that I care to count about how to price software, regardless of the deployment model. The licensing model and the deployment model inevitably get tangled up when they shouldn’t.
In 2009 (and going forward) customers will buy software using both perpetual licensing and subscription licensing, regardless of how the software is deployed. In addition, customers will buy perpetual licenses but pay periodically (monthly, quarterly, annually) and customers will buy subscription licenses but pay in single payments up front. If you can parse all of that, this is the exact opposite of the theory of how the software licensing and deployment were intended to line up. Of course, this is nothing new as software leasing has been around since the beginning of the software business, as have prepaid services.
While I know all of this gives the auditors great pleasure because it means they get to spend more time lecturing companies about revenue recognition and enforcing accounting policies that distort the true financial picture of the company under the guise of complying with GAAP, it’s irrelevant. Your goal as a company is to create great products that your customers will pay you for. The goal of your sales organization is to sell these products; they shouldn’t care how the customer wants to license the products.
That’s the essence of what I mean by Give Your Sales People All The Knives. While it makes good business sense to have a religious point of view about the deployment model (there are fundamental differences between a SaaS deployment model and a software license / behind the firewall / on premise / whatever you want to call it deployment model), customers buy each deployment model a variety of different ways and your licensing model should accommodate.
I regularly hear the argument that the economics aren’t the same. Baloney – they are approximately the same. A typical perpetual model is $x in year 1 with 0.2x in year 2 and year 3. A typical subscription model is 0.4x in year 1, year 2, and year 3. Tweak this however you’d like; you get a roughly equal cumulative payment stream over four years. I understand the cost of capital argument – you’d rather get the money up front, but remember that some customers want to pay for the subscription model up front (three year pre-pay for the subscription – or a single check of 1.2x) while others want to pay for the perpetual model in equal payments over three years (0.467x / year).
Cash flow follows this logic. The customer wants to pay in different ways to manage their cash flow. Some want to pay monthly; some quarterly; some annually. The deployment model doesn’t matter; the license model doesn’t matter – how the customer wants to pay is what drives this.
Fundamentally, the customer is managing two things. First is cash flow. If the customer has a use it or lose it budget, they want to pay now. If they have no (or minimal) budget but really need the software, they want to pay monthly and try to bury the expense in a cumulative budget, or get a budget exception for a small monthly payment. Second – and more subtle – is how the customer accounts for the purchase. Many companies (whether they should be or shouldn’t be) want to capitalize the software purchase and put it on the balance sheet to manage short term earnings, especially in down markets. Others are perfectly happy to have the purchase be an income statement item. The two issues drive customer purchase behavior much more than your licensing model does. As a result, I’m suggesting you should set up your licensing model to be flexible to accommodate your customer’s needs, rather than the other way around.
Bottom line – if you make software for a living, regardless of your deployment model, you should be able to provide either a subscription or perpetual licensing model, with any type of payment approach.
Many companies have only been giving their sales guys the brown handled knives (e.g. they are limited to using one type of licensing model.) Selling software into a downturn is always harder. Now is the time to give your sales people all the knives. If they don’t carve up enough business, they’ll at least have enough knives to put themselves out of their misery.