PedTech, Not EdTech: What Changes When Pedagogy Leads the Product Brief

Somebody looked at the word EdTech and decided the problem was right there in the name.

The word puts the technology first. Education is the modifier. And if you build a product with technology first and education as the modifier, you end up with a technically impressive product that teachers open once, find does not fit the way they actually teach, and quietly stop using.

Dr Fiona Aubrey-Smith, co-founder of the National PedTech Partnership and co-author of "From EdTech to PedTech: Changing the Way We Think About Digital Technology" (Routledge), has spent over a decade making this argument in schools, trusts, and policy forums. Named one of the 50 most influential people in education by Education Business (2022) and EduFuturist of the Year 2025, she is not making a semantic point. She is describing a product failure mode that repeats itself across every generation of education technology: build first, ask the teacher later.

PedTech reverses that sequence. Pedagogy leads. Technology follows. The product brief starts with what the teacher is trying to achieve with a specific learner in a specific moment, not with what the technology can do.

This piece is about what that reversal actually means when it hits a product roadmap. Not as a philosophy, but as a set of concrete decisions that are made differently when pedagogy comes first.

Key takeaways

• PedTech is not a rebrand of EdTech. It is a different sequence of decisions. EdTech starts with what technology can do and asks how education can use it. PedTech starts with what the teacher is trying to achieve and asks how technology can serve that.

• The adoption problem in EdTech is mostly a brief problem. Products that teachers do not use were almost always scoped without asking teachers what they were trying to do. The technology arrived before the pedagogical question was answered.

• Aubrey-Smith's Funnel of Influences explains why adoption fails. Teachers do not adopt technology that conflicts with their foundational beliefs about what good teaching looks like, even when the technology works perfectly. The product brief has to engage with those beliefs, not assume they are obstacles to be overcome.

• The sequence change produces different design decisions. A product brief that starts with a pedagogical outcome produces different features, different interfaces, and different assessment mechanisms than one that starts with a technical capability.

• EduSmart Planner is an applied example of this in an Irish context. The brief for the platform started with what curriculum planning actually requires from a teacher, not with what AI can generate. The outcome is 250+ schools and 4,500+ teachers using the platform daily, with 75% less time on administration.

• PedTech thinking is most useful before the first sprint, not after the first launch. The cost of retrofitting pedagogy-first thinking onto a product that was scoped technology-first is almost always higher than starting the brief differently.

What PedTech actually means beyond the rebrand

PedTech is not a more teacher-friendly version of EdTech. It is not EdTech with better UX. It is a different starting point for the product brief.

EdTech, as Aubrey-Smith frames it, starts with the technology. Here is what the technology can do. How can we deploy it in an educational context? The product that results may be technically excellent. It may even be pedagogically coherent. But the sequence has started with capability and worked backwards to need, and that sequence tends to produce products that are useful in theory and unused in practice.

PedTech starts with the pedagogical question. What is the teacher trying to achieve with this learner, at this moment, in this context? What is getting in the way of that? How could technology reduce that friction without introducing new friction of its own? The product that results from that starting point is shaped differently from the ground up, because the ground was a pedagogical outcome rather than a technical one.

Aubrey-Smith describes this as the shift from "there's this great tool I want to implement in my classroom" to asking first: what am I actually trying to achieve with these students, and where are they right now? As she puts it, technology quite often, but not always, offers a contribution to that. The operative words are "quite often, but not always." A PedTech founder has to be willing to conclude that technology is not the answer to a particular problem, and design around that conclusion rather than around the assumption that technology is always the answer.

Why the sequence of the brief changes everything

A product brief that starts with a pedagogical outcome produces different decisions at every stage of the build than one that starts with a technical capability.

Consider two briefs for an AI-powered lesson planning tool.

Brief A (EdTech sequence): We have an AI model that can generate structured lesson plans from curriculum content. We will build a tool that allows teachers to input a topic and receive a lesson plan.

Brief B (PedTech sequence): Irish primary school teachers spend a significant proportion of their planning time on the administrative structure of lesson plans, including the Cuntais Mhiosúla (monthly planning format required by the Irish primary curriculum), rather than on the pedagogical decisions within those plans. We want to reduce the administrative burden without reducing the teacher's pedagogical authority over what gets taught and how.

Brief A produces a lesson plan generator. Brief B produces something different: a platform where the AI handles the structure, the teacher handles the teaching decisions, and the output reflects what that specific teacher wants to do with that specific class. The features overlap. The design principles do not.

EduSmart Planner, built by Square Root Solutions for CJ Fallon, started from the Brief B position. The AI generates a structured plan from the curriculum content. The teacher edits, adapts, and owns the output. As the case study describes it: the AI handles the structure; the teacher focuses on the teaching. That single sentence is a PedTech design principle, not a feature description.

The outcome of starting from that brief: 250+ Irish schools, 4,500+ teachers, 75% less time spent on curriculum administration, and overwhelmingly positive educator feedback. The technology is sophisticated. The adoption figures suggest the brief was right.

