What I Learned After Losing Contracts

I was losing deals because I was spending the whole time during presentations talking about features.

• Adaptive remediation. 

• Real-time data-driven decisions. 

• Integration capabilities.

• And the list goes on….

District administrators would stop me mid-presentation and say things like: 

"I have 200 third graders who can't read at grade level. How does this help them?"

Honestly, my answer was clunky and awkward. Truthfully, I didn't have a good answer.

Not because our product couldn't help. But because I wasted time explaining what we built instead of what we solved.

The Competitor Who Kept Winning

A few months later, I noticed my closest competitor winning contracts. Winning contracts, I thought, we deserved.

Their product wasn't as sophisticated as ours. Their feature list was shorter. Their technology was less advanced.

They were winning because their messaging was better.

They talked about helping struggling readers catch up and close the achievement gap. We talked about our platform capabilities.

The feedback I received from the district administrators I had been working with all said essentially the same thing: "They understood our problem. You showed us features."

And they were right.

That's when I realized: I was losing deals not because of my product, but because of how I was talking about it. I was losing on value.

Why We Default to Features

Here's what I've learned about why founders—including me—naturally gravitate toward feature-talk:

We build products. We live in the details of what they do, how they work, and what makes them special.

When someone asks, "What does your product do?" our instinct is to list capabilities: adaptive learning, real-time analytics, seamless integrations, and standards alignment.

It feels concrete. Defensible. Like we're demonstrating expertise and credibility.

But here's the problem: districts aren't buying capabilities. They're buying solutions to problems that nag at them day after day.

• When I talk about adaptive algorithms, curriculum directors think of third graders who are two years behind and need to catch up before fourth grade.

• When I talk about real-time dashboards, principals are thinking about teachers who don't have time to analyze data on top of everything else they're managing.

• When I talk about integration capabilities, technology directors are thinking about whether this will create more work or less work for their already overwhelmed staff.

We're having different conversations. And when that happens, we lose.

What Changed for Me

After losing deals and watching the competitor win, I had to figure out how to actually start selling. 

Value selling. Solution selling. Consultative selling. Mastering all three methodologies.

Took me a while. But I landed on something simple:

We help [who] achieve [what] by [solving what problem].

That's it. Three blanks. Fill them in, and you have your conversation starter.

For example: "We help struggling readers who are two or more years behind catch up through daily practice that guarantees measurable growth."

One sentence. No jargon. Clear who, what, and why.

Before I figured this out, I'd say things like: "We're an adaptive literacy intervention platform with individualized, real-time data-driven placement, with seamless LMS integration."

True. But completely useless.

Curriculum directors would nod politely and then ask, "So what does that actually mean for my third graders?"

Now, when I use the formula, they get it immediately. And more importantly, they can repeat it to their superintendent without me in the room.

That's the real test: if they can't repeat your value in their own words, you haven't made it simple enough.

The Three Problems Districts Are Actually Solving

When I stopped talking about features and started listening to what districts were actually saying, I heard three problems over and over:

1. Students who are significantly behind and running out of time. Third graders reading at a first-grade level. Fifth graders who can't do fourth-grade math. The gap is widening every year, and the pressure to close it is intensifying.

2. Teachers who are overwhelmed and under-resourced. Thirty students in a class with reading levels spanning six grades. No time to create individualized plans. Constant pressure to differentiate without any additional support.

3. Districts facing accountability for achievement gaps. Board members demanding results. State assessments looming. Funding tied to outcomes. The need for solutions that actually work, not just look good in a proposal.

Those are the problems. Everything else—the adaptive algorithms, the real-time dashboards, the integration capabilities—those are just proof that we can solve them.

How This Changed My Narrative

Now I start every meeting the same way. I lead with the problem and the outcome:

"We help struggling readers who are two or more years behind catch up through daily practice that guarantees measurable growth."

Then I shut up and listen.

Most of the time, they respond with their version of the problem. Which means they get it. Which means I can have an honest conversation about their specific situation instead of delivering a generic, rote, memorized answer.

The features come later. After they understand that I understand what they're dealing with.

• I'll explain how the adaptive capability ensures students are always working at the right level—after they've told me about their students who are frustrated because the work is either too hard or too easy.

• I'll show them the real-time dashboards—after they explain that their teachers need to know which students need help today, not next week when the quiz is graded.

• I'll talk about integration features—after they've mentioned that their teachers are drowning in different platforms and need something that actually fits into their workflow.

The features matter. But they matter in context. They matter as answers to specific problems, not as proof of how smart we are.

What I Still Get Wrong

Even now, I catch myself slipping back into feature-talk:

• Get in front of a technical buyer and suddenly I'm talking techie instead of outcomes.

• Get asked a detailed question, and I dive into how it works instead of what changes.

• Get compared to a competitor, and I want to list everything we have that they don't.

It's not that I don't know better. It's that talking about features feels safer. More concrete. Easier to defend.

But safer doesn't close deals.

The Real Lesson

We build products. So we naturally want to talk about what they do—the features, the capabilities, the technology.

But districts don't buy what products do. They buy what problems get solved:

• Struggling readers catching up. 

• Teachers getting time back. 

• Achievement gaps closing.

That's what they're paying for. The features are just proof we can deliver the results.

The curriculum directors who stopped presentations and asked about their third graders aren't being difficult. They’re doing their job—trying to figure out if we could actually help their students.

I was making that harder than it needed to be.

Now I try to make it easier. Lead with the problem. Explain the outcome. Let the features prove I can deliver.

This process is a non-negotiable proven practice. It works far better than listing capabilities and hoping someone connects the dots.

What This Means for You

If you're an EdTech founder, try this:

Fill in the blanks: We help [who] achieve [what] by [solving what problem].

Say it out loud. Is it something a curriculum director could repeat to their superintendent without needing your sales or marketing material?

If not, keep simplifying.

Then test it. Lead your next presentation with that sentence instead of your feature list.

See what happens. See if the conversation changes. See if they lean in instead of nodding politely.

Because here's what I've learned: districts don't buy features. They buy relief.

• Relief from students falling further behind. 

• Relief from teachers who are overwhelmed. 

• Relief from board members demanding results they don't know how to deliver.

The features prove you can deliver that relief. But they're not why anyone says yes.

Lead with the problem. Let the features do their job—proving you can solve it.

What's the hardest part of this for you—knowing what to say or how to say it? I'm curious what's worked for others in making this shift.