… And why you’ve likely mis-casted the role, missed an interesting product integration or wasted valuable time for you and a potential partner.

Typically, in any evaluation between two companies, there are two sides.  The side that is “selling” a concept and the side that is “buying” the concept.   The Business Development function can serve an important role, but the structure and process depends on which side of this discussion you are on. 

Business Development at a start-up is inherently a “sell-side” function.  “Sell-Side” BD is typically looking to federate your business, attempting to generate distribution, market awareness and new revenue channels.   It usually benefits from an individual with a strong sense of product, a creative ability to develop use cases, an ability to navigate through organizations and a “Hunter’s”’ instinct.  

Business Development for a large, established organization is typically a “Buy-Side” function.  Buy-Side BD is typically responsible for being able to source, evaluate and channel 3^rd party solutions to the right department in an organization and structure consistent and favorable business terms to integrate 3^rd party solutions into their business environment.  It usually benefits from an individual who is a strong evaluator of tech/talent, an assessor of whether a 3^rd party services internal goals, an accurate router to the right business owner and a strong business negotiator. 

The biggest problem I encounter is that most organizations don’t distinguish between the two.  They typically have their “Sell-Side” and “Buy-Side” BD person one of the same, which undermines the difference in the two functions and the characteristics that are required to make each function individually valuable.

“Buy-Side” BD is an incredibly important function, but it needs to be respected beyond being a “gatekeeper”. The problem is that inbound requests are often forwarded and intercepted by the opposing VP, BizDev as a gatekeeper rather than being placed into a formal process for evaluation.

Let’s play out a hypothetical situation … A “Sell-Side” BD person from Yelp is pro-actively validating new merchant relationships to monetize their check-in feature and generating new distribution deals for Yelp merchant reviews one day and the next day putting on their “Buy-Side” BD hat and asked to reactively evaluate 3^rd party solutions, such as the viability of the SimpleGeo API or the Hunch personalization platform?  Do you want your BD person evaluating new technology and determining if it is a “product” fit?  Or would you prefer for your head of product or business owner managing those relationships?  This opens you up to leakage of potentially great ideas while your competitor is actively working a deal with the vendor.  While this is an arbitrary example, it happens all the time. 

One of the best “Buy-Side” BD structures that I have seen is from the team at Target.com.  They have a plan and a framework.  They have an internal “Buy-Side” BD team, who is briefed of internal objectives, who actively source potential vendors in the space, schedule a meeting/call with the right person at the vendor, loop in the appropriate business owner on their side for that meeting/call to evaluate the offering and then manages the process going forward.  It is a targeted approach, clean and organized, and really highlights the value of integrating many corporate objectives into a single business development group to be managed.

“Sell-Side” Business Development Framework

I recently wrote a post that focused heavily on the role of “Sell-Side” Business Development.  Here are a few highlights to focus and distinguish your “Sell-Side” BD responsibilities:

1. Evangelizing a product/service (ie, your B2B Marketer)
2. Looking to validate markets where the product/service has a natural fit
3. Generating distribution deals
4. Reporting back to management and product teams on market feedback
5. Exploring monetization techniques. 

Think of Sell-Side Business Development as Scout Ants or your organization’s Special Forces.

“Buy-Side” Business Development Framework

“Buy-Side” Business Development, on the other hand, should be focused on integrating various functional objectives across an organization into a single, uniform group.  A “Buy-Side” BD person/team should have an intimate knowledge of functional goals and priorities across sales, marketing, product, infrastructure, etc. with a focus on sourcing vendors, routing vendors to the right part of the organization, managing the process and to negotiate favorable business terms.  They should sit with the various functional teams each week, reporting on companies they have met or spoken to for that function to evaluate the merits on.  They should tell vendors “I will put you in touch with the right person here” more often than they say “we are not interested”, extending market feedback directly to the business owners.  When passing an initial look at a potential partner/vendor, Buy-Side BD should determine if a vendor has a solution that:

1. Is in the product, marketing, sales priority list or pipeline
2. Has already been determined to have been built in-house or not
3. Is competitive with an existing partner/vendor and understand differences
4.  Is appropriate for which stakeholder within the organization to evaluate.

Additionally, “Buy-Side” BD is incredibly important to structure and negotiate deals with vendors and to create a consistent layer of deal terms, structures and legal language. 

Think of your “Buy-Side” BD team as your Air Traffic Control and Chief Negotiators.  

Permalink | Leave a comment  »

The great fad of the last several years is self-serve and the ability to scale the distribution and access to your technology, product, service or data.  The Twitter API, Facebook Connect, Yelp API for reviews, Youtube Embed codes, Google Maps API, you name it.  And everyone knows the APIs out of the media darling’s Foursquare, Zoho and Dropbox.  But, how about little known web services that may have great functionality that you have likely never heard of like Mombo’s Social Movie Review API, Email Yak’s web-based email API, Guitar Cord’s music utility service API, YoLink’s semantic search API and literally thousands of others that have great products, but are rather unknown. 

Business Development 2.0 isn’t a new concept.  Hunch’s Co-Founder, Caterina Fake, talked about Qoop building off of Flickr’s API back in August 2006, while Fred Wilson blogged about how pervasive APIs, embeds, widgets, search and RSS feeds would become to quickly get distribution or access to services.

