The thing is, almost all services that people use for tracking projects nowadays have some way of interfacing with the information. So I have tools that know already what I've done. Why would I want to spend my valuable time writing that up again?
Just like anyone can build stackoverflow in a weekend.
In this case, the customer provides (and doesn't share) the content and community, so what's being sold is the weekend project software hack. And the target audience is already using separate project management and version control tools, and knows how to hack their APIs.
First off, there is probably a lot more to a system like this then you think. What happens when you need to add people to the team on the fly, or change the format of the email? Do you want to be the person who has to maintain this system for the foreseeable future? Is this what you really want to be working on?
It's a cheap bet that could shave off a few hours a week of work. Our standups can take up to 30 min each morning for our team if there are a lot issues from the pervious day. I rather have a 15 min standup and have time to prepare my questions the night before, or on the way to work.
It's hard to justify new systems like these when as engineers, we are conditioned to build our own tools when we see repetitive tasks that need to be streamlined. Personally I would love a system like this. It would save a lot of time for me each morning. On the other hand, I could see this going to the company graveyard of dead tools after someone finds a new system they read about on HN.
Agile practices can sometimes turn into Show & Tell time when people don't succinctly sum up there issues. Making people think about what they are going to say before they bring up blocks and issues they are having can definitely save time each day.
One of the ideas behind is, that we want to provide something using a communication channel people use every day rather than introducing a new one like Slack, Hipchat etc. However, StandupMail is a great addition to teams using those tools already.
Using StandupMail is not about sending in "dones" for every single task accomplished. It's more about a quick recap of what everyone thinks is important for the team to know to stay productive the next day and overlook the big picture of the project.
I agree simply acknowledging what to-do's people have ticked off in the day isn't that useful (BC can already do this for example) but there is room for intelligent insight here. You could determine people's productivity rate towards a milestone and provide predictions if things are on track for a particular milestone date etc.
I think then you would have a valuable service. Just my 2 cents ;-)
I think automatic information distributio is the right idea. idonethis has an API so you can have a ticket completion automatically show up: http://blog.idonethis.com/connect-apps-to-idonethis-with-zap...
You could think of the manual information entry as forcing people to write things down that they are doing which they are not writing down in the ticketing/workflow system.
The idea of using tools I already use to say what I did is valuable. In our summary email we send out everyones responses but we also include every commit that was done by each person that day.
If standupmail included other sources of data (manual email, github commits, gmail messages sent, zapier integration) - we'd def switch.
Remember Dropbox? https://news.ycombinator.com/item?id=6625306 with these comments: https://news.ycombinator.com/item?id=6625818
I think when the naysaying is "this is not technically feasible or efficient/too costly/has no revenue model", yet the theoretical idea is good in a "perfect world", you have a real shot at proving them wrong.
When the naysaying is "even if this works exactly as expected, most people would not get a lot of value out of it", assuming their reasoning is correct, then the naysaying can be justified.
It looks like most of the original concerns over Dropbox from sensible and experienced people fall in the first category, not the second.
I'm not a VC or startup/business person so I could be completely wrong, but that's the view I've managed to piece together over time. I think pg's model of "can you envision a small cult following of users who will really love this product/service?" is the best way to look at it. If you can get that initial cult following, then all other problems can (likely) eventually be overcome. If you can't get that, then you're sort of wasting your time.
I personally don't see the value in a service that emails a group of people and then gathers their responses when that data is probably already available and retrievable in an automated fashion.
I don't think you can compare questioning the value of Dropbox (which is a huge piece of software, handling sync across multiple platforms, even back then) to this.
Maybe there should be a "premium" option for an automated nightly conference call, where employees can call in and confirm that they replied to the nightly status email, and also share any cool stories about what it was like to be away from the office for a few hours. It would be a great team building exercise.
Another productivity booster is chemical castration. Families really eat up a lot of time, which ends up costing the companies. Employees who voluntarily get vasectomies could be given a 15% spot bonus.
However, the idea is to send a quick answer back, when your accomplishments are still "fresh" in your mind - Shouldn't take you longer than 5min.
And yes, workers should spend time with their families. I'm doing that right now, too :)
If you like this, take a look at https://github.com/agiliq/worktogether. We use and like idonethis, this app is just experimental at the moment.
Wouldn't anyone making any product ever say this?
It's a matter of principles (I shouldn't be compelled to enable JS on a website only to view its static content - or any content at all), it's a matter of accessibility (people with impaired vision who use text-to-speech software will have a harder time with this page)and it's a metter of compatibility (not all devices/browsers run JS)
I'm also not too fond of anything that would cause people to work later in the evening. The one problem I see this potentially fixing is the feeling of forgetting everything you did over the weekend.
StandupMail seems to want to replace daily standups for teams, which I don't think is a good idea.
First of all, standup meetings are essential to start the day. It's the team's huddle before heading out into the field. It's to provide updates on yesterday's play, but also to discuss briefly any topics of importance, making sure everyone's on the same page for the present day. Replacing that with a one-directional email update would hinder all that.
>INCREASE PRODUCTIVITY
I would argue that taking the time to write an email, read each other's update etc actually reduces productivity overall. It's much easier to go to a 5-10 minute standup and hear everyone's update as well as verbally provide your own update. In fact, if I need more clarification from someone's update, I'd have to interrupt that person after I've read the email, or write out more emails.
> Avoid time-consuming status meetings and interrupting the team from accomplishing their tasks.
Standups and status meetings are supposed to be brief. They usually happen at the end of day or beginning of the day where it provides a lot more value (as a wrap up or an anchor to the start of the day) than interruption (if any). If your status meetings are taking a long time, you're doing it wrong.
> NO MICROMANAGEMENT
If a regular standup = micromanagement, then how is an email reminder for standup updates not micromanaging? Keeping the team on the same page about what needs to be done is easier with a verbal standup. IMO whether there is or isn't any micromanagement in regular standups, it wont change with email updates. It's more of a team dynamic than a process/tool issue.
You might be right with your arguments if you see StandupMail as a tool replacing your Scrum standup. However, it's intended to be a tool for every team out there working on the same topic - most teams don't even know what a "SCRUM Standup" is (ask your sales team for example).
Distributed and remote employees I think is one of the biggest challenges facing the work place at the moment, with no good solutions available yet.
btw, your ssl cert is broken when visiting non-www.
Secondly, isn't this something most people with even basic scripting language savvy could whack together on their own (company) server? Setting up a mailing list with a daily digest (sent out first thing in the morning) and a daily 'reminder' e-mail in the evening isn't exactly hard. If I was so miserly that I'd want to screw my employees out of ten minutes of their time, I'd certainly be miserly enough to set this up myself, not pay 10+ euro a month for it.
Added feature: Perhaps users can send emails throughout the day if they want to, instead of waiting.
The scary part: Your company's information in the hands of a company you do not know much about. It becomes very easy to be kept hostage, I guess unless exporting your data and completely deleting it from their servers is an option.
In fact, using tools like slack, asana, phabricator, and github enterprise there's an overall goal to do less and less email and something like this would be a step in the other direction.
What we're looking at setting up is a centralized dashboard to tie our tools together and include status updates. The tool I'm looking at is [anthracite](https://github.com/Dieterbe/anthracite) which bills itself as an event manager ("an event / change logging/managament app").
On the surface, this looks like something you use to track when code is changed or server changes are made. And that is a lot of it. But it's really a way to display events and you can have pre-made filters of events (call them event streams). You can integrate it with your chat system or email to post status updates by hand, you could have task management systems like asana post updates, etc.
Granted, I'm not entirely sure yet if anthracite is mature enough for what we're looking for, but we definitely are angling for that approach.
On the other hand: I do like reading what my colleagues did during the day....
Idea is good but I am not convinced with the pricing. I can do it manually anyway by just cc ing the entire team.
I suggest to give it for free upto 5 or 10 users then charge for the members above that.
I'd also be hesitant to route somewhat confidential emails through a one-man band development shop who may or may not be snooping them out of interest.
