Skip to content

Partners as an Extension of Product

Customers don’t want to buy your products, customers want you to solve their problems. This is an obvious statement, but it is worth repeating. Many times, to solve a customer’s problem, your particular product may not solely suffice.

You may have an incredible offering (and I’m mainly talking about technology here), but the simple fact is that customer problems are now so complex, no one offering can fully address them right now.

This is where strong product-focused partners can help and how a well-executed Business Development strategy can make partners an extension of your product, and a solution for your customers.

Be Market Driven

In technology, especially now with SaaS, there is no end to the number of other companies you can partner with. Some partnerships may be intellectually challenging, some may be outright cool, but the ones that are really valuable are market driven. In other words, can you quantify the real customer demand for the solution that you and a partner can offer. If there is real demand, then you have the basis for a successful product partnership.

Will Both Partners Invest?

Both companies need to recognize the market demand and be willing to invest product, engineering and marketing resources to build and evangelize the joint solution. Customer will be far more comfortable contemplating a joint solution if they hear equal commitment from the companies involved

To Offer a Solution, Must There Be a Deep Integration?

This is an interesting question and I actually think the answer is no. You and a partner certainly want to come to a customer with a solution that offers unique value, and two (or more) deeply integrated products may do that. But there are also cases where a reference architecture will suffice; showing how two or more products working side-by-side addresses exactly the customer needs.

Product Management builds the product that addresses many of the needs of your customer. Business Development complements this role by finding and building the partnerships that expand the product, and allows your company to come to a customer with a more complete solution.


StartupBD: The Integration is the Product

We’re in a postmodern era of software where the value of an application isn’t only from features it provides, but what new features it creates when integrated with other applications.

The role of the BD manager is evolving to look like that of a product manager and product marketing manager. But the “product” that needs to be built, maintained and marketed to prospects and customers is an integration. The challenge of the BD team and BD programs is they can build, maintain, market, and measure these integration/products at scale, and in an efficient way.

In any list of application capabilities, many of them inevitably will only be possible when the application is connected to other parts of the IT environment. An unconnected application and a rock in the middle of an open field are equally as awkward in their respective environments.

Sure, you could say that applications have always been connected to one another in some way. But with applications moving to the cloud coupled with the easing ability to create and manage APIs, IT software and hardware that were previously entirely disparate can now connect to share data and create new workflows.

For example, an HR system, a firewall, and a collaboration platform all offer certain value to customers. But when these three systems are deeply integrated and sharing data, new secure workflows are created and/or automated that the creators of the HR system, the firewall, and the collaboration platform could never have individually imagined.

But the customer imagines them because they’re feeling the pain. And the smart vendors learn to imagine them because they listen to the customer.

Gone are the days of the “Barney” partnerships when two companies made a PR announcement that they are working together simply to generate PR. Frankly, no one is fooled anymore; customers aren’t impressed by such announcements, to say nothing of the journalists who are expected to cover it.

BD teams (the good ones, anyway) now actively discuss customer use cases when contemplating an integration between their respective companies. Is there a real use case that can be jointly solved? Has the use case been validated by the market?

And as important, once the integration is completed, is there commitment from both companies to bring the feature/integration to market through marketing and sales activities?

Such is the rise of the customer validated use case solved not by a product, but by an integration.

Integrations therefore need to be created and treated as if they were products. A customer will often want to know not only what the application does, but how deeply it integrates with other applications and what new use cases created and solved by this integration.

History of risk capital in San Francisco

Although we often think of VC and risk capital as being a relatively recent phenomena in the Bay Area; starting during the 1950s and 1960s with the rise of the microchip industry and the birth of “Silicon Valley.”

But the culture of of risk capital extends far before that, all the way back to the 19th century!

I’m reading this great book San Francisco Stories (borrowed from a public library… yay libraries!!!), which is a collection of letters and essays by great writers on San Francisco.

One who was not impressed by the city is Anthony Trollope, indeed his letter is titled “Nothing to See in San Francisco”

But as he wrote his letter in 1875, he was amazed by the willingness of San Francisco entrepreneurs and San Francisco financiers to take risks on new ventures, something that he could not imagine taking place in London or elsewhere in the US.

The great commercial community is there [in San Francisco]… If a young man there can make friends, and can establish a character of honesty to his friends and for smartness to the outside world, he can borrow almost any amount of money without security, for the purposes of establishing himself in business. The lender, if he feel sure that he will not be robbed by his protege, is willing to run the risk of unsuccessful speculation.

(Although we need to continue to ensure the risk capital investments and investees increasingly are women, as well!)

Love your product, but Silicon Valley wants to talk about the money

My recent article in the Globe and Mail highlighting that while innovation is important, but it has to be coupled with a strong business plan and market adoption.

The weather here [in Silicon Valley] is warm but the culture is coldly capitalistic. If you want to talk about investment, be prepared to talk about return. If you want to talk about business partnerships, be prepared to talk about customer demand and market opportunity.

Love your product, but Silicon Valley wants to talk about the money

Find your mafia

Networking is a key part to success. You need to find your mafia, groups of people you can call on to help with business, advice or job hunting.

I try to find different mafias, some centered around my b-school friends, some centered around my old workplaces.

Coming from Canada, I also spend a lot of time with the Canadian mafia here in Silicon Valley.

Here’s an excerpt and a link to an article I wrote that talks about Canadians in Silicon Valley and our relationship to Canada

I’m from Toronto and I’ve been in tech for more than 15 years. A lot of my friends are also Canadians in tech. In fact, I got my last three jobs through my network of other Canadians in tech. I’ve done deals with other Canadians in tech.

We go to tech conferences together. We go to evening socials and networking groups together. Of course, there are always hockey and baseball games to go to. We know each others’ kids.

We do a lot of things you’d expect a network of Canadians in tech would do, except for one. We don’t live in Canada – we live in Silicon Valley.

The value of pitching a return home to Canada’s tech expats

StartupBD: Of APIs, BD and bad math

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.

StartupBD: Master of None

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.

%d bloggers like this: