They Asked for 3 Features. They Actually Needed 17.
I had a conversation last year that I keep coming back to. A benefits services company came to us with a clear request: they wanted 3 things. An enrollment communication tool. A document search function. And a reporting dashboard.
Three features. Clean scope. They'd already written the RFP. They knew what they wanted.
Except they didn't. Not because they were wrong about the 3 features — those were legitimate needs. But because the 3 features they asked for were symptoms of 17 problems they hadn't named yet. And 10 of those problems would have eaten the project alive if we'd just started building what was on the page.
The Cost of Skipping Questions
Here's how this usually goes in our industry. A company identifies pain. They describe the pain as a feature request. A vendor says "sure, we can build that." Six months later, the feature exists but the pain hasn't changed, because the feature was treating the symptom and nobody stopped to diagnose the cause.
In worksite benefits, it looks like this (and if you're in the benefits space, why enrollment is still stuck in 2015 explains the structural reasons): "We need better enrollment emails" usually means the underlying data is fragmented across 4 systems, nobody has a single source of truth for plan details, and the reason the emails are bad is that the information feeding them is bad. Building a better email tool on top of broken data just produces better-formatted wrong information faster.
What Discovery Actually Does
When we run a governed discovery process — and I mean governed, not "let's have a brainstorming session" — we're doing something specific. We're decomposing the stated request into its component assumptions and then testing each one.
"We need an enrollment communication tool" decomposes into:
- Where does plan data live? Is it authoritative?
- Who approves communication content before it sends?
- What compliance requirements apply to each communication type?
- How do you know which employees are in which enrollment window?
- What happens when a carrier changes plan details mid-cycle?
- How do you currently handle communications for employees who missed their window?
That's 6 questions from 1 feature request. And every answer reveals either a solved problem or an unsolved problem that has to be addressed before the feature makes any sense.
In this case, 3 feature requests produced 17 actual requirements once we finished asking questions. And 10 of those 17 were problems the company didn't know they had.
The 10 Problems They Didn't See
Data authority gaps. They had plan details in 3 places and none of them agreed. The enrollment tool would have been sending communications based on whichever data source the developer happened to connect first.
Approval chain gaps. Nobody had documented who approves what. Building an email tool without a defined approval workflow means building a tool that either sends unapproved content or creates a bottleneck nobody planned for.
Carrier-specific compliance rules. Different carriers have different disclosure requirements. Different plan types have different regulatory obligations. None of it was codified. An automated system that doesn't know about carrier-specific rules will generate non-compliant communications.
Employee classification drift. The employee data in their HRIS didn't match the data in their benefits admin system. Building a communication tool that pulls from the HRIS would send the wrong plan information to employees whose records had drifted.
Why This Matters for Your Operation
If you run a worksite benefits services company, or you're a broker managing enrollment for multiple employer groups, some version of these problems exists in your operation right now. Underneath the surface-level pain, there are structural issues that no tool will fix unless someone asks the right questions first.
Skipping questions costs more than asking them. Always. A feature built on wrong assumptions has to be rebuilt. A communication tool that sends non-compliant content has to be recalled. An integration built against the wrong data source has to be reconnected.
In this engagement, the 2-week discovery process caught 10 problems that would have each required 1-3 weeks to fix after the fact. That's 10-30 weeks of rework avoided by spending 2 weeks asking questions.
The Governance Angle
We don't run discovery as a freeform exercise. It runs through the same governance pipeline as everything else we build. Every question gets documented. Every finding becomes an artifact. Every decision gets recorded with the rationale behind it.
For worksite benefits operations, where compliance is real and audits happen, having that kind of trail isn't a nice-to-have. It's the difference between "we made thoughtful decisions" and "we think someone decided this at some point."
The Offer
If you're looking at your enrollment operations and thinking about automation — or if a vendor has already told you they can build what you need — I'd ask you one question first.
How many questions did they ask before they quoted you a price?
If the answer is fewer than 20, they're building on assumptions. And in worksite benefits, assumptions have compliance consequences.
That's the conversation worth having before any code gets written. It's the same principle behind the governance layer we built — ask the hard questions first, build second.
If you're evaluating vendors and nobody's asked you more than five questions, schedule a conversation. We'll start with the twenty questions they didn't ask.
