Maker’s Schedule, Manager’s Schedule

This is a classic post from Paul Graham on Maker’s Schedules versus Manager’s Schedules:

There are two types of schedule, which I’ll call the manager’s schedule and the maker’s schedule. The manager’s schedule is for bosses. It’s embodied in the traditional appointment book, with each day cut into one hour intervals. You can block off several hours for a single task if you need to, but by default you change what you’re doing every hour.

When you use time that way, it’s merely a practical problem to meet with someone. Find an open slot in your schedule, book them, and you’re done.

Most powerful people are on the manager’s schedule. It’s the schedule of command. But there’s another way of using time that’s common among people who make things, like programmers and writers. They generally prefer to use time in units of half a day at least. You can’t write or program well in units of an hour. That’s barely enough time to get started.

When you’re operating on the maker’s schedule, meetings are a disaster. A single meeting can blow a whole afternoon, by breaking it into two pieces each too small to do anything hard in. Plus you have to remember to go to the meeting. That’s no problem for someone on the manager’s schedule. There’s always something coming on the next hour; the only question is what. But when someone on the maker’s schedule has a meeting, they have to think about it.

I can’t stress enough the importance of this post. First, if you are a manager managing makers, you better understand this schedule. When Infinity Softworks was bigger, I tried very hard to schedule meetings with my development team at the beginning or end of these multi-hour blocks, that way their interruptions were minimized. We — me and my VP of Technology — also blocked as much as we could. A good development or product manager should be blocking and tackling for the dev team, making sure only important stuff interrupts the developers’ schedules.

Second, now that Infinity Softworks is small again and now that I am writing code again, this issue is my second biggest source of frustration. [1] It is so hard to find large blocks of time to write code when I am still managing the business at the same time. I have taken to literally scheduling off entire days. I try to do this twice per week and leave other blocks open, but it is really hard to do this while accommodating other’s schedules. Sometimes it works best to just schedule nothing at all instead. One week dedicated to meetings and the next dedicated to development. This too is hard since momentum can carry over week to week. And if you really want to get my going, bring up cancelled meetings, one of my biggest pet peeves, especially when done last minute. [2] Talk about screwing up a very good maker’s schedule.

[1] Except sales. Those are always frustrating.
[2] Dirty windshields is another.

I Stopped Listening After You Said “I could easily get sign-ups to double.” Go Do That.

Yesterday I wrote on Phil Libin’s thoughts on the freemium business model. After writing it I was reviewing some old saved articles and came across one written a year ago by Jason Cohen, founder of WP Engine and writer of A Smart Bear. His argument, or rather an argument placed before him, is that there is only one important metric and picking it is critical [emphasis his].

I was listening to Noah Kagan (founder of AppSumo and the marketing mind behind Mint, and the author of this great guest post) talk to the current crop of Capital Factory companies, when he said something so simple, so obviously correct, and yet it completely changed how I thought about my approach to WP Engine.

He said: “A startup can focus on only one metric. So you have to decide what that is and ignore everything else.”

Okay, I thought. Makes sense. And after reading all that stuff on Evernote the answer was pretty clear to me: get more customers. Apparently for once I was ahead of the curve as the very smart Mr. Cohen was focused on a different metric. I hate to reproduce this much of someone else’s article but I hope Jason will forgive me this once [emphasis his]:

NOAH: So if you could change just one thing at WP Engine, what would it be?

ME: Well Dharmesh told me it’s our cancellation rate. And Dharmesh is a SaaS business-model God, as evidenced by his well-reasoned Business of Software speeches and tangible success with Hubspot.

(Yes, I proceeded to lecture Noah about SaaS business models, as if he didn’t already understand, probably to prove that I did know, or to finally work out for myself what I believe. If this isn’t enough for you, here’s my expanded brain dump on cancellation rate.)

See cancellation rate is indicative of several important things. First, whether we’re providing a genuinely valuable and desirable service. After all, I can bludgeon a person into signing up with us through marketing and salesmanship, but if they don’t stick around it proves we’re not really providing something they need, at least not at this price. So it’s an important measure of the service itself.

Second, and more “metrics-y,” cancellation rate is one of the keys to computing customer LTV (lifetime value). If we know a typical customer pays us $50/mo and stays with us for 30 months, that’s $1500 in “lifetime” revenue. That helps us answer questions like: How much can we spend to acquire a customer? Or: How many customers do we need to produce $10m in revenue?

