Let’s start with a quick list of some of the larger, primarily B2B (business to business, software companies today:
Most of these companies have achieved their success by creating services that don’t just support one use case, but many.
What do I mean by this?
Any SaaS (software as a service) platform could be considered a product, but not always the other way around.
A Product is anything that can be offered to a market to satisfy the desire or need of a customer.
A Platform enables growth through connection: its value comes not only from its own features, but from its ability to connect external tools, teams, data, and processes.
So how have a few of the above companies nailed their markets with a platform mindset?
Salesforce: Deep integrations, support any sales tracking use case (not one sales vertical, any sales vertical). I’ve seen companies in the mortgage and lending industry use salesforce - it’s that flexible. Make any workflow you want.
Stripe: The company that help make accepting online payments easy. Developer-first, guides written by engineers for engineers. Services that are stable and reliable, and works for nearly use case you want to take a payment.
AWS: Amazon is often thought as a company selling to consumers, but AWS is often considered to be the leader in providing enterprise level cloud infrastructure to other businesses (i.e. what enables your software to run and scale for your users). AWS is selling shovels for anyone to mark their territory in the internet software space. Configurable and has tools to let you deploy almost any cloud business with more lower friction than owning hardware yourself.
Let’s dig deeper here.
Engineering wise, how do you know if you’re building things with a product mindset or a platform mindset?
Here’s a few quick situations you may find yourself or your company in:
A customer in your target market asked for a new custom field. Does it require a change by engineering to add it or is it a change they can make in the service themselves?
Platform vs. Product
A customer in your target market has a new workflow for how they serve their clients. Can he or she make it work in your application or does it completely break your application existing use case?
Platform vs. Product
A customer in your target market wants to connect data from your software to three different vendors that you‘ve never heard before. Is it possible they can do it, or are you going to have to build something for them to make it happen?
Platforms give the widest audience appeal. Products can sell, but they aren’t always in a great position to scale. Or they might scale, but you’ll be spending a lot more for it, both in time and money. If your application is flexible enough, you can focus more on future opportunities and not have to rebuild for existing ones.
Platforms give opportunities for unexpected and impactful use cases that you didn’t think of (i.e. a multi-sided business model and a much larger possible market segment).
Platforms also enable deep integration possibilities by enabling customers to use the product to fit how they want to digitize or scale their existing business model, rather than forcing their business model into yours, which may not always be right for everyone.
Engineering is expensive.
If you can, make more things configuration changes — not code changes. Make the custom requests often asked by your customers accomplishable by your implementation team — and not just by your engineering team.
Take the above principles with you and you’ll be well on your way to out-maneuver any B2B rival, and in some cases B2C rival, that stands in your path.
Would love to hear your thoughts!