Signing up for a service

30 seconds. And that 30 seconds includes initial customization: confirming your name and so on.

Installing something on a server

10 minutes. Ideally 5. Once again, that includes the initial customization: setting your site name in a Known instance, for example, uploading your profile photo, and choosing the theme. Tweaking the theme can take longer, of course.

Writing a plugin for an open source app

One hour to testing that you're on the right path, two hours to having an initial prototype fully working. This might be generous: it's possible that the bar for the "1 .. 2 .. 3 .. is this on ..?" testing phase is more like 10-15 minutes, and the prototype phase is an hour.

Implementing a web standard or format

One afternoon. RSS succeeded (at least for a while) because you can sit down after lunch to take a look at it blind, and have something working to show someone by mid-afternoon. I'm convinced this is true of HTML, too.

The indieweb technologies all also have this property: pick them up after lunch, do something with them by 3pm, and have something cool working by the time you go home.

Everything happens in a sitting

This also works with proprietary APIs. Twilio was wildly successful because using it was unbelievably straightforward - and it drove a lot of business for them. APIs are interfaces by definition, of course, and so are plugin hooks and format specs. These all have to be as simple and clear as possible.

Making things simple isn't dumbing them down; it's making them more useful. Nobody wants to spend time learning your technology or figuring out your service; they want to spend it on their own goals. The bar has to be that you can get to grips with something very quickly, so people can move onto what they were actually trying to do.