Archive for August 2009
The blog StationStops, which writes fairly critical articles about the service on the Metro-North railroad service in New York has been wrangling with the New York Metro Transit Authority about schedules.
Schedules! Who’d of thought that could be controversial?
Chris Schoenfeld, who runs StationStops, created an iPhone application which provides the Metro-North train schedule. The whole idea was that he didn’t like the paper schedules that were available because they were hard to sort through and read. And, the MTA’s website and ways of publishing their schedule to an iPhone didn’t work for Chris, because they relied on a live internet connection – something you don’t always have when you’re in a subway in New York.
So, he did what any good nerd would do – he fixed the problem for himself, realized that it might be useful to other people, and built a product around it. Since then, he’s gotten cease-and-desist orders from the MTA and requests for licensing revenue.
It shocks me that the MTA would do this – what possible good can come from this kind of action? Even if originally they thought that they might be able to get a few thousand dollars in licensing money from Chris, wouldn’t they realize that they’re burning much more goodwill?
And most likely, the outcome will be that hundreds of apps or sites like this pop up just to spite the bureaucrats. Here’s more coverage of the story:
I get lots of emails every day – customers, vendors, coworkers, and occasionally friends send me stuff. I’m not overwhelmed by the volume of emails, but some days I wish that that everyone was a considerate email writer.
I’m not even worried about spam – between the filters on our mail server and the Bayesian filter on my client, things that are spammy disappear before I can see them, or end up a folder for junk suspects. Of course, you shouldn’t make email that looks like spam, but I think most of the emails that bug me are well-intentioned. Here are 5 rules for writing a clear, readable email.
- Just rehash. Don’t introduce a new concept in an email. It’s hard enough for me to read an email when I understand the point…but trying to teach me something new, sell me something, or proposing a new venture just doesn’t work well in email. Email is best when it’s the follow-up to a live or phone conversation.
- Short & sweet. There are probably 20-30 emails that I want to read and act on every day, but I don’t want to kill my whole day to do it. I’m a pretty fast reader, but there’s a huge difference between spending 1-2 minutes on an email versus 5 minutes – in the worst case, that means almost 3 hours per day. Just reading… and trying to understand. Usually, if I see more than one long paragraph, I’ll just make a phone call.
- No emotion. Nuance, sarcasm, anger, and sympathy are really hard to convey in an email. Even if you think your smileys give the right emotional cues, they could easily be missed. Controversial subjects can spiral out of control too easily, so it’s much better to leave the tough stuff to live conversations.
- Bullets won’t hurt you. I love enumerated lists, and I think the world would be a better place if that’s the only way people communicated. Having numbered bullet points in an email allows you to reference specific parts of a message, makes it a little more readable, and can convey priority without much effort.
- Contact info. It surprises me how often I get emails without contact information. “blah blah blah… from John”. For work, most folks are somewhere in our customer database, and I can look it up with some effort based on context, but even that occasionally fails – for example, if someone’s sending an email from a hotmail account with an unrecognizable name. It’s really easy to add a signature to your emails, so add a useful one.
Just following these 5 tips won’t make your emails great, but at least it’s a step in the right direction. Personally, there’s a much better chance that I will read an email and care if it’s short, concise, organized, and isn’t blindsiding me.
We’ll probably have two flavors of Skedsheet – one free, and one paid. I’ve been thinking about which features should be in each version, but I need to take a step back and ask myself:
“Even if it’s free, how do we sell this puppy?”
I know you don’t need to “sell” free stuff – at least not in the traditional sense. It’s much more about providing something in exchange for your time. Since we’re giving something valuable, and making it easy to share…each of our “free” customers should become an advocate for our software.
But, we still need a Unique Selling Proposition: What’s the reason to even look at us?
I expect people to compare the cost (in time and effort) of Skedsheet to using Outlook and Excel. I’d argue that Outlook and Excel are both effectively free – I bet you didn’t pay for them and you already know how to use them.
Here’s what I’d want to say:
With the system you have today, you’re re-typing some details from your spreadsheet onto the calendar, and figuring out how to show it to other people.
Of course, there’s the chance of making mistakes that cost big bucks, as well as time wasted looking in more than one place for information.
I think we’ve another unique concept in Skedsheet that I haven’t seen touted other places – the idea of multiple dates being tied together as one “job”. I don’t know how to describe this well – but that’s what ended up being the defining feature for our JobTracker software, and it seems like it will apply more generally through Skedsheet.
But, because it’s free, there won’t be a salesperson telling you any of this. Instead, I assume the sales pitch will be:
- Right here, with us writing about our software on this blog.
- An demo video that will explain everything clearly.
- Stories and examples of how other people use Skedsheet.
- Skedsheets that you see because a friend shared them with you.
We keep struggling with how quickly to show off Skedsheet – is what we have now still just a prototype, or is it getting to be a real product?
Part of the problem with the software is that it’s ugly, and there’s some minimum level of attractiveness that needs to be there so our future users don’t run away with bleeding eyeballs.
We’ve been working with a designer to help fix the ugliness. To start, we needed a logo, website, and some design in the software, itself. I was trying to wait until we could actually update our website with the new design, but I’m too excited. Voila, the logo!
What’s cool about this is that since we’re starting with a blank slate, we were able to give minimal direction, and be happy with the outcome. I’d say that the logo succeeds in meeting the few requirements that we had.
This logo is very typographic, original, and has a simple icon that suggests a spreadsheet or a calendar. It works on a black background, too:
So far, so good. Hopefully we’ll be rolling out decent-looking website soon. What we’re realizing is that this is an iterative process. We’ll have the place-holders for the web pages and parts of the software that we imagine needing… after a few months, we’ll understand what we really need.
Skedsheet is starting to come together – there’s some core functionality, a graphic design in the works for the website and application, and daily (well, maybe weekly) progress in both of those areas.
One of the missing ingredients is to figure out how we make money. I still think we want a freemium model for skedsheet, so the question is
“What’s free and what do you pay for"?
The dividing line all needs to be about value… what’s valuable enough to pay for? And, can we build a product that’s free for lots of people, but have a small percentage of users cover the cost of development and infrastructure?
Even the free version needs to be valuable – otherwise nobody will care. I want the free version to be useful for a single person working on a schedule, and maybe sharing it with a few other people. But if it’s being used by lots of people at a Fortune 500 company, we should be charging. The extreme cases are pretty easy to nail down, but we need to figure out where the dividing line should be.
Can we split up the features in a way to distinguish a casual user from a big company?
|Create 1 Skedsheet||yes||yes|
|Create 1 calendar view||yes||yes|
|See history of changes||yes||yes|
|Create more than 1skedsheet||maybe||yes|
|Create lots of calendar views||maybe||yes|
|Large Skedsheet size||no||maybe|
|Create lots of Skedsheets||no||how many?|
|Multiple editors||no||how many?|
Which other features should be on this list? Are there other dimensions for the free/pay boundary?
If you’re trying to manage a few schedules, but you care deeply about having your data secure, is that a feature worth paying for? How many editors is “a lot”? Would we really build a separate mobile version?
How do we make sharing and using Skedsheet really easy and not have new users worried about paying until they really find value?