5 ms·

This “Cambrian explosion” is exactly what we’re trying to help with at Monolist (https://monolist.co https://monolist.co). The number of tools used daily is g

This “Cambrian explosion” is exactly what we’re trying to help with at Monolist (https://monolist.co https://monolist.co). The number of tools used daily is growing, which is in one way beneficial for the worker since they get a better and more specialized tool to do their work. However, it increases fragmentation and the chances of missed work. Email is the most common solution, but that has its own downsides and seems to be used less and less for daily work. We think the solution is an ever-updating and fully synchronized “command center” for everything across every app you may be using.

OJFord 7y ago
That looks really cool, but unless employers are paying $10pcm seems steep to me, considering it's more than the underlying tools (which are potentially all used at free tier). Have you considered pricing by #integrations connected?
- enkarta 7y ago
  We're always considering various pricing models, and per-integration was one of them. For the time being, though, we've decided that would be counter to our primary goal: allowing you to see and process all of your work from in Monolist, as quickly and easily as possible.
  - OJFord 7y ago
    Hm, I do get that, but I would suggest that the value changes with the size of my 'all'. To be honest, just based on the screenshot it seems like a nicer management for even a single service than GitLab/GitHub's notifications.
Waterluvian 7y ago
I think instead of another tool to wrangle too many tools is as you already headed off: email. Gmail already reminds me of stuff like emails I didn't respond to. I've set up some filters and scripts to do more like create a triage queue for PRs and such.
- rolleiflex 7y ago
  This conversation reminds me of the ever-relevant xkcd: https://xkcd.com/927/ https://xkcd.com/927/
- enkarta 7y ago
  Email does indeed catch and notify you of most things, and Gmail is getting smarter every day. The one major downfall, though, is that it's stale: the minute you receive an email it's out of date, and if anything requires additional emails to send updates. It's also those "filters and scripts" you've set up to create your own triage queue that we're trying to replace. The average user should not have to write scripts to receive and process their work in an efficient manner. That's what we're trying to solve at Monolist!
koolhead17 7y ago
Liked what you folks are doing with monolist. :)
ken 7y ago
I agree we need to attack this problem, but is another proprietary service to connect via proprietary APIs to your other proprietary services really the best answer? This looks like even more complexity than before (when something breaks, who do I go to for help?), except now I'm paying yet someone else to stand between me and my data. We didn't get where we are today, in any field, using this approach. We don't have 30 different measurement systems, and a company whose job it is to coordinate conversions between them. We don't have 30 different text file encodings (any more!), and a company whose job it is to automatically convert them as necessary. We say: here's the standard, and now you can use it or be ostracized in the market. If writing custom adapters to interface with GitHub/GitLab/Jira/... is anything other than a temporary solution, while you work on some grand plan to get issue-trackers all on the same page, then it's just a money-grab on the road to failure. Someone will cut off API access, or drive up your costs, or refuse to offer an API, and users will be stuck with "one command center (for the 3 most popular services they use), plus 3 oddballs", and it's just not going to be worth the hassle. It's a band-aid. Normally you stick a band-aid on something that will heal itself, and then rip it off tomorrow. This particular problem is getting worse. This is a very pretty band-aid, but you've applied it to a sucking chest wound.

OJFord 7y ago

That looks really cool, but unless employers are paying $10pcm seems steep to me, considering it's more than the underlying tools (which are potentially all used at free tier). Have you considered pricing by #integrations connected?

enkarta 7y ago
We're always considering various pricing models, and per-integration was one of them. For the time being, though, we've decided that would be counter to our primary goal: allowing you to see and process all of your work from in Monolist, as quickly and easily as possible.
- OJFord 7y ago
  Hm, I do get that, but I would suggest that the value changes with the size of my 'all'. To be honest, just based on the screenshot it seems like a nicer management for even a single service than GitLab/GitHub's notifications.

Waterluvian 7y ago

I think instead of another tool to wrangle too many tools is as you already headed off: email. Gmail already reminds me of stuff like emails I didn't respond to. I've set up some filters and scripts to do more like create a triage queue for PRs and such.

rolleiflex 7y ago
This conversation reminds me of the ever-relevant xkcd: https://xkcd.com/927/ https://xkcd.com/927/
enkarta 7y ago
Email does indeed catch and notify you of most things, and Gmail is getting smarter every day. The one major downfall, though, is that it's stale: the minute you receive an email it's out of date, and if anything requires additional emails to send updates. It's also those "filters and scripts" you've set up to create your own triage queue that we're trying to replace. The average user should not have to write scripts to receive and process their work in an efficient manner. That's what we're trying to solve at Monolist!

koolhead17 7y ago

Liked what you folks are doing with monolist. :)

ken 7y ago

I agree we need to attack this problem, but is another proprietary service to connect via proprietary APIs to your other proprietary services really the best answer? This looks like even more complexity than before (when something breaks, who do I go to for help?), except now I'm paying yet someone else to stand between me and my data. We didn't get where we are today, in any field, using this approach. We don't have 30 different measurement systems, and a company whose job it is to coordinate conversions between them. We don't have 30 different text file encodings (any more!), and a company whose job it is to automatically convert them as necessary. We say: here's the standard, and now you can use it or be ostracized in the market. If writing custom adapters to interface with GitHub/GitLab/Jira/... is anything other than a temporary solution, while you work on some grand plan to get issue-trackers all on the same page, then it's just a money-grab on the road to failure. Someone will cut off API access, or drive up your costs, or refuse to offer an API, and users will be stuck with "one command center (for the 3 most popular services they use), plus 3 oddballs", and it's just not going to be worth the hassle. It's a band-aid. Normally you stick a band-aid on something that will heal itself, and then rip it off tomorrow. This particular problem is getting worse. This is a very pretty band-aid, but you've applied it to a sucking chest wound.