You’re hardly short of Ideas for your product's latest release, but putting that to execution mode and building it is a tough decision to make. Then again why build when you can simply reuse someone else’s software and leverage their expertise?
In this article, I've compiled insights from multiple conversations with various stakeholders involved in the decision-making process within a software product company, ranging from product managers, developers, architects, and procurement folks, among others, and the "decision" in this segment is a classic. "Do we build or buy this feature?" This question will, at some point, become unavoidable for every software company out there. This article aims to help think through that process, I’ll touch on these 3 areas;
Why buy rather than build?
Things to look for when partnering with an OEM
Why choose WSO2’s Software OEM program?
Why buy, and not build?
The decision to buy is more or less an easy one for startups and to a great extent, larger enterprises as well. Product managers make these decisions regularly and with sales targets to achieve, compliance-based opportunities in the market, impatient customers, and the urgency to enhance the product’s overall value proposition with features and functionalities that end-users expect out of the box, the inclination is to almost always “buy” rather than build a feature in house. If the feature you need is not your core competency, you should certainly consider investing in an off-the-shelf product. That being said, buying isn't a 100% hassle free decision. You’re going to spend time evaluating proposals, prototyping, integrating, and supporting to some extent anything you buy from the shelf, but when you’ve got the right OEM onboard - the return on your decision will prove to be 100 fold.
When faced with such a dilemma, an accurate costing done in terms of time, resources, and lost opportunity can make this an even obvious decision. The opportunity cost of building and maintaining something that isn’t your core competency, is massive. When you choose to build, you also undertake to manage and maintain what you build - which will burn off hours from your engineering and dev ops teams that could have been spent on a new opportunity or a new core competency feature and, needless to say, Opportunities don’t come by easily and when they do, you need to have something tried, tested and stunning to offer. Off-the-shelf products will save you time (and time is money) from; A. Engineering POV, dedicate your precious engineering resources to better use and B. accelerated time to market. Building anything that isn’t your core competency is basically wasting 2 of your most valuable resources. Your people and their time. Keep in mind that your “non-core need” is someone else’s core business.
Also remember, When you choose to buy, you’re buying more than just a piece of software: You’re investing in years and years of engineering resources and cutting edge technology with all the bells and whistles in that space. In addition to engineering expertise, you’re also investing indirectly into your team by choosing the right OEM. The OEM themselves will enable your team to increase efficiency from an operational perspective and help them understand the nuances of the technology, best practices and most importantly add value to your customers’ digital experience overall. Also partnering with the right OEM could result in multiple cross-sell and additional revenue sources by way of referral fees and commissions. In some cases, the OEM of your choice could be a market leader with awareness built already, that you can leverage, perhaps, open opportunities for you.
Things to look for when partnering with an OEM
This serves to be a guide to those who've chosen to buy and are on the lookout for an OEM (Original Equipment Manufacturer).
What is the OEM's short and long-term vision/ strategy? Is it a SME looking to accelerate growth and be acquired by a potential multinational with competing interests? - This may necessitate a change in product strategy, licensing, support, and pricing. Or I s the OEM already a part of any larger organizations that could be considered direct competitors? Keep in mind that collaborating with a competitor is not a crime as long as there are clear boundaries and terms in place.
You most likely have a list of 20 features you require today, and there are 200 OEMs that provide those features out of the box. What matters most, however, is the software's extensibility and scalability. What you don't want is to be stuck with an OEM that can't/won't support a feature you requested 6 months later, or that can't scale up to meet the influx of your Black Friday sales. That means you'll have to either switch to another OEM or build it yourself from scratch, not to mention the millions of dollars in lost opportunity cost.
What is the current commercial/pricing strategy of the OEM? Is it determined by features, usage, or something else? Are they adaptable enough to meet any of your own pricing mechanisms/parameters/models, or are they restricted to a single pricing dimension with no flexibility? You want to avoid situations in which you are selling a "triangle" to your customers but your OEM partner is trying to sell you "squares."
OEM market awareness, recognition, and success
Has the OEM established user communities and garnered recognition from industry analysts or other awards? These are excellent methods for obtaining unbiased market insight. A company's customer base can reveal a lot about it. What you're ideally trying to narrow down here is what types of customer segments they thrive in - is their base more SME or larger, Fortune 500 type customers, or do mission critical businesses white label their software? Has the OEM's software been designed to address similar use cases in the same industry?
Upsell /cross-sell opportunities
You could carve out a contractual segment that incentivizes the OEM to promote your own product to their potential prospects and market bases, depending on the OEM. Most enterprises contact OEMs in search of a single piece of the puzzle, such as a gateway for security or an ESB for mediation, but in many cases, what they're really looking to build is an e-commerce site, a telemedicine app, or an AI-based warehouse management system - which could be the exact problem "your product" intends to solve.
While you front end your clients, it is critical that the OEM's support model aligns with the support policy you have committed to the end clients. What type of support models does the OEM offer? Is it a one-size-fits-all support model? Are there any special SLAs that must be met? And what are the OEMs' policies on product life cycle support duration? A scenario to avoid is one in which your duration of commitment to supporting a release of your own product differs significantly from that of the OEM.
There are industry-specific certifications required for product components and deployment environments, depending on the industry. Certifications such as ISO, HIPAA for healthcare, Open Banking PSD2/ PSI for the payments industry, and so on. If you are in any of these compliance-based industries, an OEM that can support these compliances or commit to achieving them is a must.
When partnering with an OEM, there is much more to consider than just the contractual and commercial terms. Ideally, you want to know what the OEM's strategy is for training and development, as well as what value additions have been offered to ensure the success of your project. Is the OEM looking to invest in your company by ensuring the engagement is successful, or are they looking to profit from everything? After all, the OEM will only make money if you generate sales, so it is in the OEM's best interest to ensure successful adoption, installation, pre-sale, and post-sale activities.
Why choose WSO2’s Software OEM Program?
WSO2’s platform consists of the only leading open source API Manager, that lets you build, integrate, and expose digital services securely as managed APIs in the cloud, on-premises, and in hybrid architectures. WSO2 Identity Server is the most developer-friendly open source identity and access management tool that embraces a developer-first approach to consolidate IAM and CIAM capabilities. WSO2’s Open Banking and Open Healthcare solutions are comprehensive industry solutions that help organizations in those industries to adhere to standards & compliance-based regulations while ensuring minimum disruption to gross margins and business operations.
WSO2 OEM program is designed to ensure enhancement to your product value proposition by white labeling and embedding WSO2 technology with features & expertise you don’t have in-house, guaranteeing you the least impact on your gross margins with no undue risks.
Why WSO2’s product stack?
- White label, redistribute, and embed WSO2 API Manager, WSO2 Identity Server, and WSO2 Enterprise Integrator within your product.
- Custom scalable commercials that mirror your commercial strategy, and engagement model to integrate, implement and roll out your product.
- WSO2 products are highly extensible and built to be deployed anywhere, including metal servers, cloud, hybrid, and multi-cloud environments, as well as traditional architectures and cutting-edge MSA-based layouts.
- Save years of development time and effort by bringing your product to market instantly while improving its value proposition.
- WSO2's API Manager and Identity Server are both industry leaders in their respective fields, with leading analysts recognizing them based on a variety of criteria such as product offering, road map, commercial strategy, and so on. (See links for a detailed breakdown of evaluation criteria and how we compare to competitors.)
- WSO2 named leader in FORRESTER WAVE™: API management solutions, Q3 2020
- WSO2 is a Strong performer by FORRESTER for customer Identity and access management Q4 2020
- WSO2 overall leaders for KUPPINGERCOLE leadership compass: CIAM Platforms, 2020
- Bespoke engagement model that aids in the validation of the technology and commercial fit through WSO2 training, workshops, and architecture reviews. Test out WSO2's Quick Start program. For time-pressed teams, WSO2's quick start program comes in handy. It starts with identifying business use cases, then finalizes the DA/SA and ensures delivery of a thin slice of your end solution deployed in your lower environments.