How to Build an Integration-As-A-Product – PM Approach | HackerNoon

[ad_1]

When a product or service reaches its “tipping point” in terms of market saturation and no longer provides opportunities for further scaling, it becomes a signal for a business to think about shifting to a business ecosystem strategy. Why not leverage someone else’s expertise and pay a fee for their product if it’s not your core competency?

\
For example, why not use an external solution to handle customer service inquiries? Or for sending SMS to customers and charging their cards? There are plenty of options on the market that will probably handle this better and cheaper than an in-house solution.

\
This strategy involves a deep analysis of the business environment where partnerships, collaboration, and innovation become key to achieving sustainable growth and remaining relevant in today’s dynamic and competitive environment.

\
This approach to goal setting assumes that today’s business ecosystems are seen as a dynamic and constantly evolving landscape, shaping new customer value through mutually beneficial partnerships, synergies, and diversity of solutions provided, while maintaining the identity of the digital product within the larger system.

\
Superapps is a good example of this.

\
==In breaking down the barriers between industries, super-apps have the power to meld experiences that were previously distinct. While such apps may not replace every app on a Western user’s phone, they will likely shake up consumers’ expectations for a mobile-first experience. Through cross-service insights, new partnerships, and embedded payment capabilities, tech platforms and service providers of all kinds have an opportunity to streamline the smartphone user experience, build customer loyalty, and differentiate their brands.==

—by Gopi Billa, principal; Zach Aron, principal; and Mark Purowitz, principal, all with Deloitte Consulting LLP

\
However, you want it to be part of your product, so you’ll need to integrate it. This is where APIs, SDKs, web frames, SSOs, and microservices come into the picture.

\
In this article, I’d like to elaborate on a trickier aspect: when the core value of your product is built around integrating with other partners, especially those who have never provided their product to an external market before.

\
The insights below will be based on Gett’s experience in building an international network of transportation services on a single platform. Our goal is to provide a single platform for booking and managing transportation for corporate customers with the ability to travel anywhere in the world.

Glossary

API (Application Programming Interface) is a set of methods and rules by which different programs communicate with each other and exchange data.

\
All these interactions take place with the help of functions, classes, methods, structures, and sometimes constants of one program that are accessed by other programs. This is the basic principle of how APIs work.

\
Let’s say you buy a movie ticket using a bank card. During the purchase, the terminal accesses the API of the bank that issued your card and sends a request for payment. And if you order a cab through an app, it also accesses the payment system through the API.

\
**SDK (**software development kit) is a set of platform-specific tools for developers.

\
Components such as debuggers, compilers, and libraries are required to create code that runs on a particular platform, operating system, or programming language. SDKs contain everything you need to develop and run software in one place. They also contain resources such as documentation, tutorials, and guides, as well as APIs and platforms to accelerate application development.

\
SDKs allow you to use third-party tools and resources in your environment. An application programming interface (API) is a mechanism that allows two software components to communicate with each other using predefined protocols.

\
You can use APIs to communicate with existing software components and integrate pre-defined functions into your code. SDKs can include APIs and several other resources for the platform they support.

\
Similarly, you can use SDKs to create new APIs that you can share with others. B==oth SDKs and APIs make the software development process more efficient and collaborative.==

Product Manager – Multipotential Specialist

Every large company was required to have an internal transportation management department responsible for finding, selecting, and signing contracts with transportation service providers in every country and city where there was business. Picture this: up to 20 suppliers per country, talk about a maze!

\
Now, let’s dive into the world of transportation services. The market for transportation services is quite fragmented. And while this article is mainly focused on product integrations and positioned from a product manager’s perspective, it’s important to note: integrations require multiple commercial aspects to accommodate business interests.

\
==So, here’s the deal – while I guide you through the product manager’s lens, I’ve got to throw in a little reminder. Some of the steps we’re about to bust through will need a commercial specialist to tag along. It’s like a buddy system for business interests, you know? They’ll be right there, side by side, joining the adventure.==

To embark on this journey, start by defining the landscape and your requirements. If you’re venturing into a new niche, the initial step involves understanding who the major players are, how they currently operate, and identifying potential integration points.

\
==Here’s a roadmap to guide you:==

1. Market research: Conduct thorough market research to identify key players. Utilize public data or consult reputable agencies like Deloitte for insights into market shares.

   \

2. Client engagement: Engage with your clients directly to understand their preferences and expectations.

   \

3. Current players: Identify existing players in the market with accessible human interfaces such as websites, mobile apps, or customer service lines.

   \

4. Supplier capabilities: Map out what suppliers can send and receive through these human interfaces.

   \

5. Client journeys: Chart the client journeys for the products offered by these players.

   \

6. API exploration: Seek out players who already provide APIs for connection. APIs streamline integration processes and enhance interoperability.

   \

7. Mapping human interfaces via APIs: Build a comprehensive map detailing what functionalities are accessible through APIs on the identified human interfaces.

   \

By following these steps, you’ll be equipped with a solid foundation for navigating the complexities of integration within your chosen niche.

\
This exercise will help to achieve:

✅ Have an idea of how the industry works

✅What are the average product/service offerings on the market

✅How your platform can disrupt the market (current weaknesses)

✅What are the current API possibilities of the players and what they lack vs the native products

✅Respectively, what to ask later on to add from them

✅What can be asked from the other players in the market to meet the competition

✅What can you incorporate into your product already

\
Based on your research, the next step is to define the vision and future capabilities of your product (hints will be listed below in the insights section). Make sure you cover both the standard market features and what makes your product unique. This should be a clear set.

