Transforming from app/service to platform often (not always) involves adding extensibility (API) for other companies or customers to use. Using extensibility aside from solving a missing capability, is sticky and good for biz. Some patterns, traps, pitfalls & lessons 1/
2/ Most SaaS can be thought of as "mostly about data", "mostly about experience", or "mostly about an API", especially early. Over time most apps will naturally expand to be more of what it isn't, normal. To speed expansion and feature coverage, extensibility to the rescue.
3/ An app that is mostly about storing data will often expand to both ingest more data but to also display/report/synthesize data. Early on exposing an API that allows more data to be ingested or allows other tools to serve as front ends is natural.
4/ App that is mostly UX will often expand by including data sources from other apps (no matter how other apps fit in the spectrum)—commonly called integrations. Most UX-centric apps aim to envelope other apps, viewing those apps as "data" to be consumed within their experience.
5/ API "apps" will naturally expand in either direction—they might start storing data as a system of record of some kind (often customers will start using it that way) or they will gradually add more UX to support the API (often reporting and analysis) to become an app-like tool.
6/ The challenge in these cases is always about identifying the third party developers willing to invest in building capabilities on top of some extensibility layer that may or may not run straight into the very place an app is already expanding. AND…
7/ Most all of the time, every app that customers want integrated is itself executing from the same playbook of expanding capability by adding features (that are what you do) or by adding APIs (that they want you to take advantage of).
8/ So the common pattern of offering an API/extensibility that is advantageous to your App often finds little traction because other Apps do not naturally do things that are advantageous for somoene else. They do work in their own best interests.
9/ For example, an App that views itself as a data aggregator has little motivation to offer an API to make it east to treat it like a data source but a bit motivation to treat everyone else like a data source.
10/ A UX centric app naturally wants to be the experience for everything and won't "get out of the way" for an App that wants to treat it like a source of data. Conversely any App with a UX isn't likely to "integrate" ceding the UX they care so much about to an integration.
11/ What this means at a practical level is that extensibility/customization, if the intent is to be strategic for both your App and the developer, is that it must start from a point of view that is a winning proposition for the developer on the merits.
12/ It might even be that the extensibility on paper works against your goals—you might give up UX branding or your own UX flow, or you might support data being extracted.
13/ In general, extensiblity assuming your App is the center of everything are very difficult to get traction. Even w/ early adopters, they will soon bump up against ] restrictions/limits and get frustrated. It's hard to build whole product inside another or w/o your own data.
14/ There are many specific "exceptions" to this broad challenge. For example, narrowly defined plugin architectures (eg Photoshop, conversion utilities, visual effects, etc.)
15/ Over time, a pattern that emerges is extensibilty of this "weak form" that is tough to build a whole product out of, tends to become a spring board for non-integrated products (built w/o your App) or a service business around your App.
16/ But the strongest products that aim for becoming a platform take one of two approaches. 1) By and large they become the UX that defines a whole role or job within a company. Extensibility is opportunistic and often used in point solutions.
17/ or 2) Apps allow major "plugability" or "deep integration" that they themselves can use. They allow complete replacement of UX so as to attract broad use of the underlying data while a Developer maintains their own experience or…
18/ They allow their data to be used as though it was a developer's own data. The test for this is being able to build your own UX on top of your extensibility API to your own data.
19/ But "build it and they will come" usually has some short term pop followed by slog. So make the choice to really welcome developers to your platform and give them the capability thet want, if you're going to engage 3rd party developer community.
20/ Developers really want CUSTOMERS and CONTROL. Building for your platform should bring real paying customers to the Dev. Devs also want to be in control of the end-to-end experience of those customers.
21/ The toughest thing to internalize is that developers are not looking to help your app to fill in holes or to improve it. There are some who will gladly "help out" but they are looking to make their usage better, not to build a business which is what you really want.
22/ Developers, developers, developers is about the developers and what benefits they accrue, not about the direct benefits your App gets.
PS/ Lots of tips and ideas in this substack. ty @CeciStalls

• • •

Missing some Tweet in this thread? You can try to force a refresh

Keep Current with Steven Sinofsky

Steven Sinofsky Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!


Twitter may remove this content at anytime! Save it as PDF for later use!

Try unrolling a thread yourself!

how to unroll video
  1. Follow @ThreadReaderApp to mention us!

  2. From a Twitter thread mention us with a keyword "unroll"
@threadreaderapp unroll

Practice here first or read more on our help page!

More from @stevesi

