5 ms·

How To Hire Great Business Development People

52 points by eladgil 14y ago

pkaler 14y ago
I interview Business Development people just like I interview developers. I want to see them "code". I have them open up their CRM tool of choice. Then I have them explain their funnel. They should be able to step me through how they've setup their stages: Qualifications, Needs Analysis, Decision Makers, Value Proposition, Quote, Negotiation, etc. Then I have them deep dive on a particular deal and have them explain each of these stages for this particular deal.
- rscale 14y ago
  I'd be extremely reluctant to hire somebody who was willing to give me a guided tour of another company's CRM. Even ignoring the ethics of the request, if somebody is willing to act against their current employer's wishes, they're almost certainly going to act against my wishes as well. There are plenty of ways to check an applicant's abilities without requesting access to confidential information. This is as true for biz dev as it is for coders.
  - DenisM 14y ago
    Where did you yet the idea that GP asks for confidential CRM deployment? I think you are jumping to unwarranted conclusions.
    - rscale 14y ago
      I got the idea from his post. The vast majority of BD candidates can't open a CRM and provide detailed information about it's structure and the deals it contains without revealing confidential information. As such, I think it's a poor idea to make that a standard part of the interview process. You mounted an unwarranted defense. There are edge conditions where somebody could do so without a problem, but they're the exception that proves the rule.
- notahacker 14y ago
  Hiring a salesperson on their ability to describe pipelines in abstract terms and relate it to a CRM is a bit like hiring a programmer based on their ability to describe a particular software pattern and relate it to an application.(1) Sure, most worthwhile candidates will give broadly similar answers showing they understand the theory behind what they're doing and had formal training in it, but can they actually write the code? If you want to see them "code" get them to sell to you. Do they ask good questions? Can they relate answers you've given to an actual proposition? Are they so thorough and accurate they've ended up with a watertight business case for that proposition? Have they identified other hypothetical stakeholders they're going to need to ask similar questions to present similar cases to, and how far you'll help them with that? How do they respond to your 11th hour attempt to reduce the price? That's "coding". The other stuff is architecture: important but pretty useless without the fundamentals unless you're looking for a pointy haired guy. Plus the really good sales guys often intuitively breeze through a lot of those official "stages" in one call or meeting, whilst appearing "stuck" at another stage for ages, and are completely comfortable with that because they know what aspects of the sales cycle they can and can't control, and why they'll be waiting. This probably sounds less impressive than the textbook example of steady progress a good bullshitter should be able to come up with. (1)arguably worse: probably the best explanations of pipeline organization you'll hear are from underperformers in large companies who have to explain their activity to their line manager in more regular review meetings. The guy that sucks at writing code probably gets less regular invitations to meetings to decide on application architecture.
- orangethirty 14y ago
  Really? That doesn't sound very effective. May you shed more light into it? I'm really curious to learn more. In my experience, people who can sell are better off tested with actual selling and not the administrative side. They can always learn how to do the things you describe, but not everyone can sell.
DenisM 14y ago
This seems like a good advice to me if you're hiring a bd guy. Any extra advice if you (a hacker) are partnering with a bd guy? The only thing I can contribute is to look if the would-be partner has any friends from previous engagements joining the new venture. If so, it establishes that your prospect is not a pathological liar (no one would stick around with that sort of person). It's important because a compelling bd story could be a great business opportunity, or complete bullshit, and a hacker type is normally unable to tell them apart. It's not much, admittedly, but maybe this will get the conversation rolling?
- orangethirty 14y ago
  You need to see their track record. Have they published anything? Do they talk about their failures? How much actual business experience do they have? As someone who does both sides (software and business) I've come to realize that the best way to approach is as you would approach hiring a developer. You want someone who has shipped code and can ship code. Sometimes people exaggerate things, that's normal due to the competition. It is a red flag, but not a complete deal buster. Keep an eye for it. If it sounds fishy and does not have real data to back up then just send them out politely. By the way, I get way more red flags from hiring developers than from hiring business people. Dunno why.
  - hkon 14y ago
    Care to elaborate on the red flags?
notahacker 14y ago
I was slightly disappointed a list that was long enough to have two references to understanding legalese(1) omitted stuff as basic as "incredibly aware of your market" and "customer-need oriented" On the other hand I love the fact that you've underlined Raw charisma is drastically over rated by technical founders. Very true, and very important, especially if you're selling complex b2b products to the sort of audience that usually will do deals with the socially-awkward stereotypical geek that understands their needs and won't do it with the beautiful, bubbly person that wants to take them out for a delightful long lunch to distract from the detail. (1)useful, but you hire lawyers to ferret that stuff out and bizdev guys to come up with propositions compelling enough to discourage the other party from weasel-wording their contract clauses
- eladgil 14y ago
  Thanks for the feedback. I agree with your point about "incredibly aware of your market". "Customer-need oriented" I think is great for a sales person. For a great BD person maybe a similar axiom should be phrased as "understand the other sides objectives clearly" and really dig into what the other party wants (versus what it claims it wants).

