That reminds me of Amazon - I've been "unbundling" my purchases from Amazon due to shipping delays. I still think it's a useful place to find /which/ product I want to buy, but once I figure that out, or if I already have, I head over to the product's own website and buy it there. Examples of my recent purchases - diapers, toys, herbs and spices. In all of these examples the product has shipped within a day and received within a few days.
Good point, but unfortunately on a lot of vendor sites, the checkout experience is still sub-par, some require you to create an account (Annoying if you know it's just a one-time purchase). On amazon, it's click and done. The shipping delays aren't universal; I recently ordered coffee from there and it it got delivered within 2 days (prime customer).
On the checkout experience front, I notice that's been changing lately, especially with Shopify shopfronts. (e.g. jrwatkins.com)
The experience is even more frictionless than Amazon's, especially on a mobile device that supports mobile payments. With Apple Pay, the checkout process is literally just clicking the checkout button, then scanning your face/thumbprint, and done. No account creation, no credit card number is sent (token), address/email etc. are filled out transparently.
Kind of similar to the HotelTonight experience where you're able to book a hotel in less than 3 minutes.
he's talking about receiving his goods a day or more earlier, and you are talking about a couple of minutes longer sitting in your chair typing in the account information. Your customer service point does point out a benefit, but it doesn't address the consumer need expressed in the previous comment.
Maybe Google should know better than to "pluck" copyrighted images from people's sites and display them out of context on their own site while serving their own ads.
Talking about unbundling on connectors.. is there something like Zapier for large enterprise?
Also, would be nice there is an standard way to develop these connectors for interchange
> One of my favorite business model suggestions for entrepreneurs is, find an old UNIX command that hasn't yet been implemented on the web, and fix that. talk and finger became ICQ, LISTSERV became Yahoo! Groups, ls became (the original) Yahoo!, find and grep became Google, rn became Bloglines, pine became Gmail, mount is becoming S3, and bash is becoming Yahoo! Pipes. I didn't get until tonight that Twitter is wall for the web. I love that.
> Funny that he mentions Yahoo! Pipes, since that was sort of the same idea behind Zapier, et al., though (I guess) too far ahead of its time.
An alternate business model is to look at Yahoo product launches from 5-10 years ago, and build what they did but shut down, its time may have come. Google did this pretty well for a while. You can probably do it for Google now, too.
Maybe. Might not specifically be RSS-based, though, there's a lot of good RSS clients out there (I use https://bazqux.com/ - it's great).
Google Reader I remember sold itself as being an "inbox for the web". I think Reddit and Facebook are the big competitors for that idea… not RSS clients. But maybe the time is right for a new take on that idea, one that works more closely like Reader.
Yahoo! Pipes a strong argument for building your own tool/buying a paid product, in that if one relies too heavily on a service and it went away, then that [business] process went away as well. The demise of Pipes! caused us a bit of anxiety and made us hustle to find other solutions in a compressed time frame.
The rather quick demise of Yahoo! Groups was also disruptive. Heck, even Hacker News could have worked as a Yahoo! Group. Fortunately, it is not. When Groups went away, so did a lot of discussion groups and even when those groups moved, they lost many members. Groups.io is a nice alternative, but there too much of their platform is free.
There is always a danger when you build critical things on someone else's land, particularly if they allow you on their property for free. Even if they charge you but are not profitable, there is a risk of waking up to read that the service is closing.
We use Zapier in our small business, but work to build out tools for those Zaps! that become mission critical.
Didn't yahoo pipes also give the ability to type sql for apis like "select * from facebook.posts" or "select * from reddit.posts where subreddit='askreddit'"
Hmm makes me think...there might be some cool usecases for replacing filesystem related tools/commands with webapps using the native file system API in browsers, when/if it gets released
“Complexity can be tamed, but it requires considerable effort to do it well. Decreasing the number of buttons and displays is not the solution. The solution is to understand the total system, to design it in a way that allows all the pieces fit nicely together, so that initial learning as well as usage are both optimal. Years ago, Larry Tesler, then a vice president of Apple, argued that the total complexity of a system is a constant: as you make the person's interaction simpler, the hidden complexity behind the scenes increases. Make one part of the system simpler, said Tesler, and the rest of the system gets more complex. This principle is known today as "Tesler's law of the conservation of complexity." Tesler described it as a tradeoff: making things easier for the user means making it more difficult for the designer or engineer.”
― Donald A. Norman, Living with Complexity
I'm not sure I agree that complexity is always conserved. When I design systems, I often find that there's intrinsic complexity that I can't seem to escape, but that my initial designs are often quite poor and also include incidental complexity. If I'm thoughtful, and I learn the domain well enough, I sometimes find I can remove that incidental complexity. Alan Perlis had a couple of epigrams that echo this, I think.
> 31. Simplicity does not precede complexity, but follows it.
> 58. Fools ignore complexity. Pragmatists suffer it. Some can avoid it. Geniuses remove it.
All that said, I've definitely seen cases where trying to insulate the user from the reality of what's happening behind the scenes often dramatically increases complexity. When it's done poorly, in increases complexity not only for the designer and programmer, but the user as well. One well-known example is the progress bar. After 30 years of lying to users about how long that file copy, download, or compile would take, many recent designs simply exclude it and include an animated spinner instead.
One implication of Tesler's law appears to be that it is impossible to increase the total complexity of a system. But this feels intuitively wrong to me after looking at the source code of any ERP project.
Maybe it only comes into play if you try to decrease over all complexity of a system. After a certain point complexity can't be reduced but can only be redistributed.
The Tesler conservation law is like first law of thermodynamics: you cannot destroy complexity, only change its form. Your observation is more like second law of thermodynamics: the complexity of a closed system always grows with time.
I don't know if there's context which might change my interpretation, but from the sound of it, I disagree. This is only true in a closed system. With many things (especially software), we encounter the same types of problems again and again, so we can re-use the same solutions, which allows us to reduce overall complexity.
A program in 1985 likely wrote its own routines for memory management, math, graphics, and so on. Those add complexity. A program in 2020 almost certainly doesn't. The complexity is hidden behind nice interfaces, and more importantly, it's shared among 1000 different programs on my computer.
We traded inline complexity in 1000 places for complexity in <math.h>. That's not the fair trade that "conservation" implies.
Let's say you have some physics problems to solve. Doesn't knowing Maxwell's Equations decrease overall complexity? I don't think anyone would claim you should only learn first principles, and any other formulation only uselessly pushes the complexity around.
It's one of my favourite books and I thought that it paired quite nicely when talking about software like Zapier or Tray.io that try to solve such a complex thing.
I can tell you from first hand experience that it is extremely difficult to ensure consistent, reliable ETL of JSON payloads between thousands of services.
APIs are unreliable. Schemas change with no warning. Data you expect might be missing and data you don’t expect might show up. You would be surprised how often things don’t work as you’d expect them to.
Zapier does have thousands of integrations, and some hundreds of them (the oldest or most widely used) are maintained internally for the best user experience.
These days though, many more are maintained by the API providers themselves, since it benefits them to provide a no-code solution for their users to link their API to thousands of others - a service provider can only build and maintain so many direct integrations themselves. https://zapier.com/platform
I have always thought it would be useful if API providers were able to provide the javascript bundle that Zapier runs under the hood on the dev platform alongside their API at a pre-defined route, so any runner (Zapier, Tray, MS Flow/Power Automate) could consume the API regardless of location (SaaS automation, desktop client, etc). I believe there's even an automation provider that allows you to "one-click" import the integration you've built from Zapier to their platform (the name escapes me at the moment, my apologies).
If the API provider is already maintaining the integration, it's a matter of automation providers moving towards a standard for how to express integrations as the ecosystem matures.
Not as hard as tedious. Here is a trivial example: your application generates a message that informs the user about the number of file copied. Most developers generate the message templated as this:
{N} file(s) copied.
Which kinda works, but not so user friendly because "0 file(s) copied" sounds non-human. It should be "No files copied". What a more UX-focused developer would it is write something like:
match N with
| 0 -> "No files copied"
| 1 -> "1 file copied"
| _ -> "{N} files copied"
The latter is not very hard. It's just tedious work that many people don't do.
I can definitely relate to the point being made here: my startup (https://reclaim.ai) does various calendar automation. We see a number of users sign up for our service after having tried Zapier to solve their problem.
Not only is the UX more complex to get the job done, stuff like what we're doing (ex: personal->work calendar sync) is more complex than you think and simple "if this then that" types of workflows start to break down.
We have nothing against Zapier (heck I'm a user for some stuff). But there are definitely things it is ill-suited for, despite having an amazing marketing engine that can capture a very long tail of search terms due to the NxM nature of their product.
"Fun" fact: one of our users recently found us after screwing up his calendar sync Zap and, on a random Sunday morning, ended up inviting thousands of his coworkers to dozens of duplicate meetings, all from his personal Gmail account. It was his fault (his Zap had several errors in it), but in the end he was much better served by a dedicated solution.
I think the author's advice is spot on: there are opportunities in making better solutions for popular Zaps. Just please don't do anything in the calendar space ;)
This, I’m convinced UX is the main source of trust for a software business, and managing the solution’s complexity is a core part of that.
My team at FAANG uses reclaim.ai pretty heavily to protect our calendars from corporate bs. We find it easy to maximize our time for working and being in the zone. Other FAANG or startup engineers would find this product useful to auto optimize their schedules. Especially if they find their calendars sprinkled with meetings with small gaps of free time in the day. I like to block off my afternoons as personal dev/work time.
Reclaim Assistant is free through January 2021, give it a shot. Reign in those Zoom calls that break your concentration throughout the day.
I just looked at Reclaim. That's exactly what I tried to do by creating a Google account just to join together 6 other calendars, and that's the calendar I sync to my phone (it works but... meh. definitely a hack. For example, the annual holiday calendar is repeated about 18 times somehow).
As some who occasionally has to gather small groups (~5 people) --we all work remotely (pre-covid too), so one can't just swing around the corner-- I would be quite bothered to find my colleagues booked every last minute of their time, such that it would become impossible to schedule 30 minutes sometime in the next 2 weeks. Especially knowing that this was used, I would then have to ping everyone and see if they actually are free at such-and-such a time. I suppose that's the tool's intent.
Everyone should block off 1-2 hours a day for themselves. Consistently blocking your entire day could slow down the organization, if meetings are a place for reaching consensus and decision-making.
Quite the opposite in fact: we built this for manager-types who have many meetings and for the very reason you cited need to appear available.
It purposely makes the slots of time that we book “free” until the day is too full, and only then changes it to busy.
The result is that my calendar, for example, appears free from 11am to 2pm, but if suddenly that time starts filling up, some time (30-60 mins by default) gets held for lunch.
In other words: it does exactly as you prescribe (blocks off 1-2 hours), except without the rigidity of fixed events, making it easier for people like you to call (hopefully good) meetings.
The lunch use case animation might be a simpler way of conceptually explaining the product, just my 2 cents. Thanks for clarifying there.
Corner case: let's continue the idea of a flex lunch of 30 minutes between 11:30 and 2pm. If my work calendar has no events, and someone schedules a meeting from exactly 11:30 to 2pm, does it automatically reject? The person scheduling that meeting would've thought my schedule was free because the time was marked free, since the flex lunch time is only "claimed" once I'm down to 30 minutes of unscheduled time between 11:30 and 2pm.
My personal intent of blocking this 30 minute slot is never publicly visible on the work calendar, since it has no concept of that.
It sounds like Google Calendar (or whatever meeting software companies use) needs to build in these sort of features, since there's no way to do so. Reclaim helps, but if I'm booking my meeting within Google Calendar, and some of my meeting participants use Reclaim, I can't see the sorts of constraints participants are setting on their time.
Re: your corner case... Currently we defer to the incoming invite and remove the block IF you accept the 2.5+ meeting invite the overlaps. One exception: if the invite happens to mention lunch is being served we auto remove it. In the future we will likely offer the option to auto reject, but we don’t today.
Re: your other comments, you are right that the core platform (mostly dictated by the iCal standard) cause some of the limits on these workflows. But we designed Reclaim to do most (all?) of what you’d expect both for you (a Reclaim user) and others (non-Reclaim users who just stick on the core platform).
This is what I did with Tweet Photo [1] — It automatically tweets your instagram photos.
It started out as a Medium post[2] describing how to set this up with Zapier. Seeing how much traffic it got even years after publishing it, I decided it was worth turning into a standalone service.
While the post helped me validate there was demand for such a service. I didn’t validate people were willing to pay for it. So user growth has been good [3], revenue not so much. (less than $1k MRR)
Something to keep in mind when you go this route. Be sure to validate people are willing to pay for a solution. Building something aimed at businesses is probably a good idea.
I have created almost the opposite. A service that screenshots tweets so that you can share them on other platforms. Instagram is not directly supported, but you can use Buffer or other similar services.
I know of it. The main issue is it has a 30 second execution script time limit for custom functions [1].
So if you want to build anything that could take longer than that to execute you need to make sure to write to the spreadsheet before 30 seconds elapse and have a recurring scheduled function that completes any unfinished jobs. Gets tedious and failure prone quickly IME.
I wanted to see if it would ask for access to my entire Google Sheets account, so I tried signing into https://gsheet2mail.com/ and got an error message.
Looking at the page again, I saw this, which I missed:
> Hi there! We're currently being verified by Google. So just click "Advanced" when signing up to continue :)
I tried clicking advanced, and yep, it wants access to all my spreadsheets =) I said no, but I don't want a google sheets to RSS converter right now anyway.
This is one advantage Zapier has over unbundled apps - I'm more likely to want to give Zapier permissions to my APIs because it's an established company and it can help with a bunch of different things, than to give access to a new single function tool.
That's the read-only scope that's required to query a single spreadsheet on the user's account. The API doesn't allow listing queries unless you also ask for drive permissions (which I don't).
I'm famiilar with the Google Sheets API. The way to get fine-grained access to the Google Sheets API is by asking for a specific permission within Google Drive. While it involves two APIs, it's less permissions than giving access to all the spreadsheets in a google sheets account.
Another way to go is to use a service account, and have the user share their sheet with your service account's email address.
Python is a great tool in that it is easy for starting developers and useful experts alike.
Zapier is a great starting tool but quickly breaks down for anything more complex.
If you’re a SaaS app that has complex “use cases” then sending users to Zapier to have them figure it out doesn’t work. Instead, you can build your usecase on a tool like Integry.io (yes, founder here), embed the integration in your SaaS and have a clean UX.
Ultimately, you don’t want your users figuring out what triggers, actions, steps, mappings, transforms, validations are. People don’t buy integrations, they just want their tools to work together and tools like Zapier and tray can still be too complex.
This - I'm planning on churning with a webinar tool because the only way to integrate it with Salesforce and Hubspot is an extremely complex Zap. No thank you.
I think the issue is that techy/engineer-types are big fans of elegance. It's undeniable that services like Zapier are elegant in the sense that they generalize pretty well, they can "do it all" and, in all honesty, they're not too hard to figure out. With that said, there's no true value in elegance. And while generalizing is definitely a good idea for a mathematical proof, it might be a bad idea for a product.
I have to admit that a lot of times (especially when building side-projects/toy startups), I second guess myself when it comes to these kinds of product decisions -- "Is this product too simple? Too bare-bones; too much of a one-trick-pony? Would anyone pay for this?"
I believe that was separate senior engineers from the other is having passed the phase of elegance.
Eventually we want stuff that works, without looking at them.
On twitter people were asking what is clean code? My answer to that is that the cleanest code is the code you never have to open in an ide to figure or tweak.
I have written some beautifully elegant code in my time.
It's code that I now hate returning to because I don't understand it at first glance. (Granted this was years ago. I don't code that way anymore and haven't for quite some time).
This reminds me of what Don Norman quotes in "living with complexity" around how people buy the microwaves with all the buttons even though it's harder to use.
The two-dial ones of old were the best. Set power dial (or don't touch it if it's already where you want it), turn timer dial. Microwave goes until timer dial hits zero. No "start" button, no cancel, no menus, no preset crap. Just two dials.
I feel that complex workflows are best served by dedicated integrations, but it takes time for developers to build each integration natively into a product. We launched https://kloudless.com to simplify the process for app developers to natively integrate an entire category of SaaS services at once (I'm a co-founder).
Ignoring platforms like Salesforce, some of the "product" apps that we see adopting native integrations instead of directing users to Zapier include apps that require:
1) synchronous interactive integrations and not just background automation. e.g. a user pulling a lead from Salesforce into a marketing app.
2) complex/multi-step integrations that offer way better UX and much lower support costs to just build natively for users.
3) integrations as a competitive differentiator, or without requiring users to pay for third-party tools.
4) integrations without an API of their own to integrate to.
That said, there are always a long tail of apps and use cases so I'm certain we'll see more specialized tooling pop up to handle specific complex workflows.
This "unbundling" is the exact approach we're taking with Saasify. There's a lot to be said for focused, niche SaaS products that do one thing and do it well.
This resonates with me, just having implemented Dead Man’s Snitch style alerts with plain Amazon CloudWatch. Higher abstraction level tools are valuable.
My recent use case is needing an alert if a certain metric of my system exceeds a threshold or is not present. The simplest viable alerting tool might take these parameters:
* alert threshold
* comparison operator
* expected datapoint interval (in units of time)
* whether to consider missing data breaching (boolean)
* if missing data is breaching, margin of skew allowed (in units of time)
(assume the tool magically has access to metric source, that’s not important)
I’m not sure whether the concept was named prior to this tool [0], but this tool’s name has become a colloquial term: a “Dead Man’s Snitch” style of alert. Once familiar with the idea, I found an exception-monitoring vendor [1] that I was already using at the time had built this feature in. I quickly found use cases and was broadly able to eliminate large volumes of “cronspam” and email filters in favor of the much more elegant construct — because it was so easy to implement and maintain, it was viable for a whole long tail of second class system metrics that otherwise didn’t deserve proper instrumentation.
CloudWatch on the other hand is lower level and more flexible (naturally with higher learning curve). It fundamentally provides similar value by offloading alerting state and logic to a trusted managed system, but is distinctly inferior for my use case:
* It treats missing metrics as literally breaching the threshold and makes no semantic distinction, which spikes the whole abstraction. You can (only partially) workaround this by splitting the alert into two distinct alerts.
* It doesn’t have a “permitted skew in units of time parameter”; you need to do the arithmetic and translate it into their parameters. This spikes the abstraction and makes the alert logic opaque to my team members and future self.
Zapier is great. I use it all of the time, from personal projects to work stuff.
However, as soon as you try to do more than couple of things in one zap and have multi zaps routing/transforming data between the same apps, it becomes very easy to fuck it all up (duplicate, trigger wrong things, etc) and Zappier (or other solutions like tray.io for that matter) doesn't provide you any help and the whole things becomes quickly difficult to maintain or manage.
A great analalogy would be it's a beautiful gun but makes it way too easy to shoot yourself in foot after the first shot
I'm looking for more unbundling and "micro apps" that solve the maintainability of it too.
It sounds familiar to me since I too have built a micro-SaaS that could probably make it in Zappier: https://sheet.chat to integrate Google Sheets in Slack
LOL. Stirred up some good memories of adult Craigslist back in the day. I must have posted “Psssst! Hey you, college girl... need cash?” over 200 times.
CL is a consumer facing product that offers a good-enough experience for most categories. The category specific vertical companies mentioned greatly improve the experience / feature set. They are expansive by nature.
Zapier is a b2b tool that ties together systems / data sources and reduces it to a common interface for most scenarios. Being reductive and reusable is the chief value. I do not want another integration tool if I can help it.
Isn’t the point of the article that if one company provides a good enough experience for many things that doing one of those things better may be a good business opportunity? It may be particularly attractive to the subset of people who rely on that one thing.
The point doesn’t seem to be that you need more integration tools. It’s that if one integration is very important to you, you might want a dedicated tool that provides better experience and value.
Way deeper levels of customization, imo. You can setup web endpoints and chain data fairly intuitively between steps. It has its limits but, if you can live with them, it can be very powerful!
That’s how we came up the idea of a cloud version HTTP scheduler https://ihook.us. For sure Zapier can do this, but you have to navigate among a ton of integrations to figure out where a scheduler app is, and click though the plus sign to add downstream actions, which could feel complex even for users with engineering background. Seems in a platform where apps/functionalities are commoditized, the complexity of integrating it with your business logic is deferred to the user.
Great post!
I’ve been reading a book called “Unlocking the customer value chain” [0] which talks about three waves that the Internet brought along : Unbundling , disintermediation and decoupling. This post on unbundling is a great starting point. The trend seems to be towards decoupling which is something that will come once unbundling becomes mainstream or mature.
[0] https://www.goodreads.com/book/show/42934086
I'm currently doing this so I can stop paying Zapier. I've built a plugin to append new Gravity Forms entries in WordPress to a Google Sheet & with some more polish it'll be ready to sell.
If you've got a forms application that can't export the data where you want it to, I can't shake the feeling that you're working on the wrong part of the problem.
The word standard is doing a lot of heavy lifting in that sentence. I don't want to re-build Gravity Form's conditional logic or feeds to PayPal & HubSpot systems, so I'm not going to.
You might be the only one who believes a conversation loses all value if someone benefits from it, and who thus reduces an otherwise interesting discussion to "just an ad."
Craigslist is misspelled (there is an "s" in it).
Giving me a photo credit would be courteous as the author of that image. https://thegongshow.tumblr.com/post/345941486/the-spawn-of-c...