You know what’s common among the “How I Work”s of  Jason Fried or Matt Mullenweg or anyone who’s building ‘cool’ software today?

Take Fried, for instance:

Of the 16 people at the company, eight of us live here in Chicago. Employees come to the office if and when they feel like it, or else they work from home. I don’t believe in the 40-hour workweek, so we cut all that BS about being somewhere for a certain number of hours. I have no idea how many hours my employees work — I just know they get the work done.

Or Mullenweg:

…my preference is to work from home. We’re very much a virtual company where everyone primarily works from home (or their coffee shop of choice). The half dozen of us in the Bay Area will go in on Thursdays to have a little company, but six days out of the week the space is usually empty.

But chances are you spend two hours commuting to and two hours from work. Or have to punch in and punch out. Or have to spend a minimum of 8 or 8 1/2 hours at work. Or have a limited number of holidays. Or have to take permission to work from home. Or all of these one-size-fits-all policies.

And but still, but yet, Management would concede that the folks at 37signals and Automattic are, by any measure, more productive than their employees.  And also that there’s a positive causal relationship between autonomy and productivity. So why aren’t more companies… why do policies at your average co overwhelmingly SQUELCH autonomy?

Management is uncomfortable with issues of autonomy [1], but they will tell you (sotto voce) they don’t trust their employees to be productive without a nurturing environment, oh forget it, without external control and supervision [2].  That’s tragic. Whyever hire people you can’t trust, watched over by supervisor watched over by supersupervisor watched over by all the way up to top management?

Because if every employee was someone you could trust, was as good as the best employee, there’d be no problem.  So why not hire everyone who’s as good? Because, <impatient shake of head>, because you can’t afford to pay everybody what you pay your best employees.

And then, doggedly you ask, but then would you need as many people? Wouldn’t you have fewer people, better people, autonomous people, sensible productive happy people, if you hired just the really good ones? And Management responds, reflex-like, <check!>, and where am I going to find these people?


What Management has is a problem of time. Finding these people, these really good people, wooing them, getting them excited, selling the role to them and selling them on the role is intense, time-consuming work.

And but running co is a daily operation. That moment when co becomes too big for Founders (the very who metamorphose into Management) to run effectively, that moment is the moment when Founders need to spend time, emotion, effort finding and netting those good people and it is also the moment when they can least spare that time, emotion, effort.

So it goes. From Founders to first-rung Management to middle Management to all the way down, supervisoring and supersupervisoring. So then what do you do?

What indeed?

[1] or with any issue involving people except for the stuff the people produce for the co.

[2] Except for their best. And they can’t make exceptions for those they can trust because that’d make the rest resentful.

Pipe, Platform, Application

Some great ideas for operators to better utilize (and monetize) their assets: expose users’ location data, expose their social graph, building micro-payment systems that make sense, become verified ID providers. Just reading the article will set your head abuzz.

These are solid, solid ideas. But they require operators to think of themselves as platforms, making money off access to APIs. And that is just not in their DNA. Rather, in their rush to corner every buck there is to be made in the mobile space, they have tried to integrate vertically – running businesses from cell phone towers to handset applications, doing only a few things well.

They’ve attempted to jump from being a pipe to building applications bypassing the development of platforms in between – for identity, social, location, payments – to build good applications, not one-offs.

Too bad. That’s stunting the development of an entire, first-of-its-kind-in-the-world mobile ecosystem in India.

My reading workflow on the iPhone

Instapaper for iPhone is a simple concept, but simply beautifully executed. It is a joy to use.

It is where I spend most of my reading time on the iPhone.

So it made sense to think about how I use the application, what my reading workflow is on the iPhone. And here’s what it looks like:

I send articles and pages to Instapaper via one of
1. emailing the link to my private Instapaper email address
2. using the ‘send to Instapaper’ menu item in several iPhone apps
3. using the ‘send to Instapaper’ bookmarklet on my PC browser

