A Platform is in the Eye of the Beholder

The distinction between whether you are building a platform or a product should be made primarily to align your internal stakeholders to a particular strategic direction, as we learned in the recent iSPIRT round table.

[This is a guest post By Ben Merton]

“So are we a platform, or are we a product?” I said last month to my co-founder, Lakshman, as we put the finishing touches to our new website.

We’d been discussing the same question for about a year. The subject now bore all the characteristics of something unpleasant that refuses to flush.

However, the pressure had mounted. We now had to commit something to the menu bar.

“I think we’re a product.”

“But we want to be a platform.”

“Okay, let’s put platform then…But isn’t it a little pretentious to claim you’re a platform when you’re not?”

Eventually, we agreed to a feeble compromise: we were building a platform, made up of products.

Job done.

At least, that is, until #SaaSBoomi in Chennai last month.

Manav Garg, who has considerably more experience than both me and Lakshman at building platforms, put up the following slide:

Product = Solving a specific problem or use case

Platform = Solving multiple problems on a common infrastructure

“Here we go again”, I could hear Lakshman say to himself after I Whatsapped him the image.

“That’s his definition. It doesn’t have to be ours,” he replied tersely, “What does he mean by ‘use case’, anyway?”

“I don’t know.”

I’m in awe of the entrepreneurs who seem to bypass these semantic quandaries.

You know, the ones who say stuff like “Stop thinking so much. Just sell stuff. Make customers happy.”

For me, these are the type of questions I need to chew over for hours in bed at night.

I was therefore excited to be invited to the iSPIRT round table at EGL last week, where the topic of discussion was “Transform B2B SaaS with #PlatformThinking”. The roundtable was facilitated by iSPIRT mavens Avlesh SinghShivku Ganesan & Sampad Swain.

It takes a lot to get 20 tech founders & their leaders to travel after work from all over the city to sit in a room for three hours with no alcohol.  Fortunately, the organisers had promised a lot.  The topic description was:  

“Enable a suite of products, high interoperability, and seamless data flow for customers. This peer-learning playbookRT will help product to platform thinkers develop an effective journey through this transformation” was the topic description.”

The meeting was governed by Chatham House rules, meaning we can’t discuss the name or affiliation of those involved.

However, along with our founder mavens of large, well-known Indian technology businesses, there were 15 or so less illustrious but equally enthusiastic founders (& their +1s), including myself.

The discussions started with an overview of the experiences and lessons that had been learned by some of those who had successfully built a platform.

“We define a use case as a configuration of APIs…” the founder of a cloud communication platform started. This was going to be interesting.

“Why did you define it that way?” I asked.

“Based on observations of our business.”

I began to understand that the term ‘use case’ was being used differently by platform and product companies.  

“A use case of a platform is usually tangential but complementary to the core business. A use case for a product is something that just solves a problem,” someone clarified, guaranteeing me a slightly more restful night.

As the discussions continued, it also became clear that there were a large number of possible markers that distinguish a platform from a product, but there was no agreement on the exact composition.

To resolve the impasse, we listed out the names of well-known technology companies to build a consensus on whether they were a platform or a product.

Suffice to say, we failed to reach any consensus.  The conversation went something like this:

“Stripe?”

“Platform.”

“Product.”

“A suite of products.”

“AirBNB?”

“A marketplace.”

“A marketplace built on a platform.”

Etc etc

Even companies that initially appeared to be dyed-in-the-wool platforms like Segment and Zapier eventually had someone or the other questioning the underlying assumptions.

“Why can’t they be products?” murmured voices of dissent at the back of the room.

This was going nowhere. A few people sought solace from the cashew nuts that had been placed on conference table in front of us.

“Does the customer care whether you’re a product or a platform?” someone said.

Finally, something everyone could agree on. The customer doesn’t care.  Your product or platform just needs to solve a problem for them.

“Then why does any of this matter at all?” became the obvious next question.

“I found it mattered hugely in setting the direction of the company, especially for the engineering and design teams,” the Co-Founder of a large payment gateway said.

“And investors?”

“Yes, of course. And investors. However, I think the biggest impact that our decision to build a platform had on my business was in the design more than anything else,” he explained, “For the engineering team, it was just a question of ‘we need this to integrate with this’. But the UX/UI and the…language… needed to be thought about very carefully because of this decision.”

“So, in effect, the platform/product debate is primarily a proxy for the cultural direction of the company?”

“Exactly.”

Logically, therefore, the only way you can really understand whether a company is a platform or a product is to have an insight into the direction its management wishes to take it.

A company might appear to be a product from the outside but, since it intends to evolve into a platform, it needs to start aligning its internal stakeholders to this evolution much earlier.

“So, a startup like mine should call itself a platform even if we are years away from actually being one?” I asked cautiously after I had enough time to process these insights.

“Yes,” was the resounding, satisfying response that virtually guaranteed me a full night’s sleep.

“And when should the actual transition from product to platform happen?”

