In the cloud, everyone is making a connection.
Cloud software companies are working together to connect processes, to connect dataflows, to connect user-experiences, and to connect go-to-market strategies, all in an attempt to make users more successful with software, faster.
Cloud apps tend do one or a few things really well, and for what they don’t do, they connect into an ecosystem of other apps that do those other things. Unlike software of the past, cloud apps are architected to be rapidly deployed, and rapidly integrated.
“Don’t worry about huge, complex implementations,” they tell customers. “We’ll connect our software to your directory to your existing environment and it will all just work. The software is lightweight and integrated. Just log-in and you’re good. “
When integrations work well, a company’s data passes effortlessly from one app to another, letting end-users accomplish more tasks, collaborate more effectively, better manage processes and get more value out of their combined applications than they would from each application operating individually
How this happens is as easy as ABC. Well, A and B anyway… as in APIs and BD.
On the tech side, the responsibility for connecting to other software is handled via API, those carefully managed front doors that control the access of users and data from one app to another.
The human equivalent of an API is BD. BD is the sharp doorperson managing those front doors. What is the business model? Who can access the front door and under what conditions? At what price?
Never afraid to create hokey sayings around bad math, BD is always on the lookout for a great value-added partner to really discover how “1+1 can equal 3”.
Cloud software will only increase the need for both APIs and BD. Cloud software is easy to deploy, and therefore easy to rip out. Connecting via API to other software entrenches a cloud app within a customer’s environment, creating that elusive “sticky” factor we all crave.
But we crave sticky with a purpose.
Across the industry, smart companies have moved past the notion of connection-for-connections sake. Increasingly, APIs are no longer open but are governed by well-defined terms. Ecosystems can still be large and open, but the good ones are now better organized and exist for a defined business purpose.
Organizing these ecosystems is the responsibility of an ever more sophisticated BD function. BD is no longer measured by the size of their ecosystems, but rather the value those ecosystems bring to the company.
Successful BD people are coming up with ever more novel ways to sell the value of their company to partners and thereby build the highest quality ecosystem. With this ecosystem, BD has the opportunity to create new go-to-market initiatives that drive increased value for (1) their company, (2) their partners and (3) ultimately the joint customers.
Hmmm… It seems 1+1 really can sometimes equal 3.
One of the interesting challenges I’ve come across is sometimes figuring out exactly what does business development “own”? With other functions, it is more clear. Product owns the product, Sales owns “the number”, Marketing owns the message and so on. What does BD own? A strategy? A partnership? Sometimes maybe a number. And even if its ownership is clear, how BD achieves success often isn’t.
Often to achieve a BD-related goal, you need to partner closely with multiple functions; ie: Product/Engineering to help with an integration, Marketing to promote a partnership, Sales to share leads etc.
That is why BD is as much an internal facing job as it is an external one. To be successful, you have to understand the imperatives not just of the the business as a whole, but of individual functions. I sometimes think of BD an internal corporate diplomat, trying to get agreement and resources from multiple functions towards a single idea.
Here’s some of my guiding principles:
Brief early, brief often: Get your idea out there internally with all the relevant (and even tangentially relevant) functions to get buy-off and feedback. Yes, sometimes it takes a lot of time but it is worth it. If you’re going to be coming back to various functions for help or if you’ll be assigning them work, you better make sure you have their input and they feel invested in your deal.
If they think it, you’ve thunk it: Basically, do your homework and try to understand your colleagues’’ priorities and the potential objections. Know their individual imperatives and how your deal fits into them. Yes, your deal may be fitting into some larger corporate strategy, but how does it also fit into each function’s individual priorities. Don’t just pitch a deal. Pitch the deal internally and highlight the unique relevance to each function (again, Sales, Marketing, Product, Engineering… etc)
You don’t have to do everything, just make sure everything gets done: The two big mistakes in trying to get multiple things done to complete a deal is either trying to do everything yourself, or the opposite, which is just dumping tasks on people and assuming it’ll all get done because of the “strategic importance” of your deal. Neither approach works. Good BD people are always in partnership and working with functions to get things done. Sometimes it is rolling up your sleeves to do something yourself, sometimes it is sitting with a function and helping them prioritize what you need them to do. There’s an art to being flexible all while working diligently to a deadline.
I’ve worked on quite a few great partnerships at Hearsay, but this is one that I’m particularly proud of. I come from a long line of teachers so anytime my work contributes to education, I get a bit of a rush.
Maybe there is a teacher gene in me somewhere.
The American College is the leading post-secondary institution dedicated to training and educating financial advisers. Pretty soon these students will be using social to better reach out and connect with prospects and clients.
They’ll learn the ins-and-outs of social through a great new course offered jointly by The American College and Hearsay Social. The College is providing the forum and the credit, Hearsay is providing the content.
This is a great example of academia and industry working together to bring the latest in-demand skills to students.
There’s a lot the partnering/alliances world can learn from a well-run sales and marketing team. The pitch, the focus on results, and the need for a predictable, repeatable funnel-conversion system are all hallmarks of an efficient sales machine.
These should be the hallmarks of an efficient alliances machine as well, especially if the machine is focused on building and maintaining large ecosystem integration and go-to-market partnerships.
Here’s what I mean:
Partner to the Problem
Remember that scene at the end of “Wolf of Wall Street” when Leonardo DiCaprio is asking people to sell him a pen? In reply, his audience members talk about the virtues of the pen rather than the customer problem the pen solves. His point in the movie was that to sell, you needed to see the pen from the eyes of the customer and understand what problem the customer is facing.
The same is true in partnerships. Too often companies sell the virtue of their technology and why the whole litany of features on offer makes the company such an attractive integration partner.
What is lost is that partners, like customers, have problems too. If you’re encouraging a company to integrate their application with yours, then you need a solid business case that goes beyond the technology benefits and addresses real partner problems. How does integrating with your technology address a partner’s needs or, even better, the needs of a partner’s customers.
Do Sales and Marketing
The systems developed for sales to fill the top of a funnel and then move a prospect along to that final sale are all relevant for partner organizations. To build an extensive ecosystem, you want to have a strong marketing component to pique the interest of a potential partner and get them to interact with your company in some way (attend an event, download a whitepaper, etc.).
Once engaged, then there should be a process by which that lead can be passed along to an equivalent to an SDR who can qualify the partner and send them down the right track; ie: is this partner a high potential one who needs special care, or could they simply avail themselves of self-service modules?
If the partner is deemed to be high potential, then they need to be placed in the care of a more senior alliance professional who can ensure the partner get the sales, marketing and technical support appropriate.
The same process for passing along a customer from marketing to SDRs to a sales professional holds true in the partnering world as well; especially if the goal is to build a large partner ecosystem.
Grow and Tier the Partnership
A sales team will tend to have an account plan for a high-value customer. A sales rep will check in, understand what the customer is up to, and figure out how to upsell, cross-sell or just plain sell, sell, sell to keep happy the customer and grow the business. This is only achieved via an intimate knowledge of the customer’s business and business imperatives.
The same can be said for managing partners, especially for high-value partners. An intimate knowledge of the partner’s business will help you understand which of your offerings would be of most use to further build and expand their partnership.
Of course, you won’t be able to do this for all your partners but rather for the highest value ones. But if a partner is deemed highly strategic, then it makes sense to have a dedicated partner manager who is executing against a dedicated partner plan.
There should be a plan as well for partners that don’t merit a dedicated resource. There should be an automated or light-touch way to continue to develop those partnerships and find the ones that can move up the ranks and provide more value to your company.