I’ve always been internally conflicted about one aspect of partnerships. That conflict is around whether to selectively partner or try to partner with whomever wants to partner with my company.
In the past, I’ve mostly worked on product partnerships (i.e. an API). With product partnerships you typically want any and every company to integrate your API. I’ve used the Launch Partner Strategy (i.e. launching a new product or feature with multiple companies and use cases) many times with success (and also with failure). But now that I’m running SocialRank, which is more of sales than it is BD, selectively partnering is much more attractive.
I’ve thought a lot about the difference and here is what I think the pros and cons are of each approach.
- The right big-name partners can change the game for you overnight
- Get to focus more, less trying to manage multiple partners
- Creates intrigue and demand by being selective
- Less use cases to point to when trying to get more companies onboard
- Miss out on small-looking companies that can be really big
Partnering With Everyone
- Tons of use cases to show off
- Finding a partner that can only be described as a diamond in the rough (happened time and time again at Aviary)
- Optics look good (lots of interest)
- It is a quantity over quality play
- Usually (but not always) takes longer to close bigger deals
- Lots and lots of work
There is no “right” way to approach selectively partnering vs. partnering with everyone. It is very situational. I think if you have a decent sized BD team and have an API (as I did at Aviary and Dwolla) you can go big and small (partnering with everyone). But now that my partnerships team is small at SocialRank, being selective is the way to go.
What do you think about this topic?
I’ve written before about the four reasons why someone would want to partner with your company. They are: you’ll make them money, save them money, you’ll grow their userbase, or improve their product. Then once you determine what bucket you fall into, the question will be what are their priorities, or what is important to the other side. This will depend on where they are in their company cycle. Once that is determined they will want to know who you have done this (i.e. what you say you want to do) with before.
But there is one piece of the deal-closing puzzle that is missing from the above equation and that is “removing the friction.” If you can continually remove friction for the other side, the timetable of closing the deal will speed up by lightyears.
Just recently there was a brand we wanted to work with at SocialRank that seemed all into the product but for some reason was not moving forward with us. One of the people from the brand said something that tipped me and team off to why they were holding back. It was a big thing on their end but a small thing for us to add. They hadn’t expressed this properly to us but once we figured it out we decided to expedite the process of adding that feature. This is removing the friction of ‘yes we like it but can’t use it’ to ‘yes we are in!’
How are you removing the friction to close more deals?
I got an email from a recent college graduate this past week:
How many meetings does it usually take to close a partnership or what is the progression of what should be accomplished in each meeting? I’m referring to earlier stages where you are trying to make a name for yourself.
Here is the 3 meeting process I envision:
1) Exploratory, where you ask questions to understand the potential partner
2) Talk about partnerships, benefits, how it can help, answer questions about what each party does, etc., and follow up with a BD deck that outlines how the partnership would work
3) If they like what’s in the deck, talk about how to actually execute the details of the partnership in terms of finalizing details
Please let me know where this is flawed. Thank you, Alex.
This is quite close, but the truth is that some companies move quickly, others take time. There are many variables, including size of company, priorities (i.e. are you hitting on something they are actively trying to solve?), etc. I’ve had deals that have closed in the first meeting, and deals that have taken months. Just keep this in mind, and let whatever will happen happen. If you see the opportunity to close immediately, do it. If you sense it will take a long time, don’t push for a quick close (this will turn off the partner). Use your judgement!
When trying to express the relationship between a lead business development employee and a junior business development employee, the hunter-gatherer society analogy is best.
The hunter-gatherer society is one in which most or all food is obtained from wild plants and animals. The hunters hunt and gatherers forage for wild pants/fruits/grain.
Hunters, or the lead business employees, attempt to bring home the bacon by leading the efforts of closing big deals (capturing big animals) that will sustain the group or team for some time. Gatherers (or junior BD), on the other hand, focus on supporting the hunters by collecting small fruits and grains (small deals) and continuing the group or team’s momentum and sustainability.
In Business Development, the lead BD employee tries to take the junior BD employee under their wing to teach them to become a hunter. The gatherer in the BD structure is meant to be a short lived experience (think 2-3 years) and strong gatherers learn how to become hunters themselves. Because, let’s be honest, no one wants to be a gatherer lifer.
These five words: “Sorry you aren’t a priority”, is one of the most frequently used rejection responses people will hear when pitching/closing. Sometimes it is true. Other times you aren’t positioning yourself properly.
Try to understand what is important to the company you are pitching to. If they care about getting new users and your offering will help them get new users, harp on that. Make sure they understand how many users you can bring them and show them people you’ve done this with before.
It’s not only new users. Some companies might care about improving their product or making money. If you don’t help something that they are currently focused on, don’t be surprised when they say you aren’t a priority.
If you are truly not a priority it might make sense to go back to the drawing board and build a product that is something more companies find to be a priority.
Getting a “Sorry you aren’t a priority” sucks but if you really understand other companies and are honest with yourself about your offering you will spend your time focusing on opportunities where you are a priority.
For some, one of the scariest things to do in life is to walk away. This could be from a business development deal, a job opportunity, or just life in general. But I’m here to say, don’t be afraid to walk away. Sometimes walking away is the right thing to do.
I used to be terrified of saying no to a deal. Walking away from a deal or offer because the terms don’t make sense for you is not only smart, it’s the right move every time. Now, it is a lot easier to walk away when you have nothing to lose. So your goal is to put yourself in situations that you have nothing to lose by walking away.
One of the obvious ways to do this is to give yourself many options. If you are trying to close a deal in a certain vertical, speaking with many competitors in the space will help. This way you can be fine with saying no to an inappropriate deal.
It’s hard to walk away. Sometimes the downside seems infinite. But that’s not always the case and you shouldn’t be afraid to walk away when something isn’t right for you.
I’ve learned the hard way, when attempting to do a product partnership with another company (i.e. wanting them to integrate your offering) it is best to avoid people in business development roles. Business development can be great in many aspects, but in this area they will slow you down.
What I like to do is map out what an integration would look like. Who is needed to make the integration happen? It is usually a combo of product and engineering folks. If you have a strong offering that directly helps your prospective partner, you will go from zero to integration much faster by going directly through them.
Bottom line: In terms of product integrations, it’s a lot better for the product/engineering team to recommend something to the business side of company than the other way around.
When working in business development and partnerships at a startup, with a product integration solution, you are always looking to the next deal. There is never time to rest. You typically have an API and you need to hand hold the next partner to get their integration up and running.
This is not to say you can’t enjoy the wins as they come. Enjoy them. But remember with every new deal the expectations get higher, the numbers need to continue to go up, etc.
For all the glamour and sexiness that comes with working on the business side of a startup, the reality is that you are only good as your last deal and there is very little time to rest and enjoy current success.
I’ve tried everything to manage my biz dev pipeline. I use Highrise to track emails, Google Drive to track companies (spreadsheet) and write up summaries (docs), and Trello to track feature requests. There is no one solution for all.
I’ve been wondering how other teams track and manage their pipelines. Can anyone chime in here and share in the comments what they use and how they use it?
There are a ton of reasons to do a deal. Maybe you’ll make money. Perhaps you’ll grow your userbase. It could be that you’ll increase your exposure. Or possibly improve your product. But for all the reasons why you should do a deal, no one talks about the reasons why you shouldn’t.
Here are three reasons why you should say no to a deal:
You don’t get along with the other side
This reason is fairly obvious but needs to be stated. This is not to say you hate the other side, but you don’t necessarily work well with them. Maybe they don’t respect you, maybe you don’t respect them. Either way, working with people you don’t get along with is a recipe for disaster. Before going too far- kill the deal if you anticipate a long-term headache.
They want too much customization
I’ve often experienced this. A company wants to work with you, but only if you do X, Y, and Z for them. And Y is going to take you a few months and you’ll have to delay that really important feature or product release to re-prioritize for this big company. Unless you’re going to make enough money to justify it, kill the deal. Focus on building the scalable product, rather than the one-off for a big co. Big companies aren’t used to hearing no from startups, so you never know, they may chase you even further, offering more money or compromising and using your existing product. Unless that happens, kill this deal.
Short term win, but long term lose
There are some deals that seem like they are going to be awesome. Some may live up to the hype, others are short sighted and are long-term losses. Here is an example: a big company is going to integrate your offering that will improve their product. Maybe by a lot, maybe by a little. You close the deal and everyone is happy. Now when the big company attempts to integrate your offering, they screw the pooch and the integration is off. Maybe they put your offering behind a drop down. Maybe it’s something else. But the bottom line is NO ONE IS USING YOUR PRODUCT. Now, maybe this is about your product and you need to fix that, but at the end of the day it is on you. You closed this awesome deal but long term it turns out to be a lemon. If you are working on a deal and it gets to the actual integration/promotion part and the other company is going to do it wrong: walk away. Kill the deal. I’ve done this (walked away at this stage) a few times and while it can be painful, I’m confident it was for the best. I would have been spinning my wheels for months and it would have been a huge time-sink.
On the flip side, there have been times when I’ve done the deal before in the above scenario, and know that it ended up being a colossal waste of time. I had no one to blame but myself. You live and you learn.
All in all, these are three solid reasons why you would kill a deal. I’m an advocate of working on good things and only terminating deals if they will be detrimental to you or your business. Proceed with caution.
In Business Development and Partnerships you will hear a similar feedback every day: “If only your product did this….we’d integrate/partner/etc.” This leads a lot of companies to pull themselves in five directions at once, and lack of focus is one of the biggest reasons companies fail. This also turns you from a startup into a custom development shop. The worst thing you can do is go from being a startup to a custom development shop while still thinking you are a startup.
However, there are two reasons why you would spend time and effort to build something into your product that someone is asking for.
Many companies have asked for the same thing
I have written before about talking to as many prospective partners as you can before you build a product. This guarantees that you will have a market for something before you build it. If you talk to 100-200 prospective partners, building the right product will end up with 10-30 launch partners. “If only your product did this…” becomes something that your product should do because there are tons of people/companies that want it.
A big company has asked for it (and there is a contract)
This is when things get tricky. You really want to work with that big fish but they’ll only work with you if you build the thing that they want. Oh, and that thing is going to take you a month or two to ship. I remember working at a previous company, we had a lot of people asking us to build custom things. Our CEO smartly decided that at that point we weren’t going to do that. We were going to build a product for everyone and only once we hit a certain level would we even consider building specific things for companies. It worked out well and eventually those bigger companies used the product we built as it was because it became the standard in the space.
The only exception to building for a big company is if it wouldn’t take a month or two to build (any more than a week’s project can be very detrimental), and if they’ve put in writing that once you build it, they will integrate/partner. Only then, would I recommend building what they want.
Remember: In startup-land, a wasted month or two can derail your entire company. Stay focused, ship great products, and build for the masses.
One of the first posts I ever wrote (back in December 2010) was about compounding introductions. The concept is that if you get an introduction to the right person, that introduction can lead to multiple introductions and have a positive compounding effect.
The same concept happens with partnerships. I experienced this first hand at Aviary and now again at Dwolla. Typically when you have someone integrate your API, if it is done well, other people will take notice. If it is relevant and helpful for them, they will also want to integrate. And on and on.
This is why I like launching new products WITH companies rather than just the product by itself. While this might delay the launch of a product by a month or so, when people see the integrations it has a compounding effect. Launching the product alone, with no integrations (if your business is partnerships/integration-driven), is not ideal as companies want to see who you are already working with and where they can use it today. There are no good excuses, from a biz dev/partnership perspective, for why you can’t point to anything.
Bottom line: Launch integrations with partners. Those partners will help compound integrations and validate your business even more.
When working in business development and partnerships at a startup company where growth is driven by partnerships, you need to assume that deals will fall apart all the time. It’s not to say that you are bad at your job or you messed up, just sometimes the timing is off or your offering is not up to par yet.
I don’t want to sound like a ‘Debbie Downer,’ but I think, because of this, it is good practice to do the following:
1) Guard your team (not biz dev team, but engineers/product/design, etc.), and don’t ‘talk up’ any big deals before they are closed and about to go live. Mention them in meetings and make sure people are aware you are having conversations with X. However, don’t sell it to your team as a done-deal. While you may want the team to know you are close and doing a good job. 5 out of 10 times, the deal will fall apart.
2) Don’t depend on any specific deal to make or break your company. I’ve seen companies do this for deals and acquisitions and it never ends well. Make sure you have 5+ deals that can ‘make your company’ so that the chance of one actually going through can be very high.
3) Actually trick your mind into thinking the deal will fall through. By doing this, you prepare yourself to better deal with rejection. Plus, if you think you are going to lose, then you have nothing to lose by going out and trying your hardest to make it happen.
Assume the deal will fall apart, but do everything in your power to make sure it doesn’t.
Where they’ll never say you cannot stay
Come and play oh, my hideaway
Someday everything will be okay
- “Hideaway” by Passion Pit
This past week I got rejected big time. Something that was 99.9% done ended up balking. It put me in a major funk for a full day. I worked two full days on a solution, but alas nothing.
(EDITORS NOTE: We actually found a way to save the deal (if the folks involved are reading this, you rock!)- the article is still good and I’ve been involved in other deals that haven’t been saved)
Shit happens. In business development deals fall apart. You try to move on. If you let it immobilize you then you will continue to fail. You need to remember that for every Pepsi there is a Coke. The best thing you can do is go out and kill it (in a good way) with another company (or multiple companies) and make the company that passed on you come back begging to work together.
At the end of the day, the difference between winners and losers in life is how they deal with rejection. Winners thrive. Losers hideaway.
When dealing with partnerships you should be categorizing them by how big they are and the probability that you will close them. The sizes range from small, medium, to large. Probability ranges from low, medium, to high.
When looking at your pipeline you should focus on the deals that fall into the medium and high range on the probability column, and the medium and large range on the size column. This should be fairly obvious but you would be surprised at how such a simple concept gets overlooked.
While this is easier said than done, this should be a guiding light. If you have no partners for your product (when your strategy is partnership-driven), then focusing some attention on getting a few high probability and low size should be the first step. But once you have a few notches on your belt, it is time to focus on the high/medium probability and large/medium size deals.