← All discussions
S

Eight customers asked for the same feature. I said no to all of them

general

Eight customers asked for the same feature over a year. I said no to all eight. Here's the arithmetic that made it an easy decision, and it's arithmetic almost nobody runs, because the cost of yes arrives in a form that doesn't show up on any estimate.

The feature was multi user permissions. Roles, who sees what, an audit trail.

The estimate was five weeks. The cost was not five weeks

Permissions aren't a feature you add. They're a property every other feature acquires. Once roles exist, every screen asks who's looking, every export gets filtered, and every future thing you build carries a permissions question with it forever.

So put a number on that. Say it adds eight percent to each subsequent project, and your projects average three weeks.

What a five week build actually costs once you count the drag

Grey is the build. Red is the tax on everything you do afterwards.

Weeks
The build5.0
Plus drag on the next 10 projects7.4
Plus drag on the next 209.8
Plus drag on the next 4014.6

Twenty projects in, the hidden half is 49 percent of the total cost. You never see it, because it never appears as a line item. It shows up as everything taking slightly longer forever, which is invisible precisely because it's everywhere.

That's the general shape of the thing. A five week estimate is a five week estimate for the build and an open ended one for the tax, and the tax is the part that decides whether a one person business can carry it.

The gate it failed

The gates a request has to pass before I build it

It cleared the first three.

Three separate customers, easily. Works with how they already operate, yes. Could I support it in five years, this is where it started wobbling. Does it fit what this product is, and that's where it died.

Eight people out of about forty customers is a fifth of my base asking for the same thing, which by any normal reading is a strong signal. It was. It just wasn't strong enough to buy a permanent slowdown.

What I said

The same thing to all eight, in my own words each time. It's a fair request, I'm not going to build it, here's why, and here's what I can do instead.

Not soon. Not on the roadmap. Not maybe later. Those are the words I used to use and they're a slow no, which is worse than a fast one because it leaves the person waiting for something that isn't coming.

Two of the eight left. I knew both were likely to and one told me plainly that permissions were the blocker. The other six are still here, and three said they appreciated being told straight rather than managed.

What I built instead

What they wantedWhat I builtEffort
Assistant enters, owner approvesWeekly email listing everything that changed2 days
Client sees one account onlyRead only share link, single account, expires in 30 days3 days
Accountant needs access each JanuarySame link, plus a docs page on how to use itIncluded
Audit log of every changeNothing. Nobody actually needed this0

What was asked for against what was built instead

Five days against twenty five, covering the real job behind six of the eight requests.

That's the move worth taking from this. A request is usually a solution somebody has already designed on your behalf. The question isn't do I build what they asked for. It's what were they trying to do before they invented this, and can I get them there another way.

The audit log row deserves a pause. Nobody wanted an audit log. They wanted to answer one question, which was who changed this number, and a weekly email answered it for everyone who'd asked.

Where this reasoning fails

I've got it wrong in the other direction too, so this isn't a post about refusing being a virtue.

I refused a second currency for eight months on exactly this logic. It does touch everything. It was also blocking every customer outside one country, which is a far bigger group than eight people, and I couldn't see it because I was counting the people who asked rather than the people who never signed up.

That's the structural blind spot. Requests come from customers. The thing that would bring you customers who don't exist yet cannot arrive as a request, so a filter built on request counts will systematically refuse the things that grow you.

I don't have a clean fix. What I do now is split the question. Does this help people who are already here, which tags and requests can answer. And does this let somebody in who currently can't get in, which nothing in my inbox can tell me and I have to go and find out.

What the no I got right cost

Two customers, 58 a month, and a small recurring discomfort whenever it comes up.

I check it by imagining having said yes. Five weeks in spring, then permissions questions attached to the spreadsheet import work, the export formats, the reconciliation rewrite, and everything since. On the eight percent assumption that's roughly ten weeks of drag over two years, and I'd never have noticed a single week of it as a cost.

Which is what makes this hard. The cost of yes arrives distributed and invisible. The cost of no arrives as two specific people leaving, with names, in a week you remember.

Swarogan27d ago

0 replies

Sign in to join the discussion

Log in