“Well, Jason Lemkin says it should happen only when your ARR reaches USD 15m-20m, but that’s just another of those rules that doesn’t apply in India,” the co-founder of a marketing automation software said.

“The important thing is that this transition – when it does happen – is very hard for businesses,” he continued, “There is a lot of risk, but it opens up new revenue streams, helps you scale and build a moat.  We hugely benefited from our decision to become a platform, but it was tough.”

It’s unlikely that we completely resolved the product vs platform debate for all founders. However, I feel that all of us came away from that meeting with a deeper insight into the subject.

Ultimately, whether you’re building a product or a platform will depend on your perspective. Most companies lie somewhere in between.

Where does your company lie on this sliding scale? And if that makes you a platform vs. a product, does it make any difference to the way you think?

We want to thank Techstars India for hosting the first of the roundtables on this critical topic.

Ben Merton

Ben is a Co-Founder of Unifize, a B2B SaaS company that builds a communication platform for manufacturing and engineering teams. He is also a contributor for various publications on business, technology and entrepreneurship, including the Wall Street Journal, the Financial Times and Business Standard. You can follow him on LinkedIn here, and Twitter here.

© Ben Merton 2018

Featured Image: Source: https://filosofiadavidadiaria.blogspot.com/2018/01/o-principio-mistico-da-verdadeira-causa.html

31-Jan Transforming to Platform Products B2B SaaS PlaybookRT

Traditionally, how many Indian SAAS companies have managed to become platforms so far? Very few.

Customers needs are changing as they seek more flexibility to use their data to solve a wide range of business problems. They prefer a suite of tools instead of buying multiple single point products. For SaaS startups, the way to compete with larger incumbents like a salesforce is not by doing another better CRM product, but by being a better AI-enabled platform which is based on interoperability across a gamut of systems.

Startups building platforms to enable collaboration with partners and solving a comprehensive customer problem will disrupt those building piecemeal products. This playbook will help product to platform thinkers develop an effective journey through this transformation.

If you are a SaaS startup that is ready to embark or already started on the platform approach, this playbookRT will be a great forum for sharing & learning from our Mavens and peers on the challenges and focus areas.

Click to Register for the Platform Products PlaybooksRT. (limited invites)

Our Mavens

Avlesh Singh, Founder WebEngage

There’s been a significant difference in the way we build our product now. We have unlocked a lot of value by converting ourselves into a platform from being a tool.

 

 

Shivku Ganesan, Founder Exotel

The platform approach allows us to differentiate use cases from products.

 

 

This is a product startup founder/CXO (+1) invite-only events. Venue details will be sent along with the confirmation of your registration.

RoundTables are facilitated by an iSPIRT maven who is an accomplished practitioner of that Round-Table theme. All iSPIRT playbooks are Pro-bono, Closed room, Founder (+1), invite-only sessions. The only thing we require is a strong commitment to attend the sessions completely and to come prepared, to be open to learning & unlearning, and to share your context within a trusted environment. All key learnings are public goods & the sessions are governed by the Chatham House Rule.

Building profitable and sustainable software product company

What common principles underlie success of software product companies such as Newgen, Nucleus, Tally, Polaris, Srishti, Mindmill, Quest informatics, Druvaa, Infrasoft, Zoho etc?. Kim and Maubrogne (1997) in their analysis of high growth companies found that these companies focus on bettering themselves, continuously let unprofitable customers go, and shed commodity resources/skills. Collins (2001) in his widely acclaimed book “good to great” identifies, the value of executive leadership, getting the right people, focus on what a company is good at and creating a culture of discipline, as the core principles of great companies. On the product development side, Reis (2011), Brown and Eisenhardt (1998) have brought out the value of building core (Minimum viable product or MVP) to reduce time to market and patching modules against market opportunity.  In this article, Browne & Mohan consultants synthesize their learning of working with software product companies.

Market selection
While many product companies start off as services companies and later productize-their services, successful ones are those that operate in markets with periodic changes in regulatory requirements, witnessing newer investments to scaling and growth of enterprises in the industry and operational friction exists due to proprietary approaches or tools. Long term sustaining software product companies also look at markets where large MNC products exist, product acquisitions are on raise and MNC’s are unable to address non-behemoth companies in that sector.

Strategic Imitation, not Innovation
While it is fashionable for academics to talk about first-to-market, most successful product companies are strategic imitators. They allow the first-mover to discover the key features, educate early customers, but ride on a me-too quickly to capitalize on the market growth. This helps in lower S&M costs and improved ROCE.

Seek ideas fly from all; focus on what not to do.
Successful product companies seek ideas from multiple sources, beta clients, product demo teams, end users, etc. But build the product looking at where the friction is highest, pain is unbearable and intension to pay is highest.

Design a product for reuse and as platform
Design the product for big picture, but strip down to basic version to design first and market test. Later modules must be used for versioning and bundling. Build modular products and products that could be used in cloud or on-premise environment. Focus should be on minimizing customization, and reduce variety at early stage to benefit from low code, feature and support variety.

