Formative Assessment is Just A/B Testing (You've Been Doing It for Years)

I once sat in a product meeting at Microsoft where a senior PM was explaining the importance of "continuous discovery" and "testing assumptions before building."

I almost laughed.

I'd spent years testing assumptions before building. Every single day, actually. In a classroom. With teenagers who would tell me exactly what they thought of my lesson, whether I asked or not.

The PM was describing formative assessment. She just didn't know the word for it.

The Vocabulary Is Different. The Skill Is Identical.

In education, we call it formative assessment. You don't wait until the final exam to find out if students learnt anything. You check constantly. Quick questions. Exit tickets. Observations. Thumbs up, thumbs down. You're gathering data in real time so you can adjust before it's too late.

In product and business, they call it A/B testing, continuous discovery, or validated learning. You don't wait until launch to find out if customers want what you're building. You test constantly. Small experiments. Customer interviews. Usage data. You're gathering evidence in real time so you can adjust before you've wasted months building something nobody wants.

Same thing. Different words.

What You Actually Do (Translated)

Let me walk through a typical teaching day and show you what it looks like in business language.

You start with a hypothesis

Before you teach anything, you make an assumption: "If I explain this concept using this approach, students will understand it well enough to apply it independently."

That's a hypothesis. In product terms, it might be: "If we add this feature, users will complete the task 30% faster."

Teachers form and test hypotheses constantly. We just call them lesson plans.

You run an experiment

You teach the lesson. You try the approach. You put your hypothesis into action.

In business, this is shipping a feature, running a marketing campaign, or launching a prototype. You're taking your assumption and exposing it to reality.

You gather data in real time

Here's where teachers have an advantage most product people would kill for: immediate feedback.

You read the room. You watch faces. You notice when eyes glaze over. You catch the kid in the back row who's checked out. You hear the quality of answers to your questions. You feel the energy shift when something lands or when something bombs.

This is real-time user research. Except your users are sitting right in front of you, thirty at a time, and they have no filter.

A Year 8 will look you dead in the eye and tell you this is boring. A Year 10 will simply put their head on the desk and go to sleep. You learn very quickly what works and what doesn't.

Product managers pay consultants thousands of dollars to get this kind of unfiltered feedback. You get it for free, every period, whether you want it or not.

You iterate based on what you learn

When half the class looks confused, you stop. You try a different explanation. You find a new analogy. You break it down further. You adjust on the fly.

This is exactly what product teams do after a failed experiment. They look at the data, figure out what went wrong, and try a different approach.

When a lesson bombs and you rework it for the next class, you're doing what startups call "pivoting." When you notice something working better than expected and lean into it, you're doing what they call "doubling down on signal."

You've been doing agile development in classrooms since before software existed.

The Specific Skills That Transfer

Let me be concrete about what you already know how to do.

Checking for understanding before moving on

In teaching: You don't assume students understood just because you explained it. You check. You ask questions. You look for evidence of learning before introducing new complexity.

In business: This is called "validating assumptions." You don't assume customers want a feature just because it seems like a good idea. You test. You interview. You look for evidence of demand before investing in building it.

Adjusting your approach based on the audience

In teaching: You differentiate. The same content gets delivered differently to different students. The struggling learner needs more scaffolding. The advanced student needs extension. You read where people are and meet them there.

In business: This is called "user segmentation" and "personalisation." Different customers need different approaches. Different messages land differently with different audiences. Good product people adjust their approach based on who they're talking to.

Running quick tests to de-risk big decisions

In teaching: Before committing to a whole unit on a new approach, you might try it for one lesson. See how it goes. If it works, expand it. If it doesn't, you've only lost a period.

In business: This is called "MVP thinking" or "running experiments." Before committing to building a whole feature, you build the smallest version possible. See if anyone uses it. If it works, expand it. If it doesn't, you've only lost a week.

Using qualitative and quantitative data together

In teaching: You look at test scores AND you watch student behaviour. The numbers tell you part of the story. The observation tells you the rest. A student might get the right answer but have a fragile understanding. A student might get it wrong but be on the verge of breakthrough.

In business: Good product teams do the same thing. They look at the metrics AND they talk to customers. The data tells you what's happening. The conversations tell you why.

Knowing when the data is telling you to change course

In teaching: Sometimes you planned an amazing lesson and it's just not working. The class isn't ready. The approach doesn't fit. The energy is wrong. Good teachers recognise this and adapt. They don't keep pushing through a failing lesson out of stubbornness.

In business: This is called "knowing when to pivot." Sometimes you built what you thought was amazing and customers don't want it. Good product people recognise this and change direction. They don't keep pushing a failing product out of sunk cost fallacy.

Why This Skill Is Rare

Here's what makes this valuable: most people in business are terrible at this.

They fall in love with their ideas. They build for months without testing. They assume they know what customers want because they asked once, six months ago. They ignore feedback that contradicts their vision. They ship and pray.

Then they're shocked when nobody buys.

Teachers can't do this. Your users are right there. You get feedback whether you want it or not. You can't ignore a room full of confused faces. You can't pretend a lesson worked when half the class failed the exit ticket.

This constant, unavoidable feedback loop trains a skill that most professionals never develop: the ability to notice when your assumptions are wrong and adjust quickly.

That skill is gold. And you've been practising it for years.

The Translation Guide

Here's a quick reference for translating your assessment skills into business language.

The vocabulary changes. The underlying skill is identical.

When you're in a job interview and they ask about your experience with "data-driven decision making" or "iterative development," you have years of examples. You just need to translate them.

What This Means for Building Something of Your Own

If you're thinking about building a product or starting a business, your assessment skills give you a massive advantage.

You won't build in a vacuum

Most first-time founders spend months building something without talking to customers. They emerge with a finished product and discover nobody wants it.

You won't do that. You know that you don't wait until the final exam to check for understanding. You'll test early. You'll test often. You'll adjust based on what you learn.

You'll notice signals others miss

When you show your prototype to potential customers, you'll read the room. You'll notice the hesitation. The confused look. The polite enthusiasm that masks actual indifference. The genuine excitement that means you've hit something real.

Other founders miss these signals. They hear "that's interesting" and think it means "I'll buy it." You know better. You've been reading audiences for years.

You'll iterate faster

When something isn't working, you won't keep pushing. You'll try a different approach. You'll break it down differently. You'll find the angle that lands.

This iterative instinct is exactly what successful products require. Ship, measure, learn, adjust. Repeat forever.

A Practical Exercise

This week, notice your formative assessment in action.

Every time you check for understanding in your classroom, pause and recognise what you're doing. You're gathering data. You're testing assumptions. You're preparing to iterate.

Then ask yourself: where else could I apply this skill?

If you were building a product, what would you want to test before committing to building it? How would you check for understanding with potential customers? What would your "exit ticket" look like before launch?

You already have the skill. Now you just need to apply it in a new context.

The business world makes this stuff sound complicated because they use fancy words and charge consulting fees to teach it. But you've been doing continuous discovery with real-time iteration since your first day in a classroom.

You just called it teaching.

This reframe is from "Teach Yourself Out," which shows teachers how to translate classroom skills into products, income, and options. If you want the full translation guide, the book goes deeper.