Building software products is hard. Building cross-product user experiences, where two otherwise separate software products combine to provide a joint solution, is really hard.
Yet, this is what’s required in the era of ecosystems.
You do need to build an exceptional software product to be successful. That’s always been a minimum requirement, but the minimum is no longer sufficient.
There’s massive potential for co-innovating with technology partners to jointly solve really hard problems for users. Doing this hasn’t always been “a given,” and now it’s one of your biggest opportunities for growth.
But, this opportunity does not come without challenges. This is an unfamiliar motion for most software teams. Even among those who have been successful with co-innovation, it’s rare to have scaled that success.
In this post, I want to talk about why and what can be done about it.
Reason one: Software products tend to be built behind closed doors
You raise some money. You hire a few developers. They set up a private Git repository, and they start coding.
From day one, most software teams build in private.
There are many valid reasons for this. Most products aren’t open source, nor does open source fit their business model. Building in private protects intellectual property, which can easily be ripped off, even with proper documentation in place. See Silicon Valley for details.
Plus, if you’re building SaaS, who outside cares what the code looks like?
Yet this perfectly reasonable idea behind building in private is exactly what causes friction when you try to build some parts of the product (e.g. integrations) with someone else.
Product and engineering teams who operate as a black box, often leaving the partnership teams on both sides to be the messengers, put themselves at a disadvantage. They don’t allow some of the smartest people in their respective rooms to come together and co-create, which is exactly what’s required to build truly innovative joint solutions.
What to do about it
Your product may not be open source nor may the concept play any part in your overall business strategy. However, your team (partners, product, and engineering) should learn open-source principles. You should be intentional about where you can include the OS operating model in your tech partnership program.
The tools and workflows your product and engineering teams already use are likely already derived from open-source motions. This philosophy is built into the DNA of the web, and its best practices tend to work their way into the DNA of commercial companies, especially those who aren’t big legacy enterprises.
It’s because building software in public with people from all over the world who rarely if ever actually meet one another is a challenging governance problem. Thus, really good software development practices have emerged that now get used even when the team sits in a room together. The best engineering teams adopt such practices.
Think about what parts of your product development process can be partially opened up to your partners’ product teams. Operate “kind of open source” to allow those teams to work more closely together.
This will help you to use the principles of open-source software and understand how it is built for joint solutions with tech partners.
Reason two: Separate fiduciary responsibilities
Tech partnerships are about two or more companies coming together to jointly solve a customer’s problems more effectively than they could do individually. But, the reality is that partnerships are made of separate companies, with separate investors, separate boards, and ideally somewhat aligned but ultimately separate goals.
In more technical terms, each of those companies has separate fiduciary responsibilities to its shareholders and to its individual relationships with customers.
This immutable fact can cause friction between partners. Often it shows up when determining investments to be made by both or when navigating separate but connected relationships with customers.
Here’s a classic example: A small upstart forms a tech partnership with an established ecosystem hub product because they are able to expand that product’s capabilities in a specific way. After years of a solid partnership, the larger company decides to build its own feature that renders the smaller company’s solution mostly unnecessary.
Can you blame the bigger company? Strictly speaking, if they assessed that building it themselves was best for their business, they kind of have the right and responsibility to do it. It’s not an easy conversation, but it’s a common one.
The bottom line is, even in the most successful partnerships, separate companies will do what’s best for them. As long as the partnership aligns with those interests, it will continue successfully. If it no longer aligns, things will change.
What to do about it
You can’t change the fact that partnerships are fundamentally made up of separate companies, but you can acknowledge and plan for it.
When assessing a new tech partner opportunity, try to be as upfront as you can about your intentions. What do you hope the joint solution will do now? What about in the future? Do you plan to provide your own function that will replace it?
You may not be able to provide 100% transparency, but the more you can, the better. It’s not in either party’s favor to invest in a partnership that has an unexpectedly abrupt end.
That said, it’s quite alright to view a partnership as a temporary relationship. You aren’t fusing yourselves together for all time. If this is a “few years” thing, then be clear about it upfront.
Additionally, when you set up your partner agreement (formally or informally) try to design balanced incentives. Incorporate checks and balances with how you decide to operate together, so you’ve both got enough skin in the game.
Setting up a situation where you jointly invest time and resources in building the joint solution (my first point) is a good way to start. It prevents one side from putting too many eggs in the basket at the outset.
Reason three: Risk aversion
Tech partnerships, like all business decisions, are about balancing risk and potential reward. You can never know for sure that a partnership will work out.
You have finite time and finite resources. Your partnership, product, and engineering leaders must be discerning about where they make investments. Building a joint solution with a tech partner is no exception.
Making matters harder, despite today’s growing enthusiasm for partner-led strategies, many partnership teams are fighting for budget and are constantly required to prove their worth to the rest of the organization.
Building a deeply integrated joint solution with a tech partner has huge potential upside at the risk of a lot of downside.
We’ve all worked through those partnerships that took tons of time and money and ultimately failed. It’s really unfortunate for everyone. It can cost jobs.
All of these facts can encourage a tendency toward risk aversion. This can slow or even stop potentially valuable tech partnerships dead in their tracks. Risk management is important–no one should be reckless. Risk aversion can limit your opportunities.
What to do about it
The Lean Startup taught product teams how to build software iteratively. You start with small hypotheses and invest small amounts in products or product features in order to learn if those hypotheses are true. (The term, which is very often misunderstood, is the “minimum viable product.”)
This same philosophy should apply to tech partnerships. Think in terms of the minimum viable partnership, then grow from there.
Ideally, you have a big vision for the kinds of deeply integrated product experiences you want to create with a partner–even better if with many partners. However, if you and those partners try to boil the ocean, it’s almost certain to be a failure.
Instead, use the big vision for orientation but deliver small. Start with just enough of the partnership relationship and the cross-product experience required to support it.
See what customers think about it. See what feedback they have. Then, incorporate that feedback into the next batch of small iterations. Build partnerships and the integrated product experience piece by piece, even if that means that sometimes you have to throw away bad ideas (this is a good thing).
You can’t eliminate risk from the equation, but building a tech partnership and an integrated product experience iteratively will help to manage the risk. It helps to ensure you only spend big where the juice is worth the squeeze.
Prefer to listen? Subscribe to our nearbound.com Audio Articles Podcast. Text-to-speech provided by our partner Voicemaker.in.
