Priorities: Since my job gives me the flexibility to work on lots of things, lately I’ve been concentrating on two of the things that are most important to our business as a whole: sales, and more sales. Although I have some insights and funny anecdotes about my conversations (Q: “May I speak to Mona?” A: ”Last I heard, she choked on a chicken bone and died”), they’re not generally appropriate for this blog.
Progress: As a whole, we’ve been concentrating on JobTracker, which means that there’s little or no change to what’s going on in the Skedsheet world. This is frustrating to all of us, but at the end of the day, we need to spend a good chunk of our development effort on what brings us money. This is the classic trap that Clayton Christensen describes in the Innovator’s Dilemma.
We need to keep serving our existing customers, and we continue to bring them a higher level of service, but we’re possibly leaving ourselves open to competition from the “low end” – Skedsheet could provide a solution to companies like our customers who don’t see the value of our relatively “high end” products in the JobTracker family.
Writing on a daily or weekly basis takes focus and concentration. When there’s not much progress to talk about, and your priorities are shifted temporarily, it’s hard to come up with good ideas on a regular basis. Because of the priorities, it’s also hard enough to justify the time you need to spend to do it well.
Enough excuses…I’ve got a stack of half-written posts with ideas, so hopefully I’ll get back on the writing wagon.
One of the main reasons that we’re excited about Skedsheet is that we want to eliminate “implementation” altogether by having a software utility that’s easy enough to just get going. But, it’s still on my mind…frequently. Any time you decide to change something in your life or business, the process requires effort, and maybe a little pain.
There are some steps you can take to make sure that when you’re making a change (buying software, using new equipment, changing pricing, or introducing new products), it goes smoothly.
- Get everyone on board early. If your coworkers and employees don’t know what kind of change is coming, they will revolt. The earlier they’re involved in the process, the better.
- Be ready to break things. Making a change to your business means breaking the way you do things today – even if it’s already broken. This is scary, but it’s necessary because you can’t just add to what you’re already doing – that doesn’t fix things.
- Set deadlines. If you don’t have a deadline for getting software implemented, it’s really easy to put it off another day. Setting hard deadlines and sharing it with your coworkers is a good way to make sure you’re accountable.
- Uninterrupted time. This is probably one of the hardest, especially if you’ve got the responsibility for changing your business and the authority to actually do it… your time is in short supply.
- Remember the goal. Every so often you need to take a deep breath and remember why you’re making a change. It’s to fix the problems you had before or allow you to do something new.
It’s not foolproof, because there are always going to be unexpected problems that come up in a software implementation, but having a little planning and perspective will help.
We’ve been putting money into Skedsheet, but haven’t really thought about a business plan much. Typically you need to think about finances, market, and plan for our products. Here’s a swag at the finance part for Skedsheet. Of course, the dirty secret of any business plan is that this is all a guess…
Let’s say that the cost of doing the beta version of skedsheet is around $100K – that’s development time, graphic design, and the direct costs of setting up a website, getting trademarks, and all of the other administrative parts of setting up a new product. I think that’s the right ballpark.
After that, there are the ongoing costs of running skedsheet. We’ll need servers, which will probably start around $500/month, and grow as we’re successful. I’m sure we won’t have all of the features right in the first version, so there’s going to be ongoing development, and I’m sure that we’ll have to spend time on customer support, too. Let’s say that adds up to $2000/month for each.
Even if we’re willing to toss out the initial investment, that means around $5000 per month just to break even. And if we want to recoup the original outlay in the first year, it looks more like trying to get $14000/month. Zoiks! maybe instead we want to break even on the original investment in 2 years, which makes it closer to $10K/month.
While we haven’t thought about price in detail, there are a couple of strategies we can take. We’ve ruled out having expensive software. Even if we choose a number as low as $100/month, chances are that we’ll need a sales process, and a sales guy to convince people to part with their money.
We can’t be totally free either. That could get lots of users, but there’s not a chance of making money for just giving away our service. So the answer is Free + Cheap.
Is a $10/month cheap? $1? I think that the right model for us is to have a small group of our hardcore users pay for the costs, and allow us to give away our software to 95% of the people who want to use Skedsheet. So if the numbers I just pulled out of the air would work out, it’d be something like:
(Paid Users) x $10 = $10000, so we’d need a thousand paid users. And if
(Paid Users) = (All Users) x 5%, we’d need twenty thousand people using Skedsheet before it makes financial sense.
So, the next question should be “Does Skedsheet solve a problem for tens of thousands of people?”
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.