The painkiller test: how I decide what to build next

The most useful framework I've picked up in ten years of building products is also the dumbest-sounding one. Every feature you could possibly build falls into one of two categories. It's either a painkiller or a vitamin. Painkillers solve problems the user has to solve, with a deadline or a financial consequence for not solving them. Vitamins make life a little better but don't cause real pain if skipped. The ratio of painkillers to vitamins in your roadmap is the roadmap. Everything else is decoration.

I didn't invent this framing. I've heard it attributed to a dozen different product leaders and it's probably older than any of them. What I can tell you is that every time I've ignored it, I've wasted months on the wrong things. And every time I've applied it honestly, I've shipped things that worked.

The difference that matters

A painkiller is a feature the user has to use because not using it costs them money, time, legal exposure, or a missed deadline. If a user skips it, something bad happens. They get fined, they lose income, they miss an opportunity, they break a rule. The feature has teeth. Users don't need to be convinced to care about it because reality is already doing the convincing.

A vitamin is a feature the user would enjoy, find clever, or appreciate in a review, but not one they'd ever stop their day to adopt. If they skip it, their life continues unchanged. Vitamins are nice. They're also, in almost every case I've measured, where product teams waste most of their effort. Because vitamins are easy to imagine, easy to demo, and hard to get users to use every day.

The way I've learned to tell the difference isn't the feature's description. It's what happens if the user doesn't have it.

Take an invoicing feature. If your users are freelancers who legally have to issue invoices for every payment, and skipping one means a tax audit, that's a painkiller. If your users are side-hustlers who could just send a Venmo message, it's a vitamin with the word 'invoice' in the title. Same feature. Two different products depending on the reality the user lives in.

That's the test. Not 'is this feature valuable?' Of course it's valuable. Everything you could build is valuable to someone. The test is: what does the user lose if this doesn't exist? If the answer is 'money, time, or legal exposure', build it. If the answer is 'a little convenience', put it in the vitamin pile and come back when the painkillers are shipped.

How I apply it at Stagent

Stagent is the booking and management platform I've been building for the music industry, and the painkiller test is the reason some features I'd assumed would matter got quietly deprioritised, while others I'd thought were boring turned out to be the backbone of the product.

The painkiller stack, for a music booking operation, looks roughly like this. Invoicing. Because every gig is money owed, and the promoter won't pay without a correctly formatted invoice, and the country the gig is in dictates the tax rules, and the artist has a bank account waiting. Skipping it isn't optional. Contract generation and e-signatures. Because a gig without a signed contract is a gig that can vanish on an agent's whim or leave an artist with no recourse when a promoter refuses to pay. Advancing documents. Because the artist arrives and the venue doesn't have the right equipment and the show starts thirty minutes late and now the promoter is mad and the artist is blamed. Itinerary management with nightshift logic. Because a tour operator who mis-groups a 2 AM set onto the wrong calendar day will misbill a client and lose a customer. Accounting exports. Because the artist's bookkeeper will file taxes wrong without them, and the artist will get a letter from a tax authority.

Notice what these have in common. None of them are exciting in a demo. All of them hurt if missing. The painkiller test is blunt about this. It doesn't care whether a feature is intellectually interesting. It cares whether a user who skips it pays a price.

The vitamin stack, for the same product, is everything I'd love to build and have had to repeatedly not build. A social-style activity feed of bookings happening across the platform. Nice, but nobody's life depends on it. Collaborative playlists for tour planning. Beautiful, but not a painkiller. A mobile app with push notifications. Helpful, but agencies were happy on desktop. A Spotify-style 'year in review' of a touring artist's stats. The team is genuinely excited about this one and it's still a vitamin, and the painkiller stack is the thing that comes first.

I'm not saying never build vitamins. Vitamins are how a product earns love and how a brand gets a voice. I'm saying build them after the painkillers are shipped and stable, not before. Every time I've flipped that ordering, the product has felt charming and been useless. Every time I've obeyed the ordering, users have complained that the product looks boring and kept paying for it anyway.

The test that kills good ideas for the right reason

The painful part of the painkiller test is that it kills a lot of ideas you genuinely like. I've had features on my whiteboard for months that I thought were brilliant, and the test kept telling me they were vitamins, and eventually I gave up and let them go. Most of them I haven't missed. A couple I came back to two years later with a new frame that made them painkillers. The rest were just things I wanted to build, which is a very different reason from things users needed to pay me to build.

The best way I've found to stay honest with the test is to ask it in the user's voice, not the product team's. Not 'is this feature valuable?' but 'if this didn't exist, would a real user hunt me down and ask for it?' Painkillers have hunters. Vitamins have nodders. A hunter will write you an angry email at 11 PM. A nodder will say 'that's cool' in a usability test and then never open the feature. If nobody in your user base is going to hunt you for it, it's a vitamin, no matter how elegant the idea is.

The one place the test is dangerous

The place the painkiller test gets dangerous is when you apply it as a rule instead of a lens. Every useful framework has an edge case where it's wrong, and the edge case for painkiller-first is the feature that looks like a vitamin but is secretly the reason users adopt the painkillers in the first place.

At Stagent, the closest thing I have to an example is the press-kit builder. It's not a painkiller by the strict test. An artist can book shows without a nice press kit. But having a decent press kit is the thing that gets an agency to try the product in the first place, because it's visible, it's shareable, and it makes the artist look good in a room of promoters. It's a vitamin that operates as a top-of-funnel hook, and the painkillers lock in the customer once they're in. If I'd applied the painkiller test too rigidly, I would have skipped the press kit and nobody would have found us. Some vitamins are the door into the painkiller stack.

So the real test isn't 'painkiller or vitamin?' It's 'what is this actually for, and where does it sit in the user's journey?' The painkiller test is the default. The exceptions are the door-openers. If you can't describe a feature as either a painkiller or a door into the painkillers, you're probably building something for yourself.

The test is the roadmap

The reason I come back to this framework over and over is that it's the cleanest way I know to turn an endless list of feature ideas into an ordered list of things to build next. A roadmap with ten vitamins and no painkillers is not a roadmap. It's a wish list. A roadmap with ten painkillers and no vitamins is a grind, but it's a business. Most products that last long enough to matter start with the second list and add the first once they've earned the right.

Every week I make a list of what I'm tempted to build next, and I run the test on each item. Half of them get dropped immediately. A quarter get deferred until the painkillers are stable. The rest are the roadmap. The list is shorter than I want it to be, and the product is healthier than it would be if I'd listened to my instincts instead.

The painkiller test is not a clever insight. It's the discipline of asking a simple question honestly about every idea you're in love with. The hard part isn't knowing the question. The hard part is being willing to hear the answer when it's a vitamin and you wanted it to be a painkiller. I've gotten better at that over time. I'm still not as good at it as I should be. Nobody is.

Build the painkillers. Be honest about the vitamins. When in doubt, ask the user what keeps them up at night. The things that hurt are the things worth fixing. Everything else is decoration.