← All discussions
S

Six weeks building a feature three people use

general

Before you build anything that takes more than a week, work out how many people need to use it before it pays for your time. It's one line, and the answer is usually much larger than you expect.

users needed  =  build hours x your hourly rate / annual value per user

I built a feature over six weeks. Fourteen weeks after shipping, three accounts had used it and one of them was the customer who asked for it.

Two hundred and forty hours. At 40 an hour that's 9600 of my time. If the feature is worth 30 a year to somebody who uses it, I needed 320 users to break even.

Users who must adopt a feature before the build has paid for your time

The bar you land on depends far more on value per user than on how fast you build.

BuildValue per user per yearUsers needed
40 hours3053
80 hours30107
240 hours30320
240 hours10960

I had 41 customers. The break-even needed 320 users. It was arithmetically impossible before I wrote a line of code, and the sum takes a minute.

Nobody does this because of how the decision gets made

My largest customer, on a call about something else, said it would be great if the tool could do a certain thing. I said yes on that same call, without writing anything down or asking one follow up question.

How a six week build got decided in one sentence

The mistake is at week one. Everything after it was competent work on a decision nobody checked.

The execution was fine. The feature works, it's well built, no bugs I know of. This is entirely a story about ninety seconds.

Three reasons I said yes, and only one is about the product.

He was my biggest account, so part of me heard the request as a condition of him staying. He never said that. There was no reason to think it.

He asked in a way that assumed it was easy. It would be great if it just did X. That framing makes refusing feel disproportionate, and the correct response is to find out whether it's easy rather than accept the framing.

And I wanted to build it. Interesting problem, and I'd been doing invoicing work for two weeks. That's the reason I'd have denied at the time and it's probably the biggest one.

The signals I had

What I hadWhat I didWhat it meant
One customer had ever askedTreated it as representativeOne person had a problem
Zero mentions in 182 support ticketsDidn't check until afterwardsNot a shared problem
He described his own workflowNodded alongSpecific to how his team works
I estimated a weekNever revisited at week threeWrong by six times
No definition of successDidn't write oneNothing could disprove the decision

That last row is the one I keep returning to. I'd never written down what would make six weeks a good use of the time. With no number, there was no moment where the project could fail, so it simply continued until it was finished.

The estimate problem makes it worse

I estimated a week and it took six. That's a factor of six, and it's not unusual, it's roughly the industry's standard error on anything unfamiliar.

Which means the break-even calculation should be run on your estimate multiplied by three or four, not on your estimate. Do it on my original guess of a week and I needed 53 users, which felt reachable. Do it honestly on six weeks and I needed 320, which never was.

If you take one habit from this, make it that. Run the sum on the pessimistic number, because you're going to spend the pessimistic number.

What it really cost

Three accounts in fourteen weeks. The customer who asked, who does use it. One who tried it twice. One who has it switched on and has never opened the screen.

Meanwhile my support tags said 41 people were fighting with spreadsheet layouts. That work took two weeks when I finally did it, and it removed the single most common reason people gave up in their first fortnight.

Six weeks for three users, while a two week job sat behind it addressing my largest cause of churn. That's the real cost and it's much larger than six weeks of time.

What I do now

When somebody asks for something, I say the same sentence. That's interesting, let me see whether other people have hit the same thing, I'll come back to you this week.

It isn't a no. It buys three days, which is enough to search the support tags, check whether anyone else has ever mentioned it, and think without a person on the phone waiting.

About a third of requests don't survive those three days. And here's what I didn't expect. Almost nobody minds. In two years exactly one person pushed back on being told I'd look into it, and he was right to, because I'd forgotten to come back to him.

The pressure I was responding to on that call was almost entirely manufactured by me.

The sentence that would have saved six weeks

If fewer than ten accounts use this within three months of shipping, it was a mistake.

I'd probably still have built it. But I'd have found out in month three instead of vaguely noticing in month five, and I'd have had a number to hold the next request against.

I now write that sentence for anything over a week. It takes a minute. It hasn't stopped me building things, and it's twice stopped me building the second version of something the first version had already told me nobody wanted.

What the customer thought

Nothing, for a long time, because I was embarrassed.

When I eventually mentioned it he was completely unbothered and slightly surprised I'd built it at all. He'd been thinking out loud and would have been fine either way.

So the condition I'd imagined, where refusing risked my largest account, never existed anywhere except in my head. It cost six weeks.

Swarogan27d ago

0 replies

Sign in to join the discussion

Log in