You’ve probably sat through a demo that felt less like professional learning and more like a timeshare pitch. The salesperson clicks through slides, promises overnight results, and name-drops districts that supposedly signed on. You walk out with a glossy handout and a nagging feeling that something was off.
Evaluating edtech isn’t about resisting change. It’s about making sure the tools you bring into a school actually help your students, match your teaching goals, and don’t waste your staff’s time. I’m Sandra Okonkwo, and after years on both sides of the procurement table—first as a classroom teacher, later as an instructional technology specialist—I’ve learned that the best tech decisions happen when we stop being passive buyers and start being active evaluators.
This piece lays out a practical, repeatable way to size up edtech products without getting swallowed by the sales pitch. You’ll learn how to nail down your own criteria before the demo starts, how to ask questions that expose the cracks, and how to run a pilot that gives you real evidence—not just a good feeling.
Start With Your Instructional Problem, Not Their Solution
Most edtech demos open with the tool. The presenter jumps into a feature tour: dashboards, gamification, reporting modules. By the time they’re done, you’re mentally rearranging your week to fit their product, instead of asking whether it fixes a problem you actually have.
Flip that dynamic. Before you even book a demo, write down the specific instructional struggle you’re trying to address. Plain language works best. Skip “we need a personalized learning platform” and try “our sixth-grade math teachers can’t give timely feedback on open-ended problems, and kids keep repeating the same mistakes across units.” That small shift forces you to define success by student learning, not by a feature checklist.
Once you’ve got your problem statement, share it with your evaluation crew—classroom teachers, instructional coaches, special ed staff, anyone who will actually use the tool. Ask each person to list three must-have criteria the product needs to meet. Smash those together into a one-page rubric. Use it during every demo and pilot. If a vendor can’t speak directly to your criteria, you’ve learned something important before spending a cent.
Run a Demo That Works for You, Not the Sales Rep
Sales demos are built to show a product in its best light—preloaded data, a smooth script. Your job is to step off that script. When you set up the demo, send the vendor your one-page rubric ahead of time and ask them to shape their time around your criteria, not their standard deck.
During the demo, steer the pace. If the rep spends ten minutes on a slick dashboard your rubric never mentions, politely redirect: “Could we see how a teacher gives feedback on a student’s written response? That’s a core need for us.” Watch how they handle it. A vendor who listens and adapts is someone you can work with later. A vendor who deflects or rushes past your questions is showing you how they’ll handle support calls down the road.
Bring at least two teachers to every demo and give them clear roles. One focuses on instructional fit: Does the content match our standards? Does the feedback approach line up with how we teach? The other watches for usability: How many clicks to assign something? Can a kid navigate this solo, or will it create a new management headache? Afterward, have both teachers fill out the rubric on their own before talking. That keeps one loud voice from tilting the whole group.
Ask the Questions Sales Reps Hope You’ll Skip
Vendors prep for the usual questions about price and integration. The ones that reveal the most are the ones they don’t see coming. Here are a few I always ask, and why they matter.
“Can you show me the raw student data export, not the dashboard view?” Fancy dashboards are built for administrators. Teachers need raw data they can slice up in their own spreadsheets or gradebooks. If the export is just PDF summaries or canned reports, the tool probably won’t give your data teams the flexibility they need.
“What happens to our data if we cancel the contract?” This one often gets a pause. Some vendors keep ownership of student work, or they wipe everything after a set window. If your students have built portfolios or completed big projects inside the platform, losing that history can mess up longitudinal tracking and parent conversations. Get the data retention and export policy in writing before you sign anything.
“Can you show me how this works on a five-year-old device with a spotty internet connection?” Most demos run on brand-new hardware with a hardwired line. Your classroom reality is probably messier. Ask the rep to log in on an older Chromebook or tablet, then simulate a slow network. If the tool crumbles under everyday conditions, it’s a dealbreaker—no matter how pretty the demo looked.
“What training and support are included in this price, and what costs extra?” Some vendors roll initial PD into the first-year price, then charge for any follow-up coaching. Others offer “free” webinars that are really just sales pitches for premium add-ons. Map out the total cost for three years, training included, so the renewal invoice doesn’t blindside you.
Design a Pilot That Produces Evidence, Not Anecdotes
A lot of school pilots follow the same tired arc: a few eager teachers try the tool, tell colleagues it’s “pretty good,” and the school buys a license based on buzz. Then the rest of the staff struggles to adopt it, and the tool gathers dust by winter break. A well-structured pilot stops that cycle.
Start by choosing pilot teachers who show a range of attitudes—not just your early adopters. Include at least one skeptic who’s willing to give honest feedback. Set a clear pilot length, usually six to eight weeks, and define success measures that tie back to your original problem statement. If your problem was feedback speed, your success measure might be “teacher feedback turnaround drops from five days to two days for 80% of assignments.”
Build a simple data collection plan. At minimum, gather three kinds of evidence during the pilot:
- Usage logs: How often are teachers and students actually logging in? Low use after the first two weeks often points to usability or relevance issues.
- Student work samples: Compare work done inside the tool to similar work done outside it. Are kids producing deeper thinking, or just filling in blanks faster?
- Teacher reflections: Have pilot teachers keep a weekly log of what worked, what drove them nuts, and how much extra time the tool demanded. Those stories catch problems that data logs miss.
At the end, hold a structured debrief where every pilot teacher presents their data and their recommendation. Use a consistent decision matrix: does the evidence support adoption, a longer trial, or a pass? Write down the decision and the reasoning so you have a record when the vendor circles back.
Look Beyond the Product to the Company
A tool is only as solid as the team behind it. Before you commit, spend thirty minutes digging into the company. Check their privacy policy for language about data sharing and third-party ads. Scan their social media and support forums: do teachers report getting quick help, or do you see long threads of unanswered complaints?
If the product is fairly new, ask about the company’s funding and roadmap. A startup that just landed a big funding round may be under pressure to grow fast, which can lead to feature bloat or sudden price hikes. A company that’s been stable for a few years with a focused product line is more likely to keep its promises.
Also ask for references from schools that match yours in size, demographics, and instructional model. Call those references and ask the uncomfortable questions: “What do you wish you’d known before you bought?” and “How did the renewal conversation actually go?” Vendor-provided references will be positive, but the details between the lines often tell you the most.
Build an Evaluation Routine Your Team Can Reuse
The goal isn’t just to survive one good purchase. It’s to build a habit that sharpens every decision. Create a shared folder with your problem statement template, demo rubric, and pilot data collection forms. After each evaluation cycle, spend twenty minutes tweaking the templates based on what you learned. Over time, your team will internalize the process and get better at ignoring flashy demos.
When a vendor sends a cold email or corners you at a conference booth, you’ll have a ready answer: “We’d be happy to consider your product. Here’s our evaluation rubric. Can you schedule a demo that speaks to these criteria directly?” That one sentence filters out vendors who aren’t serious about instructional fit and saves your team hours of wasted time.
Protect Your Time and Focus
Edtech evaluation fatigue hits hard. Every week brings a new tool promising to close gaps, boost engagement, or save teachers time. If you try to evaluate everything, you’ll do none of it well. Set a cap on how many tools your school or department will formally pilot in a year. For most K-12 settings, two to three per year is manageable. That limit forces you to prioritize problems that actually need a tech fix, instead of chasing every shiny product that lands in your inbox.
Remember, sometimes the best evaluation outcome is deciding not to buy. A tool that doesn’t fit your instructional values, or solves a problem you don’t have, will cost you more in training time and teacher frustration than it ever saves. Walking away from a charismatic sales pitch is a skill, and it gets easier the more you practice it.
Frequently Asked Questions
How many people should be on an edtech evaluation team?
A team of four to six usually works well. Include at least two classroom teachers from different grade levels or content areas, one special education or intervention specialist, and one administrator who can speak to budget and data privacy rules. Smaller teams move faster; bigger ones risk getting bogged down in consensus-building.
What if a vendor won’t give me a straight answer about data ownership?
That’s a red flag. Solid education technology companies should have clear, written data privacy policies that spell out who owns student data, how it can be used, and what happens when the contract ends. If the sales rep dodges or says they’ll “get back to you,” hit pause until you have a documented answer. You can also check if the vendor has signed the Student Privacy Pledge, which sets a baseline of commitments around data handling.
How do I handle a principal or district leader who wants to buy a tool I don’t think is ready?
Ask to run a short, structured pilot with defined success measures before a full purchase. Frame it around responsible stewardship of funds and teacher buy-in. When you present pilot data that shows specific gaps—like low usage or weak alignment with standards—decision-makers often rethink. If the purchase goes forward anyway, document your concerns and request a formal review point, like a check-in after one semester, to see whether the tool is actually delivering.
Is it ever okay to sign up for a free trial without a full evaluation process?
Free trials can be handy for quick exploration, but set boundaries. Limit them to one or two teachers, not a whole grade level. Make it clear that using the free version doesn’t lock the school into a purchase. And always check what data the vendor collects during the trial—some free trials still gather student information, which may need parental consent under your district’s privacy policies.