Hackernoon logoSales Lessons from a Startup Trench by@sheshank-sridharan

Sales Lessons from a Startup Trench

image
Sheshank Sridharan Hacker Noon profile picture

@sheshank-sridharanSheshank Sridharan

Product Guy & Entrepreneur

I am a product guy. For most of my life, I have treated sales guys with skepticism. A lot of sales teams fit the description of, “ He/she can sell ice to an Eskimo”. At a fundamental level, I disagree with this philosophy. I contend a sales guy should be selling ice in the desert not in the poles to Eskimos. At my start-up, I am responsible for sales, business development and product management. Over the last few months, I have had my share of discovery meetings and learnt quite a few hard things through experience. This are my learnings:

Scraping by is an acceptable state for most people

Product companies think that everybody’s life will be easier after using our product. This maybe true but that doesn’t mean the customer will jump on it. Most people are fine scraping by, no matter how hard the current process is.

If you think that people affected by the problem will push for your software, you are wrong. The fact that they need to change what they have perfected is daunting to anybody.

The question to ask yourself when selling a product is, “What is the alternative?”. The fastest deals happen when the customer thinks the current way of doing things stinks. When I say the customer, I mean the end users as well as the buyer. This is important. If the buyer thinks the process is inefficient and the end user is not convinced, you will have a serious adoption issue. You can read more about this here.

What we need to grasp is how bad is the perception of the alternative to the customer.

  • We know it is bad but does the customer think it is bad?
  • Even if the customer thinks it is bad, are the end users willing to change?
  • How long have they been doing what they are currently doing?

Your product might have a great market fit but if the perception of that fit is poor, you need to work to fix that.

Excel sheets are terrible enemies

I have seen dozens of enterprise users struggling with bulky excel sheets instead of using a software. Excel sheet is a sticky product because:

  • It enforces no rules.
  • It enforces no structure.
  • It is easy to customise.

No rules and no structure mean freedom to do a job the way the user wants to. This can be a powerful paradigm to fight against. Excel is a horrible enemy to fight against. In my previous job, one of our competing products was “Commodity XL”. Everything about it was like excel. They overcame the adoption challenge through existence with excel.

The next time you are selling and your users are using excel, you may want to keep this in mind. It is hard to report on and hard to enforce controls on, that is exactly what the user wants.Don’t push your software as a better alternative to excel.

Following up after an initial demo

The death of most deals happen after the demo/presentation, when you are waiting for your next call. Even worse is when there is an action item on the prospective customer’s end.

In a lot of cases, product companies are driving the sale. We help the customer recognise a problem and then provide a solution. This being the case, once we are out of their office, everyone goes back to work. No one has the time for you. This is a dark place for deals. Calls go unanswered, mails stop getting replies, until one day we give up.

Does this mean that your product-market fit is poor? Absolutely not. I have seen cases where the alternative is inefficient but people aren’t willing to change. The inertia is too strong. There are some things that you can do to avoid this.

Build a starter kit

A starter kit is a short-cut where you identify everything a customer needs to go-live and have that done even before you walk into the demo. In my case, we have a product that helps tech teams hire faster. There isn’t much to configure in the system except creation of the users. The software allows you to create full stack coding assessments which requires the hiring manager to spend 5–10 minutes understanding the system. What I realised was that, this power user feature is not something I would put in a starter pack. So we created a few assessments in the system which the customer can get started with right away. Before even getting into the demo, we have everyone on-boarded on the system. At the end of the demo, we ask the recruiters to bring 10 active resumes and send out invites to them. This approach has its challenges. It is helpful because the user can use it right away.

The sooner you get your users’ hands dirty, higher the chance of success. This doesn’t apply to complex enterprise software that need parameterisation cycles.

My first demo went well. The customer team liked the idea. They left the room in agreement that everyone would get back to me with some details. It took me 4 weeks to get emails. 4 more weeks and multiple calls to get the job roles and 2 more weeks to identify what assessments to create. It was painful, I felt like the guy in this offspring song.