52 points by eladgil 14y ago

I interview Business Development people just like I interview developers. I want to see them "code". I have them open up their CRM tool of choice. Then I have them explain their funnel. They should be able to step me through how they've setup their stages: Qualifications, Needs Analysis, Decision Makers, Value Proposition, Quote, Negotiation, etc. Then I have them deep dive on a particular deal and have them explain each of these stages for this particular deal.

rscale 14y ago
I'd be extremely reluctant to hire somebody who was willing to give me a guided tour of another company's CRM. Even ignoring the ethics of the request, if somebody is willing to act against their current employer's wishes, they're almost certainly going to act against my wishes as well. There are plenty of ways to check an applicant's abilities without requesting access to confidential information. This is as true for biz dev as it is for coders.
- DenisM 14y ago
  Where did you yet the idea that GP asks for confidential CRM deployment? I think you are jumping to unwarranted conclusions.
  - rscale 14y ago
    I got the idea from his post. The vast majority of BD candidates can't open a CRM and provide detailed information about it's structure and the deals it contains without revealing confidential information. As such, I think it's a poor idea to make that a standard part of the interview process. You mounted an unwarranted defense. There are edge conditions where somebody could do so without a problem, but they're the exception that proves the rule.
notahacker 14y ago
Hiring a salesperson on their ability to describe pipelines in abstract terms and relate it to a CRM is a bit like hiring a programmer based on their ability to describe a particular software pattern and relate it to an application.(1) Sure, most worthwhile candidates will give broadly similar answers showing they understand the theory behind what they're doing and had formal training in it, but can they actually write the code? If you want to see them "code" get them to sell to you. Do they ask good questions? Can they relate answers you've given to an actual proposition? Are they so thorough and accurate they've ended up with a watertight business case for that proposition? Have they identified other hypothetical stakeholders they're going to need to ask similar questions to present similar cases to, and how far you'll help them with that? How do they respond to your 11th hour attempt to reduce the price? That's "coding". The other stuff is architecture: important but pretty useless without the fundamentals unless you're looking for a pointy haired guy. Plus the really good sales guys often intuitively breeze through a lot of those official "stages" in one call or meeting, whilst appearing "stuck" at another stage for ages, and are completely comfortable with that because they know what aspects of the sales cycle they can and can't control, and why they'll be waiting. This probably sounds less impressive than the textbook example of steady progress a good bullshitter should be able to come up with. (1)arguably worse: probably the best explanations of pipeline organization you'll hear are from underperformers in large companies who have to explain their activity to their line manager in more regular review meetings. The guy that sucks at writing code probably gets less regular invitations to meetings to decide on application architecture.
orangethirty 14y ago
Really? That doesn't sound very effective. May you shed more light into it? I'm really curious to learn more. In my experience, people who can sell are better off tested with actual selling and not the administrative side. They can always learn how to do the things you describe, but not everyone can sell.

DenisM 14y ago

This seems like a good advice to me if you're hiring a bd guy. Any extra advice if you (a hacker) are partnering with a bd guy? The only thing I can contribute is to look if the would-be partner has any friends from previous engagements joining the new venture. If so, it establishes that your prospect is not a pathological liar (no one would stick around with that sort of person). It's important because a compelling bd story could be a great business opportunity, or complete bullshit, and a hacker type is normally unable to tell them apart. It's not much, admittedly, but maybe this will get the conversation rolling?

orangethirty 14y ago
You need to see their track record. Have they published anything? Do they talk about their failures? How much actual business experience do they have? As someone who does both sides (software and business) I've come to realize that the best way to approach is as you would approach hiring a developer. You want someone who has shipped code and can ship code. Sometimes people exaggerate things, that's normal due to the competition. It is a red flag, but not a complete deal buster. Keep an eye for it. If it sounds fishy and does not have real data to back up then just send them out politely. By the way, I get way more red flags from hiring developers than from hiring business people. Dunno why.
- hkon 14y ago
  Care to elaborate on the red flags?

notahacker 14y ago

I was slightly disappointed a list that was long enough to have two references to understanding legalese(1) omitted stuff as basic as "incredibly aware of your market" and "customer-need oriented" On the other hand I love the fact that you've underlined Raw charisma is drastically over rated by technical founders. Very true, and very important, especially if you're selling complex b2b products to the sort of audience that usually will do deals with the socially-awkward stereotypical geek that understands their needs and won't do it with the beautiful, bubbly person that wants to take them out for a delightful long lunch to distract from the detail. (1)useful, but you hire lawyers to ferret that stuff out and bizdev guys to come up with propositions compelling enough to discourage the other party from weasel-wording their contract clauses

eladgil 14y ago
Thanks for the feedback. I agree with your point about "incredibly aware of your market". "Customer-need oriented" I think is great for a sales person. For a great BD person maybe a similar axiom should be phrased as "understand the other sides objectives clearly" and really dig into what the other party wants (versus what it claims it wants).