There’s a difference, however, between responding to inquiries versus begging for the first 1, 2 … 10 sites to use your web service.  Twitter, Facebook, Google and Yelp need an API because they can’t respond to the market fast enough for people seeking access … here self-serve makes a whole lot of sense because the value of these services are well understood and it cuts out expensive teams of sales, business development, account/client management, professional services, etc.  

However, what happens if you believe you have an amazing service, data, content or technology but nobody really knows about it?  Or nobody knows the benefits of building on top of your API?   You have a classic chicken and egg problem.   The trick is to think of your API, RSS, Embed, etc as a product and a business itself.  And like any product or business, understand how to market it and how to build awareness to drive market adoption.

Building and developing a self-serve API or web service is half the battle and I would argue it’s a lot less than half.  For example, Hunch.com is built entirely on our own API.  A team of clever and ambitious people could access the Hunch API and attempt to re-create Hunch.com from scratch.  The functionality and the value is all there.  But, we will define success when the web embraces the Hunch API in a fully federated fashion, in addition to a well-traveled destination site.

So, the great challenge is how to market your API so that people know a) that it is available, b) how/why to use it and 3) what value they can generate from it.

When I joined Hunch, Chris Dixon asked me what my goal would be and more importantly, how I would know if I achieved success.  My response was to cannibalize my own function by popularizing the Hunch API into the wild.  It was a simple lesson that I learned from Alan Spoon, former President of the Washington Post Company and Managing Partner at Polaris Venture Partners, who once told me that companies don’t move aggressively enough to cannabilize their business, but rather spend too much time trying to defend it. 

We created a blueprint of the goals and process of popularizing an API and generating distribution on our way to a full self-serve platform.  Here are some suggestions:   

Goal of Marketing your API:

1.  Develop Market Awareness for your service and availability of your API
2. Absolutely nail 3 partner use cases that has strong re-use across the market
3. Determine Success Metrics, Analytics (Proof that your API yields Value Impact to 3^rd Party) to preserve future monetization options

The Process of Marketing Your API:

1. Don’t be shy to do hand to hand deals.  The popular misconception is that with an API, I need to be “self-serve”.  Integration self-serve is different than 3^rd party interest.  Remember, the goal is to be self-serve, but the process of getting there can and will likely require doing deals with 3^rd parties and this can be a manual process that takes time.
   • For example, our first set of partners at Hunch took almost 2 months to sign and close, but the deals thereafter have been happening at a much faster clip as you refine the use cases and can refer to other blue-chip brands that have adopted the API.  We have seen an accelerated pace of inbound interest
2. Bowling Pin Strategy – cluster your outreach to a neighborhood of companies within an ecosystem that overtime can share overlapping interests.  The more you specialize in a vertical, the cleaner the story will be for your API and the more repetitive success stories will be to form a brand.
   • For example, at Hunch, our API is fairly flexible and can be used for a number of personalization use cases, but we have been focused on transaction-oriented environments because we want to show continued demonstration of the accuracy of the Hunch algorithms. 
3. Have a crystal clear view of what metric you are trying to solve. Are you increasing conversions, are you decreasing bounce rates, are you increasing time spent on the site, the number of pageviews, reg rates to newsletters, subscription rates, increase in CPM, CPC or CPA rates, etc
4. Once you understand precisely what you are solving, don’t be afraid to trade Revenue for Transparency to Analytics and PR.  It’s a common mistake of the human psyche to begin requiring revenue when you begin fantasizing about “what if I do increase conversion by 10%, then I should get paid NOW for it”.  This is a simple function of needing to “get paid for your time and to feel like you justified your efforts”.  But, try to avoid the temptations here and remember that your primary objective is market validation, PR and analytics.  Revenue will follow if you solve for those three missing variables.
5. Work with your partner, hand in hand, on the initial set of use cases and keep iterating until you are pleased with the outcome
6. Track and Analyze the analytics like a Ninja.  Uncover correlations within a partner and across partners.  Across the partners is the key trick to determine if you have a silo’d partner solution or a networked solution.
7. Secure PR rights upfront, have your partner write up Testimonials and apply the Double-Barrel PR approach (announce partner signings followed by the launch of your API)

Google, the posterboy for a scalable business, with their initial deals with Netscape, AOL and Yahoo is a great example of how them employed a similar strategy.  Shopping.com, Yelp, NYTimes, Weatherbug, BazaarVoice, Salesforce and Meebo invested in a strong business development effort before truly popularizing their self-serve platform to generate mass scale.

The other question that I often receive is what’s the right background for someone to employ this business development strategy.  When you are considering the right person or team to employ your efforts here, its important to recruit around product-focused business development talent.  Typically people who have had a hand in developing products, establishing creative use cases, analytics and certainly, a strong understanding of web technologies.  The new business development strategy to popularize a self-serve tool needs to move away from a sales-orientation and more towards product-orientation.

At a future date, we will also write on how to embed monetization into your API and how self-service has spawned true performance-driven business models based on value compared to licensing models based on cost structures.

Permalink | Leave a comment  »