Invest in multiplicative Ecosystem.
Successful product companies must learn to exploit the product ecosystem. Whether it is the technology OEM you have an ISV relationship with, analyst relationship, or a sales partner, they are good levers to reduce investments in your set-up (people and other paraphernalia). Align your sales resources to maximize the self-interest of partners. Align with OEM account manager to acquire new customers and “sales focused” no product companies in international markets to expand. Partners and resellers help in market coverage, delivery and post-deployment support. Invest in marketing and vendor management resources, processes including training and certification realised better results. Use every platform provided by technology OEM to brand and reach out to market.  Academic institutes and interns are a good platform to explore open innovations. Ideas for new products, GUI modifications, market research, pricing and competitive intelligence and in fact product development can all be areas where qualified resources can be employed to your company’s gain.

 

Keep sales structure lean and mean
Successful product companies need sales teams where the client opening meetings may happen through marketing events or resources on street, closures can only happen if they have sales team that can inform and influence at senior levels of organizations.  Named account strategy will work if the client organizations can be identified a priori, they are far and few and the sales team has the ability to penetrate those accounts at all levels.

Invest in sales operations
Successful product companies invest in sales operations units, often led by a visibility into last mile was high and the sales teams were mean and lean.

Credible and Consultative Pre-sales
To be a successful product company, invest in pre-sales who enjoy problem solving and consulting. Use various platforms to positions them as solution providers, thinkers, etc. Arm them with couple of certifications, it helps to open many a closed minds in many parts of world. 

Profitable license sales
Many companies do not have the mix of license, support and deployment worked out in detail and with sales pressures may accept clients where the license fee has been abnormally discounted. While winning reference customers is a must, not all clients must be treated as referential. 

Right pricing, adopt versioning
Use versioning or hosted vs. on-premise or CPU vs. instance prices appropriate to the product environment. Create sufficient variants to allow customers to do self-selection and a feeling of control.

Limited budget, Impactful Marketing
You do not have to splurge a lot to be noticed. In fact, many a business papers have paucity of good stories to tell on innovation, India based product or E-governance product. Invest in couple of resources to engage actively with media and also create appropriate noise on social media.

Many successful product companies have HR talking about the culture, what is unique and so on. Brand all aspects of the company. See in what way your unique induction program can become a business case study or women employees returning from maternity or other long breaks can immerse into the organization becomes an impactful article.

Hire for attitude, perseverance and initiative
Successful software product companies do not need hire noble prize winners, but committed people who would embrace common ambition of the firm. They come with openness and curiosity to learn, improvise activities within their control and innovate over time.

While academic degrees and honours may matter initially, what matters is positivism and attitude. Choose employees who are keen to dirty their hands, shoulder a bit of other roles and open to unlearn.  Incentivize employees to attempt, appreciate failures and set them for win.

Rein in service cannibalizing product
Service revenues that come with product installations can be very tempting and wean away the focus away from the product if strongly not reined. Many successful companies find themselves in service cannibalization over time and lose their long term sustainability. Limit your services play and consciously promote partners to support roll out and de-risk yourself.

Risk Management
Product companies that grew and sustained momentum measured the risk and impact of their actions, though mostly subjective.  Senior management insisted on developing an approach to estimate risks, their impact, however rudimentary across organizations. Explicit identification and evaluation of risks helped the companies question their assumptions and prepare for back up plans.

De-risk, invest in R&D
Product companies must de-risk from technologies, products, markets and customer segments. Look out for related product usage areas where the product could fit, refurbish the features appropriate to a specific industry and monetize extension of the product knowledge across different customer segments. 

With inputs from Pratibha Sharma

Bibliography Brown, S.L. and Eisenhardt, K.M. Competing on Edge: Strategy as Structured Chaos, HBS Press, Boston, 1998. Collins, J. Good to Great: why some companies make the Leap… and others Don’t, Harper Business Press, New York, 2001. Garud,R. Kumaraswamy, A and R.N. Langlois, Managing in the Modern Age, Blackwell, Oxford, 2003. Hagel, J and Brown, J.S. The only sustainable Edge: why business strategy depends on productive friction and dynamic specialization, HBS Press, Boston, 2005. Johnson, R. and Soenen, L. Indicators of Successful Companies, European Management Journal, 2003, 21(3), 364-369. Kim, W.C and Mauborgne, R. Value innovation: the strategic logic of high growth, Harvard Business Review, 1997, Jan-Feb, 75(1), 1012-112 Kopitov, R and Faingloz, L. Ways of transforming aims into results at Successful companies, Technological and Economic Development of Economy, 2008, 14(3), 312-327. Kotter, J.P, Leading Change, HBS Press, Boston, 2008. Leonard, D. Wellsprings of Knowledge: Building and Sustaining the Sources of Innovation, HBS Press, Boston, 1995. Morgan, M. Levitt, R.E and W. Malek, Executing Strategy: How to break it down and get it done, HBS Press, Boston, 2007. Schnaars, S.P. Managing Imitation Strategies, Free Press, New York, 1994.