I’ve had this mouldering as a draft forever, might as well push the go button.
(This article is the first in a series. The next one is over here.)
I call it the Software Industry Scam: when you set out to build a modular, general-purpose platform that can be leveraged into a large number of industries and use cases, it might take awhile, but if you do a good job, you start seeing amazing ways to tackle unforeseen use cases with no architectural friction, and little to no net new code.
When you pull it off, you can see tremendous revenue leverage—a multidimensional product of the time-honored software industry benefit of near zero marginal cost of goods, times the delicious benefit of low marginal effort to conquer new use cases. Sometimes the right platform really does make what once required a team of expert programmers working for 6-18 months into a matter of configuration files, or better yet drag-and-drop, Lego assembly of modular, compatible features into custom products that a sufficiently motivated end user can glue together herself. I’ve seen it work!
OK, let’s say you’ve timed your startup well, and in the 3-5 years it inevitably takes to build a solid platform, it looks like the TAM has really started to mushroom just as your sales and marketing are unleashed. Now, how do you convince people who don’t know, or don’t believe, that your general-purpose platform components can be assembled into a solution that will solve their problem in a shockingly short time, without hiring a team of developers or expert consultants?
We had exactly this problem at Layer 7. We built a web services gateway platform. It was a unicorn: powerful, fast, really easy to use, and modular, so we could add new features incredibly quickly. But we were selling it as a web services gateway. Not as an ERP to payroll connector. Not as a REST to SOAP to JMS to FTP to transport adapter. Not as a dynamic service routing orchestration bus. Not as an API versioning layer. Not as any Foo to Bar connector, provided Foo and Bar had standards-based messaging formats. It could do all those things, but we focused our marketing on the general-purpose, abstract, architectural benefits of the solution.
The financial crisis hit, I got laid off along with half the dev team, things were touch-and-go for about a year. Then the winds of industry fashion changed, APIs were suddenly everything, and hey it turns out a web services gateway platform can be wrapped in an API management product with a little bit of effort. Same underlying technology, identical use cases at runtime, different configuration experience, brand new marketing message.
Suddenly the revenue growth starts looking like a hockey stick, the foosball table gets paved with gold, and CA got a whiff of sustained revenue. An overnight success after ten years of effort! Nearly all the founders are gone, and investors are getting bored… We have a deal! It’s rumored that CA had no idea about the power and elegance and ease-of-use of the underlying platform, they just saw a product with revenue and wanted it.
- Sunday December 27, 2020
- 2 Comments
- Previous Article
- Next Article
1 · Burak Emir · Thu Dec 31, 02:25 am
Luke Hohmann in his book “Beyond Software Architecture” talks about product / marketing architecture vs technical architecture. I found this very lucid: something that can be presented as an extra/different product or feature does not have to require big technical changes.
I have seen this from the other side, where something that is a small, reasonable request on the product side would require massive technical changes because it invalidates basic assumptions that were made a long time ago and people built elaborate hacks and extensions with those assumptions in mind over the years.
2 · Phil · Mon Jan 4, 09:06 pm
A good observation about platform and timing. Sometimes you can make a pivot work, sometimes not. That’s where some luck is often required.
I’m interested to read the rest of your missive.