What Twitter's Co-Founder Got Right About Picking Problems Worth Solving
I read a post about how Twitter's co-founder approached choosing what to build. It stuck with me because it maps directly to how we've been thinking about agent design at SoftStackers - not starting with the tool, but starting with the specific problem that breaks when humans try to solve it manually.
The core insight from Medium is straightforward: don't pick a business idea because it sounds cool or because AI is hot right now. Pick it because you've watched someone struggle with a specific, repeatable problem and you know exactly how to fix it.
We've applied this directly to our agent work. Early on, we built features we thought customers needed. We shipped a general-purpose workflow automation tool that looked impressive in demos but sat unused. The problem: we were solving for an imaginary user, not a real one.
Then we started embedding with actual teams. We watched a customer's ops person spend 90 minutes every morning pulling data from five different systems, reformatting it, and sending it to Slack. That was the moment we understood what to build. Not a generic automation platform. A specific agent that solved that specific bottleneck.
The lesson applies to how we think about agent design now. An agent that tries to do everything does nothing well. An agent built for a precise workflow - with clear inputs, defined success criteria, and measurable time savings - actually gets used and compounds.
This also changed how we talk to founders building on top of our platform. We push back on vague use cases. We ask: what's the 90-minute problem? What's the thing your customer does manually that breaks their day? Start there. Build that. Measure it. Then expand.
It's unsexy compared to "we're building an AI-powered everything platform," but it's the difference between shipping something people actually use and shipping something that looks good in a pitch deck.