12 May
New "Hardcore Software" post - "Trapped" ……

Microsoft has a master plan, riding a wave of unprecedented success. We're going to build the roads for the information superhighway.

Then I got trapped in the snow at Cornell. 1/

Maybe subscribe. It's fun!
2/ We had big plans for how to link up computers and share information. We called that strategy "Information At Your Fingertips" or IAYF.

We were going to build that strategy in the next release of Windows codename Chicago and Windows NT.

We had a fancy vision brochure. Scan from brochure highlighting multimedia capabilities.
3/ Then I got trapped by a snowstorm at my alma mater, Cornell.

I did what every alum 5 years out does and retraced my years, visiting the computer center I used to work.

The mainframe was replaced with Macs. All connected by a bunch of free GNU software (aka open source). A big mainframe computer.students using Macs in hte libraryUser interface screens for getting online.
Read 7 tweets
9 May
Why were word processors $500+ in 1980s (~$1300 2021)? Aside from "seemed right" the packaging and contents were expensive. Here's a leading WP MultiMate. It came with several books, reference cards, keyboard templates, backup disks... The box is a fancy cloth storage box. 1/ Photo of box with 3 books, two reference cards and stickers
2/ Companies were not just teaching their product but had to explain how a PC worked. The "Beginner's Guide" literally explained how a PC worked? Why, because often people were buying a PC to run one software product. How do floppies work? start of beginners manual explaining inserting a floppy.
3/ Products were enormously complex to use. It often took weeks to become kind of proficient. Mostly because usage meant learning essentially arbitrary keyboard "chords". MultiMate was famous for *stickers* you'd put on your keys (talk about commitment). (tough to find these!) Keyboard reference and stickers.
Read 6 tweets
9 May
"Working Backwards" is a very good book for product leaders to read. It builds on 6 core Amazon principles AND tells the story of 4 key amazon projects. Written by @cbryar (12+) and @BillCarr89 (15+ yrs) of Amazon. 1/…
2/ My normal caveat is that I tend to like books that tell the story and tools a company used but don't try too hard to tell you that you should do what they did or "use these tools". I'm hardcore about this because I think context, domain, and people make all the difference.
3/ I've seen far too often business leaders adopt the low-friction/readily adoptable part of such expressed lessons, and then get frustrated things don't work. I've even seen this happen when one part of Microsoft tried to lift parts of what another team did.
Read 25 tweets
17 Apr
"BillG the Manager" in _Hardcore Software_ (read and subscribe via this link) ……
2/ From the earliest days the company was uniquely focused on a breadth product line, and only on software. Those were both unique compared to single-product companies or to the vertically integrated likes of IBM captured by this classic video (c. 1981).
3/ As technical assistant I was there to help with product reviews and serve as a form of connective tissue or glue between product groups executing on Bill's vision. In 1993 Microsoft just launched the 'year of Office' and had started the pivot from apps to the suite. Advertisement for Office in 1993
Read 5 tweets
11 Apr
A topic I end up talking about quite a bit is how org structures evolve. In today's "Hardcore Software" I discuss origins of Microsoft's two main cultures--Systems and Apps. "018. Microsoft’s Two Bountiful Gardens" in Hardcore Software on @SubstackInc …… 1/
2/ Mike Maples Sr (then head of all World Wide Products) explained the origin of each culture using a folksy story about "two bountiful" gardens at Microsoft. Apps was 58% of revenue but Systems was top of the food chain, so to speak. Excerpt from annual report in 1993. PDF of scanned document.
3/ Many are familiar with this image of different tech company org charts. It always drove me bonkers because I felt it did little to understand how or why companies are structured like they are and presumes it is just lunacy. Yes, I get it was to be funny. Manu Cornet - tech company org charts. https://bonkersworld.
Read 8 tweets
29 Mar
Climate of 'fear' prevents experts fro questioning the handling of the pandemic.… // this is super interesting and not at all obvious for a true pandemic in a democracy. 1/
2/ WHO has studied pandemics and worked tirelessly for decades in many countries. They serve in an advisory capacity with varying degrees of involvement depending on country. Lots of history going way back, smallpox, HIV, flu, ebola, SARS, etc.
3/ In 2008 a few years after SARS they published an updated Outbreak Communication and Planning Guide.…
Read 7 tweets

Did Thread Reader help you today?

Support us! We are indie developers!

This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3/month or $30/year) and get exclusive features!

Become Premium

Too expensive? Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal Become our Patreon

Thank you for your support!

Follow Us on Twitter!