But the key to computing LTV is “how many months will a customer stay with us,” and the key to that is cancellation rate — the higher the rate, the fewer the months, and LTV plummets. High LTVs are nice because it means the business has good cash flow, and means we can spend more on things like marketing and advertising.

So yeah, I want cancellation rate to go down!

NOAH: OK.

(That’s how Noah says, “I heard everything you said. I’ve heard it before. It’s technically accurate, but you’re a dumbass and you’re missing the whole point. But you won’t listen to the truth until you get this bile out of your system.” Noah is a man of few words. Unlike me.)

NOAH: So do you think you could get your cancellation rate from 3% to 2.5%?

ME: Yeah I think probably we could, and that could increase our LTV by 15%.

NOAH: Let’s say you did that. Congratulations. What would be different?

ME: Oh, we’d have more revenue and we could spend more on ads.

NOAH: That’s it? All that would change is you’d spend more on ads? That’s important? That makes the business fantastic?

ME: Well no, I guess things wouldn’t change that much.

NOAH: You should only be doing things that can be “that much.”  If you increased signups by 2x would you say that would make a big difference?

ME: Heck yes, that would be huge!

NOAH: So do that and ignore the cancellation rate.

ME: But I can’t just ignore it because: I could easily get sign-ups to double if I just spent 5 times as much on AdWords, but then the lead quality would suck and cancellation rates would skyrocket and in the end I haven’t done anything meaningful, and I probably made things worse because now we’re sifting through all these crazy people who won’t even stick around and it just doesn’t seem strategic.

NOAH: I stopped listening after you said “I could easily get sign-ups to double.” Go do that.

ME: But what’s the good of a “sign-up” if most of them cancel?

NOAH: You don’t know they’ll cancel. What if you got sign-ups to triple? And cancellation rate doubled, from 3% to 6%. You’d still be growing almost three times faster.

ME: Oh yeah. Shit. Oh yeah.

It worked. His subscriptions went way up and his cancellation rate didn’t change noticeably.

As Jason noted, at a little company there is no time for little changes. A/B Testing, tweaking AdWords copy, landing page optimizations, cancellation rates – all little stuff. Engineer the costs right and focus on moving the big dial. Incredible advice I hope I will always remember.

“Focus On Free And the Emium Will Follow”

I’ve been doing a bunch of research on Evernote and their implementation of the freemium business model. In the early days, Evernote CEO Phil Libin was a treasure trove of useful information and perspective on their business, including enough data to make some reasonable revenue projections for a similar kind of product. A few things in particular really jumped out at me.

In an interview with Xconomy, Phil said:

Where a lot of people stumble when they’re thinking through this model is that they get stuck on the percentage of people who pay. If 98 percent of your customers are using it for free, it seems like there’s no way that could be a good business model. But the percentage does not matter at all. What matters is the total number of people who are paying, and the total expenses you are incurring to get those who pay.

So let’s say our goal is to have a million people paying for Evernote. There are two ways of doing it. If we were a traditional product, and we wanted to get a million people to pay us $45 a year, we’d have to spend some very large amount of money on advertising and marketing. Or, we can get 50 million people to fall in love with the product and use it for free, and have 2 percent of them pay us. It’s actually a lot easier and cheaper to get 50 million people to use your software and have them fall in love with it and tell their friends.

I had never thought about freemium this way. Phil’s basic comment is: focus on the free and the paid will take care of itself. At one point in another article, he goes even further:

Right now, roughly 2% of all [registered] Evernoters are premium customers, which is good for business. As the service adds more users, both free and paid, Libin wants to maintain that rate at 5% or less. If people start converting en masse, “that means our free product isn’t good enough,” he says. “And if our free product isn’t good enough, what’s the point of being freemium?”

Frankly, this set of comments really blew my mind. Almost every Lean Startup book and website is chalk full of A/B Test examples and talk of optimizing price and landing pages. Phil says, in essence, forget it all. Focus on the free and the paid will follow. At the Founder’s Showcase, Phil gave his three bullets for a successful freemium product:

  1. Long term retention rate
  2. Product increases in value over time
  3. Low variable costs

I have a little harder time with this list, but only because of my own experience and the people I know who use Evernote. I am still skeptical that giving people a free product without any reason to convert will just get people to pay. Especially in today’s world of consumer’s pay nothing for apps and services, I think it is actually far fetched. So there has to be some stake in the ground, something that gets a customer to pay. Maybe that is fear that if you don’t pay then all your stuff will go away. That’s what Phil implies. For me with Evernote, that line was sharing. I needed to be able to share and have other’s edit my documents and at the time that was a paid feature. A business associate paid because he wanted indexing of pdf documents. But something got each of us to pay.

