Edtech Can't Simplify What It Hasn't Lived

Sarah Finnemore's recent piece, The Observation Principle: Why Great Edtech Products Start by Watching, Not Building, made an argument that more edtech teams need to hear. Great products start by watching, not building. Schools describe their challenges at a strategic level, workload, attendance, safeguarding, SEND, and the real opportunity usually sits underneath those headlines in the small operational frictions that have become so normalised nobody mentions them anymore.

I agree with all of it. I would only say the iceberg is far bigger than the part this points to. The small operational frictions are the visible tip, the bit you can see breaking the surface in a single day. Underneath sits the much larger mass that holds those frictions in place, and it is structural, not operational. Statutory duties and inspection regimes that dictate what schools must record and when. Funding pressures that decide what is even possible. Accountability that lands on named individuals when something goes wrong. Trust-wide decision making, safeguarding thresholds, the policy weather that shifts every year. The duplicated spreadsheet is real, but it is a symptom of forces that no amount of watching the spreadsheet will reveal. If you only solve the friction on the surface, you have chipped at the tip and left the mass untouched.

I want to add to Finnemore's point, because observation is where good products begin, and the harder question is what you do with what you see and how far below the waterline you are willing to look.

What you notice depends on who is doing the watching

Spending a day in a school is the right instinct, but on its own it is nowhere near enough. A single day is a starting gesture, not a substitute for understanding, and treating it as sufficient is exactly how teams end up confident about the wrong things. Two people can sit in the same staffroom for that day and leave with completely different notes. A product manager who has never taught will watch a teacher juggle four systems before 9am and conclude the teacher needs better software. Someone who has actually done the job will recognise that the teacher has already triaged those four systems into a workable order and is quietly protecting the one task that matters most that morning.

The difference is interpretation. Observation only ever hands you raw material. Whether you read it correctly depends on the context you bring to the room, and two people with different backgrounds will pull opposite conclusions from exactly the same scene. The watching is the easy part. Knowing what you are actually looking at is the part that decides whether the product is any good, and it is worth being honest about how much you are reading in versus how much you genuinely understand.

Domain expertise is what stops you solving the shallow problem

This is the part I would underline most. Observation without domain expertise tends to land on the surface problem, and the surface problem is rarely the one worth solving. You can watch a school for a day, see the friction clearly, and still misjudge it completely, because you do not have the context to know what that friction is actually attached to.

An outsider watching a SENCO (the Special Educational Needs Coordinator responsible for SEND provision in a school) chase paperwork sees an admin burden and builds a tool to speed up the paperwork. Someone who understands the sector knows that paperwork sits inside a statutory framework, that the timing is tied to Education, Health and Care Plan (EHCP) deadlines, that a parental complaint or an inspection can hinge on it, and that the real problem is not the speed of the form but the accountability and risk wrapped around it. Same observation, two completely different products. One saves a few minutes. The other addresses what was actually keeping that person up at night.

Education is full of this. The vocabulary, the funding pressures, the inspection regime, the way decisions are distributed across a trust, the political and regulatory weather that changes what schools are allowed and required to do. None of that is visible from watching alone, and all of it shapes whether a product is genuinely useful or just superficially helpful. You cannot interpret what you are seeing without it. Observation tells you where the friction is. Domain expertise tells you what that friction means, why it exists, and which version of the problem is the one that matters.

This is also why edtech is hard to enter from the outside on enthusiasm alone. The industry does not just need products that work. It needs partners who understand how schools actually function, how they are held accountable, and where the genuine leverage sits. That depth is what separates a company that genuinely supports the sector from one that just adds to the pile. The teams that earn trust in education are the ones who clearly understand the world they are building for, not the ones who learned it for a week to ship something.

The workaround tells you there is a problem, not what the solution is

Finnemore is right that the workaround is the clue. When staff build a spreadsheet, a manual checklist, a Teams thread that runs parallel to the official system, they are telling you the ecosystem is failing them somewhere.

But a workaround is a symptom, and symptoms can mislead. Sometimes the spreadsheet exists because the software genuinely cannot do the job. Sometimes it exists because nobody was ever trained on the feature that already does it. Sometimes it exists because one influential member of staff prefers it that way and everyone else has fallen in line. If you treat every workaround as a feature request, you will build software that automates habits rather than solving problems.

The skill is asking why the workaround exists before deciding to absorb it into your product. The spreadsheet that compensates for a missing capability is a roadmap item. The spreadsheet that exists out of habit is a training and change problem, and shipping a feature for it just moves the friction somewhere else.

