We built the feature nobody asked for. It's now our most used feature.
Few Month ago building bearconnect.io. We had our roadmap locked in: automation sequences, connection requests, message templates. Standard LinkedIn tool stuff.
Then a beta user named Sarah sent a screenshot. She was managing LinkedIn for herself plus four clients.
She had 47 Chrome tabs open. Her exact words: "I don't need more automation. I need to stop losing my sanity switching between accounts."
We almost ignored it. Multi-account management wasn't on our roadmap. We were building an outreach tool, not an inbox manager.
But three more users said the same thing that week. Agencies were our unexpected early adopters, not solo founders like we planned.
We spent two weeks building a unified inbox. One dashboard, unlimited LinkedIn accounts, all conversations in one view. It felt like a detour from our "real" product.
Launch day for that feature: 34% of users connected a second account within 48 hours. Our activation rate jumped. Support tickets about "missing messages" dropped to zero.
Turns out we weren't building an automation tool. We were building an infrastructure tool for people drowning in multiple LinkedIn accounts.
The lesson hit hard: your first customers will tell you what you're actually building. Your roadmap is just a hypothesis until real people use it.
Now when someone requests a feature, I ask: "Are you the third person to ask this?" If yes, we build it. If no, we wait.
What feature did your users force you to build that you didn't plan for?
The hardest thing about B2B is that you're often selling to someone who didn't budget for your category. They need the result you provide but never planned to pay for it.
The products that win here usually create a new budget line (by being categorically new) or steal from existing budget by making the ROI comparison obvious. Which of those are you trying to do?
The "third person to ask" rule is one of the cleaner prioritization frameworks I've seen. It filters out the vocal minority (power users who request edge case features) while catching actual pattern signals.
The 47-tabs story is also a good reminder that the surface request ("I need to manage multiple accounts") often hides the real problem ("I'm losing track of conversations and making embarrassing mistakes with clients"). The feature that solves the real problem is usually different from the feature that addresses the stated request.
What's interesting here is the customer segment shift — from solo founders to agencies — was revealed not by a pivot decision but by paying attention to who actually showed up. Most founders try to find product-market fit by adjusting the product. Sometimes the right move is adjusting the ICP to match who's already using it.