\
It is then important to identify what can be implemented within your product and what will need to be provided and handled by suppliers.

\
The latter should be used to identify gaps in the current API capabilities of each of the selected vendors. In this way, it will be possible to formulate a “request”: what you want them to build in exchange for the business opportunity you provide.

Reaching the Market – Pitch

Entering the market is akin to pitching – it’s a delicate dance of integration.

\
Think of it as an intricate tango of companies intertwining through APIs. It’s highly unlikely that suppliers will just hand you an API; instead, your company needs to seamlessly integrate it into its API framework.

\
Your product must be versatile enough to support a myriad of unique integrations with each supplier standard. Consequently, any advancements in the supplier’s API will lead to subsequent integration efforts on your company’s part.

\
Essentially, the next move is to captivate the players with your product, showcasing its potential impact on revenue and instilling confidence that your offering won’t disrupt their business. It’s about painting a vivid picture of collaboration through API integration and ensuring a harmonious partnership in the market ecosystem.

\
The key recommendations would consist of:

1. Be clear on your purpose: how exactly you’re going to help their businesses. What segment of the clients your platform can bring to them, and why it’s more efficient to achieve that through you, rather than by themselves?

   \

2. You need to have the names and numbers: the suppliers will be keen to work with you if you can share some of the client names they are familiar with and some projections of the numbers that you can potentially bring to them.

   \

3. Start with smaller, more desperate players: they will probably be more keen to try something out to scale the business than the larger, more established players.

   \

4. State what is the ask from them: specifically, what do you want them to build to start the mutual operation?

   \

5. Make it as effortless for the suppliers as possible. The likelihood that someone will invest in an API from scratch by their resource investment is probably small. Therefore, someone who has an API already would be more keen to perform that. Alternatively, you may suggest to fund the development.

   \

6. Tip: funding does not necessarily have to be a one-off payment. In situations where you can guarantee future volumes, it could be possible to convince a supplier to provide payback as a per-transaction or (monthly) cycle commission.

   API Journey. POC/Wizard of Oz

   Entering a market where creating API connections seems like wizardry can be daunting. Imagine being on the cusp of market creation, with technology not quite ready to solve the problem, perhaps due to cost constraints.

   \
   In such a scenario, leveraging human resources becomes your starting point. By manually processing client requests and utilizing existing supplier channels for inquiries, you can establish connections through:

   \

• Phone calls

• Email communication

• Booking via their applications

  \

  As your product gains confidence and demonstrates demand and financial viability, partners are more likely to join the journey.

  \
  by Max Sadontsev

  \
  🚕Execution plan

  Your partner shook hands, agreeing to collaborate on API integration and contribute to the product’s development. It’s crucial to monitor the partner’s development as if it were your own project, implementing robust project management procedures.

  \
  The linchpin of this partnership is communication: clear, transparent, and proactive. Utilize project management skills within your company, adapting them to bilateral projects. Establish KPIs, milestones, timelines, and roles and responsibilities for both parties. Share project files with your supplier, schedule regular meetings, and address potential issues during the process.

  \
  🚕Growth

  Successful partnership precedents should motivate other suppliers to join your platform. Utilize the experience gained, both individually and collaboratively, to persuade more entities to come on board.

  \
  As you become the standard API in the market, business growth will make suppliers more inclined to integrate with you. At this stage, creating a unified, standard API protocol for your business and offering its integration to suppliers makes adding new partners a routine Plug’n’Play process.

  \
  🚕Self-service

  When the number of suppliers reaches hundreds or thousands, consider transitioning from manual commercial and operational processes to self-service tools for suppliers. Create a platform where they can easily read and sign contracts, provide their API credentials, and define the services they are willing to offer. This self-service platform can also enable suppliers to handle accounting and automate invoicing for comprehensive partnership coverage.

  \
  🚕Sharing technologies

  A piece of advice gleaned from the taxi market, applicable across various industries like hotels, air travel, etc., is that many companies buy/license the same technology from third parties. Developing a single API can cater to multiple businesses, provided commercial relationships are aligned.

  \
  However, it’s essential to note that software providers may be protective of their revenue streams in such deals. Additionally, larger businesses are more likely to use proprietary or highly customizable third-party software.

  \
  ==Challenge: lack of technology==

  Some players may lack the technology for integration. This can be addressed in two ways:

1. Continue employing the Wizard of Oz approach.

   \

2. Propose these companies transition to existing market solutions, which may already be integrated. You can negotiate with software providers to offer their solutions on more favorable terms for such companies.

   \

   In navigating the API landscape, combining the magic of human touch with strategic technological solutions can lead to a successful journey down the yellow brick road.

   Summary

   It’s essential to highlight:

   1) Defining the format of integrations is key to success

• The more complete the list of requirements, the less likely something will fail.

  \

• Partners are more likely to invest in integration capabilities during initial development than in the future because they likely have their own roadmap of priorities.

  \

• Accordingly, any new development in the future will require partners to internally prioritize their plans and explain the implications.

  \

  2) Make sure the requirements list includes both functional and technical requirements

• It is very important to compile a list of requirements for the API just like any other feature. The product, user stories, and/or paths need to be clearly defined.

  \

• However, it is also important for the API to be robust. Therefore, use available technical expertise to set technical standards: average and maximum response times, response codes, and retry strategies.

  \

  3) The API should meet security and privacy standards – at least based on generally accepted standards or your client’s needs.

  \
  Thanks, I’d be happy to discuss Max Sadontsev

\

[ad_2]

Source link