The Feature Nobody Asked For That Changed Everything

Building something new means fighting the urge to wait for permission. You wait for customer data to emerge, for trends to develop, for dozens of people to request the same thing. But sometimes waiting means you miss the window entirely.

We learned this lesson building Boon's referral widget. No customer had asked for it. The market wasn't sending signals that it needed to exist. However, Dakota Younger, our CEO, noticed a pattern that many product teams face: users claiming they want something but not actually using it when it is built.

The pattern was simple in our case: referral programs failed due to access issues, not because employees didn't want to help their teams hire great people. When referrals lived inside tools people actually used every day, they'd send more of them. We had no data to back this up. It was based on pure instinct, derived from observing user behavior patterns.

When Data Isn't Enough

Most product teams live and die by data. User feedback shapes the roadmap. Usage numbers point toward what's working. When you're moving fast and resources are tight, building what you can prove feels a lot safer than testing what you think might work.

But that approach has blind spots. You end up sticking with features that don't have track records of failure yet. You build what users say they want instead of solving problems they don't even realize they have.

Our customers kept telling us the same thing: companies would get excited about referral programs, employees would nod along during the kickoff meeting, and then... nothing would happen. People would often forget to check the platform, overlook sharing jobs, and even forget that the program existed at all.

The users weren't lazy or uninterested; they simply needed to be informed. They were just busy doing their actual jobs. Every extra step between thinking "I know someone perfect for this" and actually sending their information was another chance for people to get distracted and move on to more pressing work.

The solution seemed obvious once we saw it: put the functionality where people already were. Inside the tools they used daily. Let them take action without needing to switch contexts.

Making Big Bets With No Safety Net

Building the widget meant pulling engineers off other projects for months. It meant pushing back features that TA teams were actually asking for. It also required a lot of time and focus on something that might not help anyone at all.

Other launches got delayed. Customer-requested features took longer. Since nobody was demanding the widget, we couldn't point to hiring manager pressure or survey data to justify the decision. We were making a call based on gut instinct when everything in the product playbook says to wait for proof.

We'd watched the same pattern play out in hiring team after hiring team: people liked the idea of referrals but couldn't be bothered to use them when it meant stopping what they were doing and going somewhere else. The widget was our answer to that specific friction point.

The Breakthrough Moment

Most teams try to avoid internal conflict, but we learned to lean into it. We appreciate it when people challenge our ideas, because building products that actually solve problems requires testing assumptions from every angle.

Engineers worried about security. How do you safely embed something in a client's internal systems? Customer success worried about complexity. Would this create a support nightmare for already-busy customers? Sales wondered if we were building something users would want to adopt.

The security questions prompted us to develop more robust authentication that wouldn't hinder busy users. The support worries led to clearer setup documentation that customers could actually follow. The sales skepticism prompted us to investigate how people actually used existing tools.

None of this was smooth or polite. People disagreed, but we stayed focused on making the core action so easy that users would actually do it. The friction between different perspectives made something customers could really use, not just something that looked impressive in demos.

When Users Finally Had What They Needed

The widget was launched six months after the first debate, and customers began using it immediately. Companies embedded it everywhere: employee portals, scheduling systems, even Slack workspaces.

We saw an immediate impact. Referral activity increased, and reward engagement grew as employees could finally see their referrals being tracked without having to switch between different tools.

However, the real validation came when customers started asking for more. As Dakota noted: “Once we started doing all these things, that's where it started to validate, because then companies started being like, ‘We need to issue rewards.’”

Suddenly, customers were requesting features that built on what the widget made possible. They were not just using it, but were also thinking about how to make it even better. That's when we knew we'd actually solved something important.

Lessons Learned: Why Simple Wins for Users

The widget was a success because it didn't ask customers to train their teams on something new. It didn't require separate passwords or new workflows. It sat quietly in places people already went and made one specific action completely frictionless.

It also changed how companies viewed core functionality. Instead of treating it as a separate program that required separate attention, it became part of what employees were already doing. That shift from "extra work to manage" to "built-in opportunity" was what made adoption stick.

The best solutions often work by removing steps, not adding features. That's exactly what happened here.

How to Decide When Your Team Should Build Risky Features

Here's the framework we developed for evaluating decisions like this, especially when data is scarce but you're seeing patterns that could help users:

1. Look for Behavioral Patterns Users Can't Articulate We tracked where our core functionality broke down in practice. Most users expressed a liking for the concept, but few followed through consistently. The real issue was the gap between intention and action that traditional product solutions couldn't easily fix.
2. Count the Real Costs to Your Team and Theirs Building the widget meant two full engineering sprints plus delayed launches for other features. If this failed, what else could we have built to help users instead? We mapped out exactly what we were giving up and decided the potential benefit was worth it.
3. Set Clear Success Metrics That Matter to Users We defined success as 25% adoption among existing customers within 60 days and a 30% increase in the core action for participating companies. Having specific numbers meant we could quickly determine if we were actually helping people or just creating more complexity.
4. Plan Your Exit Strategy to Minimize Impact on Customers Before we built anything, we agreed that if adoption stayed below 15% after 90 days, we'd shut it down and focus those engineering resources on something that would actually help users. Having a clear exit plan made the risk feel manageable.

This framework helps us distinguish between smart bets and wishful thinking.

When Instinct Serves Users Better Than Spreadsheets

Understanding when patterns matter more than polls becomes crucial when you're trying to help users actually accomplish what they say they want to do.

We didn't abandon structure or stop measuring things. We just made room for informed hunches about what users actually needed. We watched what people did, not just what they said they wanted. We trusted behavior over surveys. And we were comfortable being early, even if it meant being wrong.

This time we weren't wrong. But even if we had been, we knew exactly what it would cost us and our customers. That clarity made the risk worth taking.

Most product teams ask, "What does our data tell us?" When you're building for users who can't always articulate their real problems, you also need to ask, "What are people showing us that they can't put into words?" That small change in perspective opened up space for a decision that significantly enhanced our core functionality.

What This Means for Your Next Big Bet

Your breakthrough solutions probably won't come from user surveys or feature request lists. They'll come from noticing what's broken in user workflows that nobody's complaining about yet.

The referral widget started with us watching the gap between what users said they wanted and what they actually did. It's now helping people take actions they never would have taken otherwise. The validation came after we built it, not before.

Sometimes the most valuable features solve problems users don't know how to articulate. The key insight comes from watching people work rather than just asking them questions.

If you're sitting on a decision like this, think about what waiting really costs the users you're trying to help. Consider reframing the question from "What do we know for sure?" to "What are we seeing that could make people's lives easier?"

Want to see how the widget works in practice? Schedule a demo to see how Boon's widget integration fits into real workflows.

‍