The Biggest Screwup You Can Make as a First Time Startup Sales Guy or: “How to Sell Like an Engineer”

There are a lot of things you can screw up as a first time sales guy – especially having never done it before. I know. I’ve screwed them up.

One of the worst is having a crappy way of thinking about your prospects and the key datapoints that help you qualify and prioritize between them.

So, when I say “sell like an engineer” I do NOT mean roll into the office 11AM, stay till 2AM, and stare at your shoes when you talk to someone ; )

What I mean, is that borrowing rigorous modeling concepts from your tech team might be one of the smartest things you can do as an early stage sales leader.

WYMIWYG #

My friend, and TalentBin technical lead, Rodrigo Leroux has this handy saying – What You Model is What You Get.

Now, he’s typically talking about this in a data model capacity, as relates to modeling software engineering candidates via TalentBin (or other such logical objects in a datastore), but it’s been helpful for us on the TalentBin sales team too.

That is, the meta-data with which you characterize a business object is central to your ability to interact with it in a business setting.

On the sales team, that modeling means Prospects and Opportunities.

Modeling Sales Objects for Maximum Impact #

In sales, and especially early stage sales right beyond the cusp of product-market fit, focusing your time and efforts on the most impactful prospects, and as they make their way down the funnel, the most impactful opportunities, is paramount.

And typically what that means is engaging with prospects for whom your offering solves the greatest magnitude of business pain. Not just a little. Not even a lot. The largest business pain possible. (This is somewhat tempered by the concept of Rabbits, Deers, and Elephants in Startup sales. )

Early stage, newby founder sales types often have the issue of thinking “Wow, there’s so many people, and my solution will work for so many of them! Let’s talk to them all!” That’s pretty much the worst thing you could do.

More on that in a separate post, but if you are to prioritize your prospects, and later, as they continue down the funnel, opportunities, you need to have them modeled in your CRM in a way that allows you to do that.

What are the business pain drivers that make a prospect relevant to you? #

I’ll use the case of TalentBin, since it’s near and dear to my heart.

There are many organizations out there who are hiring for hard to hire technical talent – literally any organization who works in software, small or big, corporate or agency could be said to have this business pain

But when you’re starting out, and especially when you’re in Evangelical Sales mode, like we were with TalentBin back in late 2011, taking an unproven, early adopted solution to a market that has plenty of status-quo options to go with, prioritization is key.

So when filling your CRM with Prospects, and later, Opportunities you need to ensure that you have them properly modeled to let you ruthlessly qualify, and then even force rank prioritize within that set of qualified prospects.

Types of characteristics to think about modeling #

Raw fundamentals: These are the fundamentals that pretty much any lead database will give you, and often are not super helpful in prioritizing your leads, but can help you in segmenting territories.