With a starter-pack approach, the hiring managers are usually blown away by how good the webIDE is. Hiring managers have their daily tasks to deal with, recruitment is often like a necessary evil for them. If they bought in to our value proposition everything else will fall into place. This brings me to my next point.

Selling to the team vs. selling to execs

A pilot customer tends to be someone from your close circles, typically an executive. If your product solves a problem, they will be enthusiastic in pushing for your cause. That enthusiasm cannot be expected from the teams under them. Teams on the ground are worried about the daily rigmarole. Unlike an exec who is focussed on the bigger picture, operations teams are worried about daily targets. They see it as a nuisance. I have been through this many times. The key takeaway is:

Don’t sell to an exec, make sure your end user is always in the process. You need the end user to buy-in and stay in the loop.

A few years ago, I came to work to find a mail from my boss. We were to collaborate on a new platform which was like slack’s country cousin. My first reaction was, “WTF and why on earth do we need a collaboration platform?” I walked up to my boss and said, “As a software company, don’t you think requirement gathering is an essential step to software adoption?”. He ignored my sarcasm and said, “The product is owned by our CEO’s friend and we need to see if it works. Please give it a try.” We never sent more than 2 messages, there was never a follow-up from the CEO. That was the end of Slack’s country cousin. Things could have been different if the guy selling the product had asked for a meeting with our team.

Selling to execs will get your foot in the door, from there on get ready to feel the door slamming on your foot if you don’t involve the end users.

Selling honestly vs. lying close to the edge of truth vs. lying through your teeth

Imagine you had to pay $100 per month for a product.

  • The guy selling it to you is telling you the product has 3 features but is unable to show you the system in working order.
  • The guy selling it is showing you 10 features in the product.
  • The guy selling it is showing you 4 features and a working prototype. He also tells you that 7 other features are coming up over the next 6 months.

Who would you pick? Without doubt, most of us would choose the second. This tells us two things:

  • Showing a working system is really important
  • The customer can’t tell if you are showing the app or a cleverly built prototype.

The first is important to make an impression and give the confidence that you have a product. Believe it or not some products exist only on presentations and are built after deals are signed. Last week, I spoke to a mentor who was telling me about his time at a very large organisation. All he did was sell presentations for a year. He quit because he didn’t think it was the right thing to do. This sets a terrible precedence for the competition. Very soon everyone is lying.

The second point leaves a lot of room for lying and cheating to get the infamous foot in the door. Sales teams use prototypes to sell vapourware and then leave the customer disappointed. As someone selling you need to make the hard choice of what is prudent to show and what is not. Most sales people tend to detach themselves from the delivery. They need to assume that the teams delivering the product will come through. This is a way to avoid ownership of failure, if you concern yourself with delivery you can no longer sell.

Sales like everything else is very dependent on the leadership of the organisation and their values. A lot of companies sells thousands of dollars worth of software by lying. This is exactly what is holding them back from selling million dollar deals next time. Problematic implementations and over-worked staff that need to make the delivery happen follow. In the long run, without even realising it, the company builds huge technical debt and finds its customer acquisition level flat-lining. I can’t say what is the best thing to do but my approach would be as follows:

Make sure your sales team is full of guys who have a strong understanding of how products are built.

This will ensure that they know the consequences of what they commit and the likely outcomes. Most sales team suffer from a lack of this understanding which over time leads to a lot of frustration. At an early-stage startup, the product guys usually close the first few deals. As the organisation grows, the sales team starts working towards growth targets and paths diverge. If the sales team and the product team grow with similar values, it will yield the best outcomes.

In summary:

- Scraping by is an acceptable state for most people, it does not aid selling your product.

- Get your customers working with the product as soon as possible. — Any back & forth after a demo usually means dead deals.

- Make sure the end user is buying into your value proposition, execs will only get through the door.

- Build sales teams that understand product building

- Build product teams that understand selling

Tags

Join Hacker Noon

Create your free account to unlock your custom reading experience.