Should Product Managers be Pragmatic or Idealistic?
Product managers are often expected to bring quick and significant metrics impact to business through API (application program interface) integration with a partner company. As PMs, in order to achieve the goal faster, we often compromise on building a holistic scalable solution, and focus on a quick integration completion. In this article, I have tried to capture, based on one of the recent products I worked on, what rationale PMs should apply to decide when to go for quick individual integration and when to start building for the future from the very beginning.
What was our problem statement?
The current process of completion of customer journey for appliances (TV, refrigerator, AC, etc.) included manual activities of creation of “installation” (partner brands install an AC, TV, etc., post that is delivered by us) tickets in partner brand systems, which resulted in longer turnaround time, resulting in lower customer satisfaction. The success metric of the solution was to reduce the TAT for completion of installation activity by integrating systems with partner brands.
Probable solution options to integrate with partner brands
1. Pull-based solution (platform-based approach): We will expose APIs for partner brands to pull data periodically.
Pro: One-time development effort, scalable solution.
Pro: No time needed for onboarding new brands; brands can adopt our exposed APIs.
Con: Reliance on brands to adopt the solution; few brands are technically capable.
2. Push-based solution (individual integration approach): We will push data to different brands on a real-time basis, preferably through a middle layer.
Pro: Majority of the partner brands readily available for integration.
Pro: Real-time data push possible from our systems.
Con: Customization/changes required for any new brand onboarding.
Con: Higher TAT for onboarding any new brands, if they have different protocols.
3. Hybrid solution: We continue to push data for real-time primary data and expose APIs for brands to pull secondary data.
Pros and Cons: Dependent on the level of customization, but less scalable and less effective than pull-based solution.
Of these available solutions, the platform-based solution suited us best from scalability, adaptability and robustness perspectives. The ideal approach would have been to create the integration platform and ask the partner brands to adopt.
But, in this case, the partner brands commanded more authority, already have legacy APIs in place and were technically less adaptable to agree to this solution. We did try to convince brands to adopt the solution, but none of the metric driver brands were onboard. One of the brands (Brand X) not ready was a market leader and contributed ~70% to our overall business. As a PM, I needed to evaluate the metrics impact before deciding on the product solution design.
Sample metrics impact:
Current TAT (Turn Around Time) for installation completion is 3.50 days (objective of the product is to reduce this metric; this is a reference value):
Our decision to go ahead with the push-based solution will yield a 35% (2.25 vs. 3.02) better number for next year. This number will increase to 53% (1.90 vs. 2.92) more efficiency after Year 1, if we continue to improve metrics operationally.
Here was the qualitative feedback of our approach:
If we implement push-based individual integrations now:
Success metric numbers looking good? Yay!
Business happy? Yay!
Customer happy? Yay!
Product manager happy? Kind of!
If we implement platform-based solution now:
Success metric numbers looking good? Nah!
Business happy? Nah!
Customer happy? Kind of!
Product manager happy? Yay!
I guess both the quant and qual evaluations show product managers sometimes need to be pragmatic rather than idealistic. This is how a customer-focused approach should be.
Core principles we followed to design the solution
Build a robust core module: We did not compromise on the core architecture and system flows, whether we build a push-based or pull-based system. The core architecture was built keeping in mind scalability and adaptability, so when we decide to migrate to a platform-based solution, it is less cumbersome to migrate. The customization will be done based on integrating brands only at the end-point level, not at the core level.
Facilitate maximum configuration: Though we integrated partner brand APIs individually, we tried to keep the parameters for integration as configurable as possible in the middle layer. This will help us onboard a similar brand in the future with less time and faster precision, though we were cognizant there will be certain customization required for each integration. Our aim was always to minimize, not eliminate, the need for customization.
Decide the hard stop for customization: We made the decision to onboard the biggest metric driver brand (Brand X) through a customized push-based solution. But this should not become a norm going forward. We must make a hard call, both as a product and as a business, of when to stop doing customization and move to a scalable centralized solution. At some point, the company needs to say “No” to any more customization and adhere to a scalable solution.
Decide whether to do now or wait more: The cost of doing vs. the cost of not doing has to be evaluated. It is important to know what metrics will be affected if you do not solve the problem immediately, and rather, wait for the ideal solution to happen.
To summarize:
Question: Why did we knowingly build an under-par product solution?
Answer: We created the product for the customer, not for the product manager!!
