Why Platform-ify?
The Difference Between Bundling vs Integrating
I recently got a great reader mailbag question that prompted me to write a long form response and turn it into a full blog post (see below). The tl;dr is the reader was trying to get advice on how to make a business case for better integrating different products that had been built/acquired piecemeal over the years. And to me, the fact that point solutions were being sold under the same umbrella with no cross-product unification was a sign that basic bundling had been achieved, but proper integration had not. And there was a resistance to platform-ing. Read on for the whole story.
Also note, I have 2 upcoming interviews as part of 60 Minute Stories that you won’t want to miss: Jon Fan discussing Why You’ll Always End Up Building a Workflow Engine in B2B and Aaron Smith talking about Leveraging 100% of Your Company's Brain. Both events are free, live, virtual webinars…but seats are limited so sign up today!
In so many companies today, there is a tendency to grow via acquisition. This is particularly true at ours. And while we've acquired, our products retain so much autonomy that they have a high level of variability between products in the same portfolio.
Is there a best practice, tradeoff, business justification process that you've seen in industry to re-evaluate some core capabilities to align those products on a common licensing mechanism, consumption models, or simplification and alignment of business models in order to better support customers and to decrease unique internal costs of infrastructure, marketing that are tied to individual products?
It seems like an obvious question to me, and I have examples of other companies like Microsoft, Adobe, Autodesk doing this to products during their business model transformations, but I don't know where apart from press releases that I could make a business case for my leadership for this approach.
The starting point for me is acknowledgement that putting together adjacent solutions in a B2B context makes sense and just works - products are workflows after all. So credit to this company for building and acquiring complementary pieces. But in B2B products you are fundamentally dealing with (at least) 2 personas (more on this in a future post):
the buyer - who wants unification from a purchase/renewal perspective
the user - who wants unification from an activation/adoption perspective
And this is where the question gets interesting. Many companies solve for [1] by bundling products, offering discounts, incentivizing reps, and optimizing cross-sells. But that is just 1/2 the puzzle. In order to actually get happy customers serving as references (your best future source of pipeline), you’ll need them to actually deploy and utilize your product. And that’s where integration comes in. Make the sum greater than the parts…1+1 =3 as it were.
There are 3 rationales for the type of "unification" work the reader is trying to justify to the business:
Time to Value
Repeatable Motion
Cost to Serve
In order to get customers to value, true “solved our business problem in a delightful way such that we’ll talk about it on stage at your conference” value, you have to reduce (or even remove) the cognitive load on the part of the end-user navigating your product and the admin working to configure and manage it. And when you have inconsistent components, patterns, and flows in different parts of your products (because it was built or bought piecemeal), you are adding friction on the path to value. When users who took the time to ramp up on your product are presented with different paradigms and forced to learn new mental models, they’re left with a bait-and-switch feeling. Don’t make it harder for people to “get good” at your product.
Beyond your users, having a streamlined product helps your GTM motion as well - whether you have an internal sales team or rely on external partners, getting them to consistently sell and deploy the same use case with minimal customization is the path to repeatability. And repeatability is what separates a product business from a services business. If your portfolio has 3 products (X, Y, Z), imagine how much extra work you’re creating for your marketing, sales, support, and success departments with different demos and docs for each. With shared widgetry across X, Y, Z, you can not only have consistent demos and docs, you can have a consistent playbook for land and expand. The time to ramp up new sales or support people gets drastically reduced and you have more value from generalists vs the need for specialists. Again, don’t make it harder for people, even employees, to “get good” at your product.
And the last reason for unifying is to reduce costs. Whether it’s the testing load for different components or infrastructure bills for different clouds, you tap into economies of scale with a unified tech stack. Any time your technical teams (engineering, premium support, data analytics, developer relations) are spending maintaining different versions of the same thing is time they’re not spending improving the end-user facing functionality of your product (which is what customers are actually buying). Whether it’s a shared design language or shared back-end services, you unlock new product development velocity when developers can ramp up on the codebase (and again “get good”) more quickly.
Now, the counter-argument you'll get to this business justification to unify the product is team autonomy / speed of execution. If you let a thousand flowers bloom, you’ll fill out the garden faster. But my counter to that counter? Is that a garden that’s appealing to the community? Is a product with more features that don’t work well together appealing to your users? When you are just a collection of parts bundled together, are you stuck at 1+1=2? Your differentiation, when compared to point solutions or other commercial bundles, is that you have the potential to have 1+1=3.
The last point I want to make is that when you decompose your product into logical building blocks and reconstitute it in a more intentional way, you open up the door to something bigger: a platform. With a standard alphabet and shared vocabulary, you can not only communicate with your desired audience consistently and clearly, but you also allow others to extend and expand on your language, which in turn can be a gateway to new audiences. I’m a big fan of this quote from Steve Yegge’s Google / Amazon Platforms Rant:
A product is useless without a platform, or more precisely and accurately, a platform-less product will always be replaced by an equivalent platform-ized product.
As always, I’d love to hear from readers who are navigating the cross-product unification journey - please chime in via comments👇 or join the chat via the Substack app.
And if you enjoyed this post, please consider subscribing.
further reading / references
Span (vs Split) Personas is where I delve into the idea of products as workflows
In Platform Plays I talk through the 3 key ility’s (scalability, extensibility, composability) which allow you to 10x “reach”
The idea of removing friction for your B2B product buyer and user is elaborated on in Death & Taxes in B2B
If you’re wondering how a product business differs from a platform business, check out these great explanations by Rich Mironov and Nathan Barry
childish drawing / interpretation
