What’s the deal with BizDev?

I’ve worked in a few companies that had a role called “Business Development”. I have to say, this is probably one of the most poorly defined and managed roles I’ve seen in any of these companies. Usually “Business Development” means “Strategic Alliances”. Now what does that mean?

From what I’ve seen, Strategic Alliances involves trying to cozy up to one or more large technology vendors, such as IBM or HP or Sun or Dell or some equally significantly larger company to develop a relationship with them that will turn into a huge channel for the smaller vendor at minimum, or in some cases, impress them enough that they’ll buy you outright at some point.

Now let’s understand something. In the abstract, this is not a bad thing, and it has been known to work for some companies. But in practice, what usually happens is that the BizDev team cozies up to the target large vendor, creates a lot of “buzz” about the potential of the relationship, IF ONLY, we partake in certain activities with the vendor. These activities, unfortunately, typically involve heavy lifting by Product Management and Engineering for product integrations or ports or feature enhancements and the like. There are of course marketing and sales activities as well that are involved, but the bulk of the effort falls on the product teams.

So, here’s the problem I have with this. When we talk “strategic” alliances, keep in mind, these alliances are usually only strategic to the smaller party. The large partner is probably in similar “strategic” talks with you and all of your competitors as well, playing each off one another.

I once worked for a company that wanted to cozy up to IBM. IBM was willing to help us port our product, which ran on Unix and Windows, to the mainframe (OS/390). We had no such plans on our roadmap and we couldn’t identify more than 1 or 2 (out of over 2000) customers who would purchase a mainframe version of our product. But, cozying up to IBM was “strategic” for the company. Even Sr. Management had bought into this. So, we started the port. I won’t go into all the details of the problems we had (we had very few mainframe savvy staff to begin with), but after about 2 years, and a switch from a native mainframe port (which worked but was very slow and needed a LOT of tuning), to a Linux on Mainframe port, IBM did an about face and bought our biggest competitor for a 10 figure sum. So much for the “strategic alliance”. I’ve seen this type of thing happen at other companies as well.

No disrespect intended, but BizDev people are really just sales people with a very small prospect base, and usually high quota numbers. They are chasing “the big deals”. There are few constraints put on them, because the relationships are “strategic”, and so this pattern of cozying up to large vendors, bending over backwards to impress them, only to usually have the rug pulled out later happens again and again.

Yes, there are risks in business that must be taken, but when the pattern these large companies take, particularly with smaller vendors, is patently clear, why do companies fall prey to this over and over again? Is it simply a case of “lotto-fever”, or are there many more hits than misses that occur across a wide swath of companies? I’d love to hear your comments on this.



6 responses to “What’s the deal with BizDev?

  1. Hey Saeed,

    I was going to post about this on a very similar issue on my site (and hopefully will soon). I am coming from the other angle.

    I work ‘sales’ for a tech company, but in actuality it is totally a business development position. Here is what I believe the difference is.

    With sales, you have a product that is set (unchanging) and it is your job to make phone calls which in turn will make sales happen. Phone Call=Revenue. Good examples of this are toyota camerys and Oracle DBs.

    Unfortunately when small tech companies design products they start with a vision and build out. When things work well, customers need precisely what the company builds, whether its B2B or B2C. I would guess that most the time the company is slightly off, so the company has an expertise, but the designed product does not match business or consumer customer’s needs exactly. This is where business development starts. Yes, many times it is with huge potential customers because they make re-designing worth the effort.

    So in essence, Business Development is where sales and product design meet.

    Business (sales/creating a transaction) + Development (product development/design)= Business Development.

    Sorry, my longest comment ever.

  2. Pingback: What is Business Development? « Life and Life Only

  3. Mike,

    Thanks for the comment, though what you describe is different than what I was thinking. In a sales driven company, product follows the transaction. i.e. the company builds the product to fulfill the transaction criteria.

    There are many examples of successful sales driven companies, but in my experience, those are not ones where Product Management plays a significant role. Program Management may likely be more visible in such a company as they take the requirements from the transaction and work with development to build the solution.

    In a market driven company, which is where Product Management looks at overall market needs (and not strictly at individual customer needs), the transaction follows the product. i.e. the company sells what is built with little or no modification.

    In companies such as this, Business Development can have a distracting effect on the company, because they are playing by different rules. They are pushing a sales driven model into a market driven company. It can’t help but cause problems, unless it is managed properly by the Exec team. In many companies it is not managed well (if at all) and problems arise. That’s been my experience working with several BizDev teams in market driven companies.


  4. Saeed,

    Nicely written article and one that addresses the likely perspective of a product-oriented organization. Fundamentally they have interest in cultivating relationships with larger vendors which inherently increases the possibility (at least) of expanding the channel.

    My perspective on business development however is derived from the vantagepoint of a systems integrator, where there are significant differences between services and product. As someone who has spent over 20 years within federal business development, the term implies an understanding of all aspects of winning business. This includes:

    1. Sales. More specifcally this has a direct relationship to “closing” deals that are typically customers buying off a GSA schedule, or a Indefinite Quantity, Indefinite Delivery (IDIQ) contract. In other words this is much more tactical than strategic.
    2. Marketing. Marketing from an integrator’s perspective is a strategy that enables you to capture business in market segments your typically not already in. For example a company whose portfolio of clients is made up of Navy or Air Force, and they woud like to expand into Army. This requires a collective marketing strategy and sales has little to do with it.
    3. Capture Management. Understand first that within the federal sector, contracts can be very large and bidding programs over $100M is commonplace. As such this individual is someone who understands both sales and marketing, how to cultivate strategic alliances, price to win strategies, and generally also possesses experience writing proposals as well. Which segways to:
    4. Proposal Management. This is also a specialty which, as you know, constitues not only excellent writing skills, but also someone who can dissect RFP’s, and addres the proper thematic messages that resonate wth customers throughout the proposal.

    In aggregate therefore, business development experts within the federal marketplace should have all those aforementioned qualities to be successful. Suffice it to say because of the level of comprehensive knowledge required, their expertise is always welcomed. Hope that helps. Jim.

  5. Pingback: What’s the deal with BizDev? pt. 2 « On Product Management

  6. Pingback: Here’s the deal with Biz Dev (Part I) « On Product Management