Why Features Don't Matter—Outcomes Do

Your users are lying to you.

Not on purpose. They just don't know how to tell you what they actually need. And if you build exactly what they ask for, you'll end up with frustrated users and a product that doesn't get adopted.

Here's why.

The Feature Request Trap

What typically happens: A user reaches out through sales, support, or direct contact. They tell you exactly what they want—a specific feature, often one they've seen in another product. Everyone assumes they know what the user needs because the user literally just told them. The request gets documented, prioritized, and built.

Here's what user researchers know that most product teams don't: humans are terrible at communicating what we actually need.

We articulate the easiest thing to describe, not the most important thing to fix. We request features based on what we've seen before, assuming those features were designed to solve our exact problem. (They probably weren't.) We suggest the first solution that comes to mind instead of taking time to analyze alternatives. And we often don't know what our core need is—we just know the symptom we're feeling.

Here's the thing: the way we're asked for feedback shapes the answers we give. Ask someone what features they want, and they'll give you a feature list. Ask them about their goals, triggers, and pain points, and you'll discover what they actually need.

One Feature Request, Seven Different Needs

Let me show you what this looks like in practice.

I worked on a math diagnostic and learning platform. Students took a validated assessment, and based on the results, an algorithm created a personalized learning path—showing which skills to work on, in what order, to reach grade-level proficiency.

When the application was rebuilt from scratch, the team intentionally stripped it down to core functionality to avoid recreating feature bloat. Then we started gathering feedback to determine what to build next.

The feedback came flooding in from every channel. Sales reps. Customer support. Users contacting us directly. Everyone was asking for the same thing: the ability to create assignments instead of having students work on the algorithm-suggested skills. This feature had existed in the old platform, and people wanted it back. Immediately.

The pressure on the product team was intense. Here was a clear, consistent feature request from multiple sources. The obvious answer was to rebuild that functionality as fast as possible.

We did something different. We dug deeper.

We talked to users about their actual workflows, their triggers, their goals. We asked about specific situations where they felt stuck.

What we discovered was that one feature request was masking seven completely different core needs.

• Educators didn't trust that the algorithm was suggesting the most appropriate skills.

• They wanted to use the program for exit slips for the day's lesson.

• They wanted to keep all students working on the same lesson on the same day.

• They wanted to have a few small groups of students with each group working on a needed skill they had in common.

• They wanted students to fill in holes in supporting skills for the day's lesson.

• They wanted students to fill in holes in supporting skills for the current unit.

• They wanted students working on skills related to a specific standard.

Only one of these needs would have been effectively and efficiently met by rebuilding the old feature.

We would have spent time and money building something that still frustrated 6 out of 7 groups of users with how much it relied on the teacher to manually determine which skills to assign to whom and to make those assignments.

Instead, once we understood the underlying needs, we could prioritize based on prevalence, look for solutions flexible enough to address multiple needs, consider business objectives, and evaluate technical feasibility.

The result? Much happier users. Lower development costs. And a better product.

The Flip Side: Different Requests, Same Need

This problem works in both directions.

Sometimes multiple people ask for the same feature but have completely different underlying needs (like the math platform example). But just as often, multiple people have the same core need yet give completely different feature requests—because they all have different past experiences with other products, or their first-thought solution differs based on their background.

This is why asking users for solutions is fundamentally flawed. It's much more productive to ask about their triggers, tasks, and goals. To dig into their pain points. To understand their actual workflow, not the workflow they think they should describe.

From Features to Outcomes: What Changes

When you shift from feature-oriented to outcome-oriented thinking, everything changes about how you work.

Research changes. Instead of asking "What features do you want?" you ask "What are you trying to accomplish?" and "Tell me about the last time you encountered this problem." You ground conversations in specific past experiences rather than hypothetical futures.

Design changes. Instead of designing features in isolation, you design task flows that support complete workflows. You think about where users are in their journey when they need something, not just whether it exists somewhere in your product.

Prioritization changes. Instead of counting feature requests, you analyze which outcomes matter most to your users and your business. You look for solutions that address multiple needs rather than building separate features for each request.

Success metrics change. Instead of measuring feature usage, you measure whether users can actually accomplish their goals. Whether they're successful. Whether they're satisfied.

Communication changes. Instead of announcing new features, you explain how users can now achieve outcomes they couldn't before. Instead of listing capabilities, you tell stories about transformed workflows.

What This Means for EdTech

This matters even more in education technology because the stakes are so high.

Teachers don't have time to waste on products that don't actually work in classrooms. They don't need more features—they need solutions that genuinely reduce their burden while helping students learn.

When EdTech companies focus on features, they build products that look impressive in demos but fall apart in real classroom use. They create tools that require extensive training because the features aren't organized around actual teacher workflows. They add capabilities that technically meet requirements but don't address the underlying challenges teachers face.

When EdTech companies focus on outcomes, they build products that teachers actually want to use. They create tools that fit naturally into existing workflows because they were designed around real tasks. They solve problems teachers didn't even know they could articulate.

The Shift You Need to Make

If you're building products, here's what needs to change.

Stop asking users what features they want. Start asking what they're trying to accomplish and where they get stuck.

Stop designing features in isolation. Start designing task flows that support complete user journeys.

Stop counting feature requests. Start analyzing the outcomes users actually need to achieve.

Stop measuring feature adoption. Start measuring whether users can successfully complete their real-world tasks.

This isn't about being user-centered in theory. It's about being genuinely committed to understanding what users actually need—even when (especially when) they don't articulate it clearly.

Because here's the truth: your users don't want features. They want to get home on time. They want their students to actually learn. They want to feel effective at their jobs. They want to make a difference.

Features don't matter. Outcomes do.

Want to learn more about uncovering real user needs? Download my Strategic User Interview Guide—it walks you through exactly how to dig beneath surface feature requests to discover what users actually need.