Email to Instapaper is a fantastic idea. There is just so much that I browse on Mobile Safari and don’t want to read immediately. This includes links from Twitter that I open, scan and email. I doubt I’d use Instapaper as much if I couldn’t email articles to it. [1]

And I share articles I like to Twitter from within Instapaper. The app automatically appends a short URL to the article at the end of the tweet. So far, I’ve sent around 50 articles to Twitter from Instapaper.

[1] Yes, there’s the Mobile Safari bookmarklet, but it’s inconvenient to set up; I’ve never gotten around to it. Emailing is so much easier.

Always tinker

I learnt recently that even when all indications are that your business (or life. or city. or whatever) is running fine, something could be wrong – in plain view – that those indicators can’t tell you.

The only way to discover these problems is to tinker around with data. Ask questions of it.

Here’s what happened.

Ours is a prepaid subscriptions business. You sign up, put money into your account and pick your subscriptions.

Our signups, payments and new subscriptions – the three primary indicators of our health [1] – were growing at expected rates relative to each other. Nothing seemed to be wrong.

Until one day, I discovered that many new signups didn’t have any subscriptions. That was unexpected. It meant that most of our new subscriptions were via older subscribers.

That meant – and this was quickly confirmed – that most of our payments were also made by older subscribers. This is a problem, and we commissioned a quick survey to find out what was wrong with our new signups.

But then we tinkered further. We plotted a histogram of (normalized) new subscriptions started (all of this is excluding renewals) versus how long ago the subscribers had signed up, and we found this:


Click for a larger image - bet you can't read the tiny text


Astonishing. The older the subscriber, the more the number of new subscriptions they started recently [2]. We had a larger problem than we expected; our older subscribers were so active, they’d hidden how un-engaged our newer subscribers were for several months.

While we took immediate steps to fix this, we also realized that it’s hard to build a dashboard for stuff like this. You can – and should – track primary measures of success, results of specific campaigns, and suchlike. But under-the-surface stuff like this – we’d never have figured it out if we hadn’t tinkered with data.

[1] There’s also ARPU and churn, but they aren’t material to this discussion.

[2] The data for months 8 and 9 is skewed by a small set of people with a lot of subscriptions each, but they’re still much higher than any other month, and the trend is the same

(Cross posted from the MyToday blog.)

Cost of acquisition versus lifetime value

A post on Fred Wilson’s excellent blog about cost of acquiring each customer versus the lifetime value of that customer. And it’s pretty simple: “LTV has to be greater than CPA or you won’t be able to scale – or, for that matter, survive.

This seems obvious. But when you’re preparing a revenues-versus-costs estimate for a business plan, you often overlook how much you earn versus spend per customer over time. Here’s a slight variation of that from a few weeks ago:

The CEO of our firm shot down a recent plan I presented, one that involved both the mobile web and SMS working in tandem. The product was different, compelling, and the estimates said we’d be profitable in a year on the gross. But our SMS costs were 80% of the revenue we would have earned from advertising.

“Keep SMS out; figure out the mobile web part. If you’re spending 80% of your revenue on acquisition and retention, you won’t have enough to spend on content and infra and operations and product innovation – and that’s not even counting people.”

And this was true not just in the month we acquired the customer. Month on month, the SMS costs kept pace with the ad revenue per customer [1], so we’d never have enough money to spare. In other words, the CPA was lower than the LTV. But not nearly low enough [2].

[1] It was also likely, I realised later, that over time the customer would yield less ad revenue as he/she tired of the service, but the SMS costs would be the same. So we would have to evaluate the customer’s worth and adjust SMS quality of service constantly, making things rather complicated.

[2] As an aside, these costs also grew linearly not just over the lifetime of each customer, but also with the addition of every new customer – there were no economies of scale to be had. If there were, the total lifetime value of all customers would have grown faster than the total (SMS) cost of acquisition and retention, and it would’ve been viable after a point of time.