Everything overlaps, and that is a design constraint, not a mission statement

The observation that schools do not experience their day in product categories is the most important point in the original piece. Attendance touches safeguarding, safeguarding touches wellbeing, SEND touches workload. Operationally, none of it is separate.

The risk is reading that as a brief to build the all in one platform that solves everything, which Finnemore rightly warns against. The interconnectedness is not telling you to expand your scope. It is telling you to be unusually serious about the edges of your product, the points where your system hands off to another. Most of the daily friction in schools does not happen inside a single tool. It happens in the gaps between tools, in the re-keying, the exporting, the copy and paste from one system into another.

A focused product that handles its handoffs gracefully will beat a sprawling platform that does ten things adequately. The lesson from observing the overlap is not do more. It is connect better.

And from my perspective, there are far more fundamental issues to solve before anyone piles another tool onto the screen. Schools are not short of software. They are short of systems that talk to each other, data they can trust, processes that are not duplicated three times over, and time. Adding a new product into that environment, however good, often increases the load before it reduces it. The honest first question is rarely what can we build. It is what is already broken underneath, and would this school be better served by us fixing a foundation than by us shipping another tool. A lot of edtech skips that question because the foundation is unglamorous and a new feature is easy to sell. The overlap between systems is telling you to start at the bottom, not the top.

Simplicity is evidence of understanding

The point that schools want clarity, visibility, fewer clicks and less cognitive load rather than more functionality is true. The usual excuse is that simplicity is commercially inconvenient, that feature lists win procurement comparisons and a clean product does not photograph well in a sales deck. I do not buy that as the real obstacle. If you cannot simplify a product, that is usually a sign you have not understood the core problem well enough to know what to take away.

Complexity is what you ship when you are unsure which part actually matters, so you keep all of it just in case. Simplicity is what becomes possible once you genuinely understand the work, because then you know exactly which two things the user needs and which eight are noise. Simplicity is not a sacrifice you make against the sales team. It is the visible result of having done the hard thinking. A team that cannot strip a product back is not being commercially brave, it is telling on itself, because it does not yet understand the problem deeply enough to be confident about what to remove.

This is also why depth and simplicity go together rather than pulling against each other. The companies that earn the right to a clean, focused product are the ones that understood the messy reality underneath it first. You cannot simplify what you do not understand. Observation gets you closer, but it is the understanding that follows, the kind that comes from real domain knowledge, that lets you cut with confidence instead of hedging with features.

Observation has to become a habit, not an event

The thing I would add most firmly is this. A single day of watching is a strong start and a weak system. Schools change across the year. September looks nothing like the week before half term, and the frictions that dominate exam season are invisible in October. A product team that observes once has a snapshot. A product team that builds observation into how it works has a feed.

That can be modest. A standing relationship with two or three schools who let you sit in a few times a year. A habit of watching real usage rather than only reading support tickets. A rule that nobody ships a workflow change without seeing it used in context first. The companies that get this right are not the ones that ran one immersive observation exercise and wrote it up. They are the ones who never really stopped watching.

You have to live it, not just watch it

Here is the point I would end on, because it sits underneath everything else. Observation is critical, but observation on its own is limited. Watching tells you what is happening. It does not give you the ability to reflect on it properly, to think critically about why it is happening, or to tell the difference between what people do and what they should do. That deeper reading does not come from standing in the room. It comes from having lived the work yourself.

There is a real difference between seeing a process and having been responsible for the outcome of that process. When you have only watched, every habit looks like a requirement and every workaround looks like a need. When you have lived it, you can feel which parts are load-bearing and which are just scar tissue. You know the weight of getting it wrong, the quiet pressure that never shows up in a feature request, the reason a teacher does something the long way even when a faster path exists. None of that surfaces from observation alone, and you cannot reason your way to it from the outside.

This is also where I would add a note of caution about launch partners. Building with launch partners is important, and I would not do it any other way. But a launch partner tells you what they are used to, and what they are used to is not the same as the root problem, and neither of those is necessarily what they should actually do. If you only listen to what partners are accustomed to, you will build a faster version of a broken process and call it progress. The job is to separate the habit from the need from the right answer, and you can only do that with enough lived understanding to know which is which.

Finnemore's core point stands. If you have never properly watched the problem unfold in its natural environment, you are probably solving the wrong thing, or the right thing in the wrong way. I would only push it one step further. Observation opens the door. But watching is not the achievement, and it is not the end of the work. You have to live it to understand the core, and it is that lived understanding, not the watching alone, that tells you what to actually build.