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.
There are two ways that deals originate: inbound and outbound.
Inbound is when companies reach out to you in hopes of scoring a partnership. Some of the best deals can come in from press announcements, introductions from thoughtful friends, etc.
Outbound is when you put together a list of companies and try to get in front of them. Outbound is obviously much harder as you are on the side that’s trying to convince another company to work with you.
I have two thoughts on the inbound and outbound.
1) Not all inbound is good. Sometimes companies are fishing for information about the industry. Other times they are not the type of deals you should be focusing on. While it’s great to have companies reaching out to work with you, you need to be conscious of not wasting time, as time is the worst thing to lose.
2) I’ve seen companies become really popular and deal solely on inbound. This takes up all their time. They do very little outbound, and that is dangerous. I almost fell into this trap at Dwolla. We have a lot of inbound, some really great companies and people wanting to work with us. But I also have a list of companies I want us to work with. You can’t control which companies reach out to you, but you can control who you reach out to.
Bottom Line: Never stop reaching out to the companies you want to work with. Try to balance inbound and outbound. Both are important in developing your business.
Good developers are not only judged by their programming work but also by how they document that work. Good documentation helps bring others up to speed and makes a company more efficient.
The same can be said with business development. Good business development people keep track of all their meetings and developments by making meeting summaries and updating their pipeline.
When initiating new people on your team or leaving deals over at a job you are leaving, having poor notes or information about the deals you were working on can have major negative ramifications on the business.
I haven’t always, but now currently do a few things every day that will help when we eventually bring more people on board in business development roles at Dwolla.
Here are two important things I do:
Meetings Of The Day
Every night before I go to bed I write up a meeting summary for each meeting I had that day. This consists of the company name, people in attendance, summary of what happened, and next steps. I have one google doc running of all the meetings I’ve had since Day 1. If someone would join now their first order of action would be to dive in and read these notes.
I used Highrise at Aviary, and after a few weeks I decided it was worth getting for Dwolla. The only thing I am doing with Highrise is bcc’ing all my business emails to keep tabs on all the companies we are talking with. I go in once a night and tag the emails with who the people are, their company, and their industry. This way if I ever need to follow up on, let’s say, the e-commerce industry, I can go in and get a quick list of companies.
If you do anything else that helps you document your biz dev efforts please let me know by leaving them in the comments.
You can have the nicest slides and coolest demo but if you can’t back it up with numbers you will have a hard time closing the deal.
One of the most important things necessary for partnerships is being able to prove your value. Coming into a meeting and saying your company is so awesome because of X, Y, and Z. And then proving your awesomeness by showing the results of your actions.
If you are having trouble closing deals, it is probably because while you talk a good talk, the other side is having a hard time justifying taking a risk with you because you haven’t shown tangible results.
Go out and get those tangible results (usually via your standalone business) before approaching a third-party about working together. It will save you the time of trying to sell the other side on something that is probably not ready.
It’s been awhile since I have been a one man BD team. At Dwolla I have Michael on the platform team, but I don’t have the other roles-in terms of help and support (see this post).
There are a few core things needed to be successful in partnerships. The most outward facing one is having your company’s overview deck. This should help bring anyone, who hasn’t already spoken with you and gotten the “pitch”, up to speed.
There are also a few not outward things needed to be successful at your job. The two biggest are managing your pipeline and writing meeting summaries to bring your own team up to speed. Keeping up with these things up can be really difficult and you need to be sure to set aside the proper amount of time to write meeting summaries every day and update the pipeline at the end of every week.
Anyone have any good tips on being a successful one person BD wrecking crew?
One of the biggest issues in business development is prioritizing deal opportunities. Not all inbound is equal and sifting through that, as well as figuring out where you want to be is not an easy task. You can easily be caught in a perpetual irrelevant meeting/call black hole.
I like to analyze what I have today in terms of an offering. What type of deals can I do today? Who are the target companies?
Then I map out the next features we have coming out. Are any of them gamechangers? Do they make our product more desirable? Can we get companies to commit to integrating them for a potential launch partners situation?
I then put them all together in a google doc (typically a spreadsheet) and balance getting deals done today and upcoming features/partners that would make sense. There is a lot more that goes into this, but at a high level you need to find a balance of immediate and future opportunities.
How do you prioritize deals?
I had a post last week about what you should do when someone says no. In the comments section someone mentioned that there are times when getting a yes is actually worse than a no.
Completely agreed on the insight about hearing no when trying to partner. A bit of pure sales experience at some point in someone’s career is important to learn that ‘no’ could just mean ‘not necessarily for me at this time’, and learning how to maneuver those situations.
One random point would be how to deal with a “yes” in looking for partnerships. I can’t count the times that in a meeting someone said ‘yes’, but actually completing the deal took a tremendous amount more effort (bureacracy / approvals, etc.). Just as you shouldn’t get too discouraged by a no, that initial yes should also not make you think you’re already the king.
I totally agree. Getting an initial yes is a great feeling, but if you don’t take the proper steps to get the partnership live then it is actually worse than getting a no.
Once a company says yes, I like to map out the proper next steps to the promised land.
It usually comes down to three things:
What do we need to do?
What do they need to do?
What is the timeframe for both sides?
If you can map this out right after getting a yes, than you should be good to go.