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?
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.
One of the most crucial skills when you don't have a boss telling you what to do is figuring our where to spend your precious time.
If a weekend project means, say, 16 hours of work, you need to value your time at less than $6.50 for this to be worth one year at the cheap plan.
If a whole team is expected to respond to the emails this service sends with new updates on a daily basis and do that in addition to whatever activity planning, communication and and tracking tools they're already using, then using this service instead of making a one time effort to get their existing toolset to spit out daily emails is probably a false economy.
And if they're currently not systematically tracking project activity, and relying entirely on verbal communication or email they're - for good reasons or bad - probably not overly likely to pay for to SaaS-based coordination tools either.
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.