@jdvhoutenImagine two startups. One startup makes a business chat app similar to Slack. The other startup has a business wiki product. In principle, these are very different apps that solve different problems. In practice, both apps face constant pressure from their customers to become more like the other.
Users of the chat app start demanding threaded discussions, archived discussions, pinned discussions, rich text options, and the ability to draft responses. Any individual feature might make customers happier and increase retention and conversion rates, but mindlessly adding all these features will turn a good product into an unfocussed mess. You end up with an ugly hybrid app that is half chat half wiki. It doesn’t have a clear audience anymore.
You can see how a wiki app can end up in the same place by adding more and more messaging features. Different chimera, but equally bad.
It’s a problem that all b2b SaaS apps struggle with. If you say yes to every feature request your product eventually turns into a platform product like Office 365. Customers always ask for Forms, workflows, calendars, project management, chat, writing, and email features. And they’re not wrong to want a single integrated solution as opposed to a hodgepodge of overlapping products. If they like a product they want it to solve more of the problems they have. So what is the app developer supposed to do?
As a SaaS vendor you have a couple of options. One option is to embrace the platform vision. Max out on engineers and build it all. This is the Google Suite, ZoHo and MS Office 365 strategy.
A second option is to stay strictly on course. You build out your narrow product and make it the best it can be without adding any platform features. Instead of making your product wider you go deeper. You keep your focus and you refine and perfect your product, and users will have to use an API for everything else. You get really good at saying “no” to customers. The big disadvantage of this approach is that you spend a lot of time making small improvements only a handful of powerusers care about while ignoring the features your customers really want but that don’t fit neatly in your product vision.
A third option is the “tiny platform” approach. Instead of building a whole platform you only build the easiest 5%. You implement a couple of key features of each platform product and go no further. This is the Basecamp approach. The big disadvantage here is that you end up with a product that is okay at many things but doesn’t excel at anything.
A fourth option is to make your product an add-on to an established platform like Office or Google Suite. You focus on your product features and you can provide integrations with the other application suite products for everything else. This strategy makes a lot of sense, except, you tie your future to a 3rd party that really doesn’t care about you. It’s a precarious position to be in. The platform owner can pull the plug at any time. One day you’ll wake up to an automated email that an API function has been deprecated. Your app stops working. Your customers are angry, you are helpless, and years of work go down the drain.
There is no correct approach to this platform dilemma. Software is never finished and you can always keep building and building in any direction. Build in the right direction and you’ll get many happy users. Build in the wrong direction and you’ll attract the wrong kind of customers that will push your product even further away from product-market fit. That’s why it helps to have a clear platform strategy. It can tell you when to say no.
This is what we have to figure out for Thymer. Thymer will have task management and planning features, but this has some overlap with the features provided by conventional calendar software. And everybody already has a calendar app that Thymer can’t realistically replace. Neither can Thymer replicate all major functionality people have come to expect from calendar software. So what do we do? Do we go all-in on API integrations with 3rd party calendar software? Do we tolerate scope creep and reimplement all calendar features we think are important? Do we add a minimalistic calendar to Thymer and accept that users will still have to use a different calendar product on the side? Or should we kick the can down the road in the hope the correct answer will become clear in the future? I don’t know.
