{"id":7808,"date":"2024-09-25T10:00:16","date_gmt":"2024-09-25T04:30:16","guid":{"rendered":"https:\/\/gtm360.com\/blog\/?p=7808"},"modified":"2024-09-26T16:13:30","modified_gmt":"2024-09-26T10:43:30","slug":"product-mindset-middleware-platform","status":"publish","type":"post","link":"https:\/\/gtm360.com\/blog\/2024\/09\/25\/product-mindset-middleware-platform\/","title":{"rendered":"Product Mindset – Middleware Platform"},"content":{"rendered":"

I recently read the following post on Twitter:<\/p>\n

\n
@sudomax<\/a>: Who would have thought connecting disparate APIs would have been so successful.<\/div>\n<\/blockquote>\n

<\/p>\n

The OP is referring to Zapier<\/em><\/strong>, which automates workflows by connecting APIs between different systems. Its $4 billion valuation is a good measure of how successful it has been. MuleSoft<\/em><\/strong> is another very successful middleware \/ integration company – it was acquired by Salesforce<\/em>\u00a0for $6.5 billion.<\/p>\n

\n

Systems Integration<\/em> is one of the mainstays of the Indian IT Services industry.<\/p>\n

Typically a large enterprise in the west has a plethora of IT systems. Whenever it buys a new software, it entrusts the product vendor (or implementation partner) to “land the product safely” in its existing IT landscape. This means that the new product must work well with the company’s existing systems aka surround systems, which requires it to talk to existing systems and be implemented without causing any disruptions to current systems, operations, or processes.\u00a0This is enabled by interfaces between the product and the surround systems.<\/p>\n

Some interfaces will fetch data from the surround systems and provide it to the new product, whereas others will fetch data from the new product and provide it to the surround systems. (For some reason I can’t fathom, a vast majority of interfaces I’ve come across are only unidirectional. Anyone knows if there’s a reason why bidirectional interfaces is not a thing?)<\/p>\n

Some existing systems have an API architecture so that their functionality and data are exposed to the new product as a blackbox service that can be consumed easily whereas others call for an intrusive approach needing the interface builder’s team to work with the owner of each and every surround system to understand its architecture and data flow structure while designing the interface.<\/p>\n

Interfaces are typically developed by a third party Systems Integration<\/em><\/strong> firm.<\/p>\n

To cite an example from my old life, a Top 5 UK bank purchased a new payment hub software product to process TARGET2 payments. (For the uninitiated, TARGET2 is the crossborder RTGS payment system in EU.) The bank had 84 different systems in its payments landscape. It hired my old company to develop interfaces between the new TARGET2 payment hub and the bank’s Origination, Sanctions Screening, Reconciliation, Data Warehouse, and other existing systems. As Systems Integrator, we developed over a hundred interfaces during the course of the program.<\/p>\n

As leading SIs, TCS<\/em>, Infosys<\/em>, HCL<\/em>, Wipro<\/em> and other lndian IT services companies have done thousands of integration projects where they have built millions of interfaces across diverse customer landscapes. As a result, they have amassed deep expertise and vast experience in the middleware space. If they have not built a middleware platform like Zapier or MuleSoft, I speculate that they were impeded by cultural – rather than technological – hurdles e.g.<\/p>\n

    \n
  1. Context not Rule<\/strong>. To develop a middleware product, an SI services provider needs to survey all the integrations it has done for multiple customers, abstract the common features, and create rules for its platform. Indian mindset:<\/em> Move on, don’t revisit and introspect, culture emphasizes context, not rules.<\/li>\n
  2. Shirk Responsibility<\/strong>: If a surround system changes the specs of its API (or something else), subscribing apps will likely break down. A middleware product vendor needs to quickly rewire its platform such that they can resume normal operations with minimal downtime. Indian mindset<\/em>: It’s not my fault if surround system changes.<\/li>\n
  3. Reactive not Proactive<\/strong>. The middleware product vendor should engage constantly with the developers of surround systems and get ahead of the curve on future API (and other) changes. This will enable it to \"\"<\/a>rewire its middleware platform before<\/em> the changes happen so that subscribing apps do not break down in the first place<\/em>. Indian mindset<\/em>: Surround system owner should tell us that it’s changing its specs, it’s not our job to find out.<\/li>\n<\/ol>\n

    All of these speak to lack of problem definition<\/em><\/strong> skills. According to a doyen of the Indian IT industry, this deficiency has not been remedied in the entire 40 year lifetime of the industry.<\/p>\n

    Problem definition is a vital part of product mindset<\/em><\/strong>. In my opinion, the lack of problem definition skills has prevented an Indian IT company from developing an integration platform like Zapier or MuleSoft despite having deep expertise and vast experience in integrating zillions of systems.<\/p>\n

    \n

    So far I’ve focused solely on the product development facet of the product mindset. But winning in products requires the right mindset towards sales, marketing, and many other facets. I’ve covered the success drivers for those functions in a previous blog post titled Developing The Product Mindset<\/a>. Given below is the most important takeaway from there for the present context.<\/p>\n

    Marketing, marketing, marketing<\/strong><\/em><\/p>\n

    According to Saastr<\/em>, the Silicon Valley venture capitalist that focuses on SaaS companies, the typical American product company spends $2 in sales and marketing for every $1 in product \/ engineering \/ R&D, with the multiple exceeding 3X in the case of outliers like Salesforce<\/em> and Zoom<\/em>.<\/p>\n

    \"\"<\/a><\/p>\n

    In sharp contrast, the typical Indian product company does not get the importance of marketing. Many founders of product companies believe that a good product will sell by itself. While they learn the hard way that they’re mistaken, it’s sadly too late to rescue their companies by then.<\/p>\n

    \n

    TIL there are still people who believe in “build and they will come” in the 21st century. https:\/\/t.co\/uXlYxFdGNn<\/a><\/p>\n

    \u2014 Ketharaman Swaminathan (@s_ketharaman) August 31, 2024<\/a><\/p><\/blockquote>\n