These can be things like Zip Code, Geographical Basin, but also Headquarters Phone Number, or corporate website, or organizational LinkedIn Company Page hyperlink (e.g., http://www.linkedin.com/company/yelp.com for quick access to employee lists, etc.)

This can also include things like company revenue size and employee count – which a lot of the time can be used as a weaker signal of potential prospect-solution fit, but honestly, there are probably much better signifiers that are leading indicators of business pain that your solution solves.

Special for your solution: Then there are Account characteristics that are specific for your solution.

Like in the case of TalentBin, our solution makes technical recruiters more efficient and impactful, and better at hiring more software engineers, with higher quality, faster.

So it’s only natural that organizations with high technical recruiting requirements, that is, with many recruiters (who could use the solution), and so on would be a great fit for our solution – and the more of those characteristics a given Account has, the better.

Generally speaking, these characteristics bucket into those that are observable in the world (and thus accessible to a lead generation team), those that are only observable after engagement with the Account (to sales staff), and those that are based on the judgement of the sales staff themselves. All are important to capture and model in your CRM.

Observable in the world-characteristics: The first bucket is those that are observable in the world, and harvestable, ideally, by a lead generation team, who do the heavy lifting for your MDRs (Market Development Reps) and AEs (Account Executives), letting them focus their time on selling.

For instance, our lead generation team at TalentBin (more on this later), when discovering and harvesting Prospect targets, grabs the Account’s Jobs Page (e.g., http://www.yelp.com/careers) (so our MDRs and AEs can quickly refer to it), they count the number of technical requisitions (e.g., openings for java, python, ruby, ios engineers, devops, UI/UX designers, etc.), they count the number of recruiters in the organization (by searching on LinkedIn for specific titles, in that this indicates the potential total demand for our solution in an organization). They even pull the type of technologies that an organization uses in their tech stack for (e.g., java, spring, mysql, jquery, etc.)

In addition to organic sources (like an organization’s web presence or LinkedIn) you can often get access to this from special sources, like BuiltWith.

So for instance, if your offering would be relevant to organizations that use Optimizely / Monetate for A/B testing – having that information attached and modeled with an Account in the CRM is important.

Even better are external signifiers that indicate budget. In the case of TalentBin, organizations that have high technical requisition counts are good – but those who also are posting lots of job postings that cost actual money are event better.

The upshot is that there are a number of characteristics that are key to qualifying and prioritizing prospects that are observable in the world – and that you should make full use of that.

Later-observable characteristics: The second bucket of characteristics are those that only come to light as your sales staff engages an Account in an Opportunity.

While these often can’t be harvested ahead of time, they are important to have modeled in your CRM as they become discovered in the sales process, in that they, like the publicly observable ones, help your sales staff qualify and prioritize how to spend their scarce time on their Opportunities.

Examples of these would be budgetary cycles, existence of budget, or other tools that are being used by an organization (e.g., we like to sort out if an organization is using LinkedIn Recruiter or resume search databases – both are offerings that we smoke for the technical recruiting case, and which indicate that an organization already spends resources on offerings for which we are a better substitute.). Especially relevant would be a hypothesis of the forecast revenue for a the deal in motion.

They can also be indicators that an organization has complementary technologies that make your offering make more sense. In our case, if a recruiting organization uses Gmail or Outlook – both of which are email systems that TalentBin integrates with and extends for technical recruiters – it makes our offering all the more compelling. So too if they have an Applicant Tracking System or Candidate Relationship Management system that TalentBin exports to.

Similarly competition. If an organization if considering one of our (inferior) competitors, ensuring that the AE knows that this is the case, and how to position our strengths against their weaknesses, is vital.

Judgement-based characteristics: Then there are judgement-based characteristics. These aren’t purely observable in the world, like the number of technical requisitions, or even which email system an organization uses.

In our case, our MDRs have the capacity to rate an Account as Cold, Warm, Hot – that is, while on its face an Account might seem very relevant, with lots of tech reqs, budgetary signifiers, and so on, there may be a certain sense an MDR gets that tells them that it may not be as hot as it seems. Or the reverse. So letting that MDR model that opinion in the CRM, for later reporting on is important.

So too with the age-old AE characteristic of “deal stage” for an Opportunity. “Qualified”, “Negotiation”, “Sent Proposal”, “Verbal Commit”, etc.

All help an AE make sense of the relative stage of a deal in motion.

Evolvable characteristics: Don’t forget that you’ll continually be learning which of these matter more than others, discovering new ones, and also realizing that ones you previously thought were vital aren’t as important as you thought.

For instance, we realized that raw technical requisition count was only part of the story, but that, additionally, technical requisition intensity (as in, as a proportion of total open hires) was another important characteristics.

That is, 5 technical reqs might be promising in a company that has 10 total openings (a 50% req relevancy). But 5 technical reqs amongst 200 total openings might be less interesting.

So we updated our process to require the capture of the total number of open reqs so we could converge on technical recruiting intensity.

Moderation in All Things: One thing to note in all of this is that there’s always a cost to more process.

You can always add *one more* thing – but that can aggregate into substantial overheard. So always be clear that it’s worth the effort, and if it turns out that the characteristic that you previously thought was paramount turned out to be just so-so, cut that requirement. It’s ok to be wrong. Just fix it.

Now that you have these, now what? #

Having these characteristics explicitly modeled is all well and good, but then what?

Well, once you have your Account and Opportunity objects nice and tagged up with these key characteristics, that’s when the fun starts.

Any CRM worth its salt (We use the hell out of Salesforce) will let you report on all this data for reporting and list building.

Qualification: MDRs choose to spend their time attacking the Accounts that are most likely to turn into held demos. As such, an MDR would choose to pursue Accounts with the highest technical req plus recruiter count plus budget intensity.

Reporting on that is only possible with the relevant characteristics modeled in the CRM.

Time Prioritization: AEs know that not all Opportunities are created equal. Helping them prioritize between different Opportunities, using size of deal, competition in the deal, complementary-characteristics, and such can help them know which opportunities to spend the majority of their time on, and which ones to put on the back burner.

Territories / Size of Prize: Having your Accounts well-modeled with relevant characteristics can help with pan-sales organization activity as well.

For instance, (and this is something that only becomes relevant in later stage organizations – so early stage founders and sales folk – just put this in the backlog. You need to crawl before you can walk before you can run, son.) being able to balance total opportunity when assigning Accounts across AEs.

It can also be helpful once an Account goes from Prospect to Customer for Account Management, to understand the total “size of prize” (a concept we heartily borrowed from LinkedIn’s sales organization), to understand that while we may have sold 5 seats today, there’s a total opportunity of 20 seats for Account Management to attack. So we better get busy on those!

Model, and go get it! #

All of this is a result of nearly 3 years of early stage sales operations and scaling learnings. Most of it was painfully earned.

Modeling-centric thinking in a sales use case is just as valuable as in an engineering use case.

And it might just make you some revenue, too.