The Funnel of Influences: why teachers do not adopt what they do not recognise

Aubrey-Smith's most useful conceptual contribution to this conversation is what she calls the Funnel of Influences: the layered set of beliefs, experiences, and contextual pressures that determine how a teacher relates to any new technology.

The broad end of the funnel includes systemic factors: policy, curriculum requirements, school leadership priorities, the professional culture of the school. As the funnel narrows, the influences become more personal: a teacher's own experience of being taught, their beliefs about what good teaching looks like, the specific needs of the learners they are working with right now.

A product that lands at the wide end of the funnel and works its way down has a chance of being adopted if it is compatible with what is at the narrow end. A product that is built for the wide end without understanding what is at the narrow end tends to hit an invisible wall at the point where teacher beliefs live, and nobody can quite explain why adoption has stalled.

The practical implication for product founders is this: a teacher does not adopt technology that conflicts with their foundational beliefs about what good teaching looks like, even when the technology works technically, even when the training has been delivered, and even when the leadership has mandated it. The beliefs are upstream of all of those interventions. The product brief has to engage with them.

This is not a change management problem. It is a product brief problem. If a technology requires teachers to do something that does not fit their model of good teaching, no amount of change management will produce sustained adoption. The product has to be redesigned so that using it feels like good teaching, not like compliance.

Pro tip. The single most diagnostic question in a PedTech product brief is: does using this platform feel, to a good teacher, like good teaching? If the answer requires qualification ("well, once they get used to it" or "it will feel different once the benefits become clear"), the brief is not finished.

What changes at the product level when pedagogy leads

The shift from EdTech to PedTech thinking produces concrete differences in product decisions. Not in principle, but in the brief.

Feature prioritisation changes. An EdTech brief tends to prioritise features that demonstrate technical capability: AI generation, real-time analytics, integration with multiple systems. A PedTech brief prioritises features that reduce teacher friction at the specific moments in the teaching cycle where friction is highest. Those are sometimes the same features, often in a different order, and occasionally in direct conflict.

Assessment design changes. EdTech assessment is often designed to measure completion or progress through content. PedTech assessment is designed to measure the thing the teacher is trying to develop in the learner. The design question is not "did the learner finish the module" but "did the learner develop the understanding we were trying to develop, and how does the teacher know?"

The teacher's role in the product changes. In many EdTech products, the teacher is a user among other users: a content manager, an analytics viewer, a course assigner. In a PedTech product, the teacher is the primary design reference. The product is designed to extend and support what a good teacher does, not to create a parallel track that runs alongside teaching. The product surface that matters most is the one the teacher interacts with in the five minutes before a lesson or the fifteen minutes of marking after one.

The definition of success changes. EdTech success metrics tend to be platform-side: monthly active users, completion rates, time on platform. PedTech success metrics are learner-side: what did the learner understand by the end of the lesson that they did not understand at the start? A platform that achieves high completion rates against low learning outcomes has succeeded at its own metric and failed at its actual purpose.

The Irish classroom as a test case

The Irish primary curriculum has some properties that make it a useful test case for PedTech thinking.

It is structured, sequenced, and subject-specific in ways that give a digital tool clear pedagogical anchors. The Cuntais Mhiosúla monthly planning format, the subject-specific curriculum documents, the Irish-language medium requirement in Gaelscoileanna (all-Irish primary schools): these are not configuration options. They are the curriculum. A product built without understanding them is a product built for a different classroom.

The Irish primary teacher works in a context where class sizes are significant, where the same teacher covers every subject across the day, and where planning time is a finite and contested resource. A tool that saves meaningful time on administrative planning without reducing the teacher's control over what gets taught is a tool that fits that context. A tool that requires more planning time than it saves, or that produces generic outputs that need to be heavily customised before they are usable, does not fit it regardless of how technically capable it is.

EduSmart Planner's design decisions reflect this context: AI curriculum extraction from the specific Irish curriculum documents, Cuntais Mhiosúla plan creation built to the Irish primary format, multi-school teacher access for teachers who work across more than one school (a common pattern in the Irish primary system), and an admin layer that gives school principals real-time visibility into planning progress without having to ask individual teachers for updates.

None of those features are generic. Each one reflects a specific property of the Irish classroom context. That specificity is what produces 250+ schools and 4,500+ teachers using the platform daily. A generic lesson planning tool could have been deployed at a lower build cost. It would not have achieved those adoption figures because it would not have fit the context well enough to feel, to an Irish primary teacher, like good teaching practice.

What founders building for teachers should actually do differently

The practical implication of PedTech thinking is a set of changes to how a product brief is written, not a set of changes to the technology itself.

Start the brief with a teaching moment, not a technical capability. Describe the specific moment in a teacher's day where the problem you are solving is most acute. Not "teachers spend too much time on planning" but "an Irish primary teacher arrives at school at 8:30am and has twenty minutes before the first class to check whether the plans for the day are ready, adjust for an absent colleague, and confirm that the resources for the third-class literacy lesson are accessible." The more specific the moment, the more useful the brief.

