The Text Box That Mattered

We all keep a list of features we'll build someday.

I have one too. Moodboards. Payment integrations. In-app photo sales.

They've been sitting on my backlog for months. Untouched.

Last week, I built a text box instead. A blank rectangle. You paste a list of filenames, hit enter, and Picstome marks those photos as favorites. Bulk favoriting — the least glamorous feature on my list.

One customer asked for it. They'd curated dozens of photos in another app and were staring down the soul-crushing task of re-selecting every single one by hand. I shipped it the same day.

That tiny feature felt more important than everything else on my roadmap combined. I don't think I was wrong.

Most product builders prioritize backwards. We rank features by how they'd sound on a landing page. But the features that matter start with a specific person, a specific frustration, and that urge to fix it right now.

There's a phase where big features make sense. Early on, Picstome needed galleries, photo proofing, the core stuff. You build big things because the product needs them to exist.

But then the product feels complete. The foundation is set. And the momentum doesn't stop — like a train that's already left the station. You're still laying track, except now you're headed somewhere nobody asked to go.

My business partner and I put a payment links generator on the roadmap. Simplified payments for photographers. Sounded like a no-brainer. We built it, shipped it, and waited.

One person uses it.

One. Because it solves a problem we imagined, not one anyone was actually feeling.

So how do you find the real problems?

For me, it's never come from a feature request board or a survey. It comes from a Telegram message at midnight, a support ticket that reads like a confession, a DM I can feel through the screen.

A feature request lands politely. A real pain point makes your jaw tighten.

When that customer messaged about bulk importing favorites, I didn't think "let me score this against other roadmap items." I thought "that's awful, I'd be pulling my hair out too." Then I built it. Same day.

If someone describes a frustration and I don't feel an immediate urge to fix it, it's probably not worth prioritizing. But when I can feel the hours bleeding out, the click-click-click of someone doing something that should take seconds — that's the signal.

Your customers are already telling you. You just have to stop long enough to hear it.

Following pain doesn't leave you directionless. It gives you a roadmap that builds itself.

Solve a real pain, and customers trust you more. They tell you the next thing that frustrates them. Small things they'd never put on a feature request form because they seem too minor. But they're not minor. They're the product.

Those features ship faster. When you feel someone's pain, you don't over-engineer. You just fix the problem and ship.

When you ship something that relieves a real pain, the customer doesn't just feel satisfied. They feel seen. That's a deeper loyalty than any flashy feature can buy.

If your product still needs its foundation, build the big things. But the moment you catch yourself adding features to impress, pause.

Ask: when was the last time a customer described a frustration that made me wince?

That's your next feature.

The roadmap whispers about what would look impressive. Pain tells you what would actually matter.