That doesn’t change, to me, the profound nature of what Phil says here. Focus on the free customer and the Emium ones will follow.

Size Doesn’t Matter (Anymore)

I had a funny thing happen the other day. We have been updating a partner product, getting it ready for some new uses and fixing a couple of issues that have arisen over the years. We host the trial on our side and the partner company, ETS, includes a copy in the exams for College Board tests.

The original product was completed in 2004 and designed exclusively for Windows, although for a while it also worked on Mac. And then Apple changed something in their implementation of Java and broke the app, plus Microsoft made changes in Vista and 7 that broke the app. (Neither change really impacted usage, just delivery.) We got a new trial build up on the site last week, fixing the issues and adding new features, and in the process I updated the content.

One of the pages was for requirements and listed among the requirements was 8MB of hard disk space required for the application.

That struck me as funny. First of all, I can’t believe how little space it required (and most of that was the long-defunct installer). Second, that the hard drive space was listed at all. The more I thought about it the more I realized that I haven’t seen a listing for how much hard drive space an app requires in years!

In 2004 every sector of the hard drive was precious. Now, not so much.

Live By The Platform, Die By The Platform

As a software developer the biggest risk I can take is developing on someone else’s platform. The irony, of course, is that, as a software developer, that is pretty much all I do.

Let me explain: when I write applications for an operating system I am writing on someone else’s platform. I have no control over that underlying platform. If that platform breaks my code, too bad. If that platform dies on me, tough luck. If that platform changes the rules of engagement, so sad.

Often times, as developers, we rely on two platforms or more. Say, for instance, I write an app for Android. Not only am I beholden to every change made by Android but I am also beholden to every change made by every licensee of the Android operating system. Now, let’s compound that problem. Let’s say I require login authentication using Facebook. Oy! Add fuel to the fire. Any changes made to any of those could have a profound impact on my product or service.

I wrote apps for Palm OS, made a good living at it , too, and was highly influential in that space. Does anyone care now? No. I might have been developing for VAX systems. I lived by the Palm OS… and died by the Palm OS.

Look, folks. I know we are all upset about what is happening to Twitter (info here, here and here) but the reality is that developing on top of it has been a questionable decision for a long time now.

The web is open, right? With my own server I’m in control, right? Even the web provides no safety. I do most of Infinity Softworks’ web work in Ruby on Rails. When David Heinemeier Hansson and the crew developing Rails decide to make a change, I’m pretty much stuck. Yes, at least there I can make decisions about when to upgrade to the latest version [1]. All the same, though, it isn’t really feasible for me to run Rails 1 forever. Not only does underlying support and my ability to advance and improve my own software end but I also never take advantage of fixes (like those for stopping SQL injection, one of the more significant problems for any database-based web app).

Don’t buy into that argument and think the web is safe? You’d still be wrong. Even if I can control my own destiny on the server, I still can’t in the browser. As if it would be the first time that Microsoft broke Internet Explorer and left me scrambling at the last minute to make something look right.

The problem is very easy to compound. I’ve been developing Rails apps longer than Objective-C [2]. There is a new framework called RubyMotion that lets me write apps for iOS in Rails and then the framework recompiles it into Objective-C. But iOS 6 launches in a month and how likely is it that RubyMotion can keep up? Will it be able to support all the new software and hardware changes? And if the platform doesn’t take off or the developers lose interest then the problem is even worse. By choosing that intermediate layer, I’ve made a profound business decision that could haunt me horribly in the future.

Even within Objective-C there are various off-the-shelf frameworks (such as frameworks for parsing and creating JSON files used to pass data between an app and a website) that help me write code faster. Choosing one that I rely on, one that isn’t being updated for major new revs of the OS, is an extremely dangerous proposal. If I’m going to pick one, I damn sure better be certain that either 1) I can update and change the code myself; or 2) I can swap it out for a different framework.

Now, let’s get real. Unless I am going to write the operating system and develop all the hardware and figure out my own programming language, it is inevitable that I will write software for a platform. The trick is to minimize the risk.

  1. Choose platforms that will likely be around long-term
  2. Pick platforms that give me some level of control
  3. Decide to work with stable companies
  4. Minimize the number of intermediate layers

We don’t have a choice. As developers we rely on platforms. Let’s be smart about picking the right ones.

[1] Assuming I am running my own servers and have control over such things.
[2] Although I code more in Objective-C and am much better at it.