Write the non-adoption case before the adoption case. Before describing why teachers will use the product, describe the specific ways in which a good teacher might decide not to use it. What aspect of their teaching practice might it conflict with? What belief about good teaching might it implicitly challenge? Those are design problems to solve in the brief, not change management problems to manage after launch.

Design the teacher interface before the learner interface. The product brief for most EdTech platforms prioritises the learner experience because the learner is the end user. In a PedTech product, the teacher experience determines whether the platform is used at all. A learner cannot use a platform that a teacher has decided not to deploy. Start with the teacher interface.

Test the brief against Aubrey-Smith's question. Does using this product feel, to a good teacher, like good teaching? Run the brief past two or three experienced teachers before the first sprint and ask them to identify the moment where the answer to that question becomes uncertain. That is where the design needs more work.

What PedTech is not

PedTech is not a framework for excluding technology from classrooms. Aubrey-Smith is not making a Luddite argument. The argument is about sequence and priority, not about the role of technology in education.

PedTech is not an argument that all EdTech is badly designed. Many EdTech products have been built with genuine pedagogical understanding and achieve real learning outcomes. The PedTech framing is most useful as a diagnostic for the products that do not achieve adoption, not as a criticism of the category.

PedTech is not a guarantee of adoption. A product built with a pedagogy-first brief can still fail. The brief is the starting point. The execution, the content, the support, and the school context all matter too. But a product built without a pedagogy-first brief is starting from the wrong place, and the adoption figures for EdTech broadly suggest that is not a rare problem.

PedTech is not only for school-facing products. The same argument applies to corporate L&D platforms, professional training tools, and university-facing learning systems. Any product where the person delivering the learning (the teacher, the trainer, the facilitator) is a mediating layer between the technology and the learner benefits from designing that mediating layer first, not as an afterthought.

Frequently asked questions

What is the difference between EdTech and PedTech in practical terms?

EdTech starts with what technology can do and finds educational applications for it. PedTech starts with a specific pedagogical outcome (what a teacher is trying to achieve with a specific learner) and designs technology to serve that. The practical difference shows up in the product brief: an EdTech brief leads with technical features and capabilities, a PedTech brief leads with a description of a teaching moment and what the teacher needs in it.

How does PedTech thinking affect AI features in education products?

It changes the design question from "what can AI generate?" to "what would a teacher do with AI-generated output, and does the product design support that?" A PedTech brief for an AI lesson planning tool does not ask whether the AI can generate a lesson plan. It asks whether the output fits how the teacher actually plans, whether it is editable in the way teachers naturally edit their plans, and whether using it feels like planning rather than like processing AI output. The Surpass Assessment podcast with Aubrey-Smith makes this explicit: it is not about using more technology, it is about using the right technology to deepen learning and empower teachers.

Is PedTech relevant for products aimed at university or corporate learners, or only for school-age learners?

The same principle applies across every level of education and training. Any context where a human facilitator (teacher, trainer, lecturer, coach) mediates between technology and learner benefits from designing the facilitator's experience first. The specific pedagogical context differs, but the sequence of the brief does not.

What is the National PedTech Partnership?

The National PedTech Partnership is a network of pathfinding schools and trusts in the UK co-founded by Aubrey-Smith. It applies PedTech principles across participating schools, running research programmes that test what happens when technology deployment decisions are made by starting from the pedagogical question rather than the technical capability. The Chartered College of Teaching's EdTech Evidence Board, which Aubrey-Smith sits on, functions as an independent quality standard for EdTech products making evidence-based claims.

How does a founder know whether their product brief is starting from the right place?

Aubrey-Smith's diagnostic question: does using this product feel, to a good teacher, like good teaching? If the answer requires qualification, the brief has not resolved the pedagogical starting point. A more structural test is to read the brief and check whether it describes a teaching moment before it describes a technical feature. If the first substantive section of the brief is a feature list rather than a description of the teacher's context, the sequence is probably wrong.

Does PedTech require more expensive or longer builds?

Not necessarily. PedTech thinking changes the brief, not the build cost. A product with a clear pedagogical brief is often faster and cheaper to build than one whose brief is vague about the pedagogical outcome, because the scope is better defined. The cost of PedTech thinking is a longer brief process, not a longer build. The cost of not applying it tends to show up in adoption figures rather than in the build itself.

The argument Aubrey-Smith has been making for over a decade has not changed: start with the learner, start with the teacher, start with the pedagogical outcome. Let technology serve that, rather than making that serve technology.

The products that have achieved real adoption in Irish and UK schools are almost always the ones where that sequence was followed. The products that have not achieved adoption are almost always the ones where it was not.

Or, if you are working on a product brief for an Irish or UK school-facing product and want to test whether it is starting from the right pedagogical question, a complimentary Discovery Sprint with Square Root Solutions will surface that. Book a Discovery Sprint