Jobs to Be Done, Supercharged with AI: How Memrise Rebuilt Product Development from Scratch

For most of the past 15 years, Ben Whately has been frustrated. As co-founder of language learning app Memrise, which has grown to around 85 million users, he has watched his teams pour time and money into one problem: how to build faster.

At Appsforum London, he described what happened when that problem started to go away, and why he believes almost every app company is still moving too slowly.

"I'm almost sure that whatever you're working in, you're moving too slowly, probably in what you're building, and probably in adopting AI."

He was clear: "I'm not an AI maximalist. I'm kind of terrified by it. But in a work context, there's just no other option."

The hidden blocker: people who say they're already using AI

According to Ben, the biggest obstacle to adoption isn't resistance. It's people who believe they're already at the front. Most developers will say they use AI to write code, but he sees that as only the very first step. "That is AI 0.1. But because they're not objecting, it makes it kind of hard to move faster."

Two ideas that shape the approach

Ben's thinking rests on two frameworks.

The first is Jobs to Be Done, developed by Bob Moesta and Harvard Business School

professor Clayton Christensen. Its core idea is that people "hire" a product when they're struggling with something, and the product builder's task is to understand that underlying job. As Ben put it, the question is what people actually want – "because it's definitely not what they asked for."

His example was Patek Philippe. Interviews with buyers showed the watch wasn't doing the job of telling the time. For many wealthy, older buyers, its job was to give grandchildren something to remember them by. That insight led to the brand's famous positioning: you never really own one, you look after it for the next generation. "It shows quite how far the job that it's doing is from what it looks like on the surface."

The second is Boyd's Law. Fighter pilot and aircraft designer John Boyd studied dogfights between the MiG-15 and the F-86. The MiG was faster and more agile yet lost most of the encounters. The F-86 advantage was a hydraulic joystick that made turning easy, so pilots turned more often and kept gaining better positions. "Speed of iteration beats quality of iteration every time."

Ben sees the same dynamic in product teams, where ideas get killed before they're tested because they'll take too long to build. His pet peeve is the self-described perfectionist who won't ship something imperfect. "I'm a perfectionist – that's why I want to ship something that isn't perfect. Because the only way to get to a perfect product is to iterate really, really quickly."

Software is no longer the bottleneck

In the traditional product cycle (customer discovery, hypotheses, prototyping, software development, usage data), development has always been the pinch point. Ben argued that for teams willing to change, that constraint has almost disappeared.

He shared a question one AI-forward leader now opens developer interviews with: do you read the code AI writes? A "yes" ends the interview. "You should be writing so much code that no human can possibly go over it, and you should be building systems that mean that you don't have to."

At Memrise this means multi-agent adversarial code review, which he acknowledges is compute-heavy and needs ongoing optimization. "You make the system that can go at lightspeed and then you make it work."

Prototyping to learn, not to verify

With development no longer the constraint, attention turned to the rest of the cycle. Discovery and hypothesis generation were the easy wins: AI can analyse huge volumes of interview transcripts in parallel, holding context across thousands of conversations that no single person could absorb.

Prototyping changed more fundamentally. Tools like Figma could only simulate the first few seconds of a language learning experience. Now working prototypes can be built almost instantly, which turns prototyping from a verification step into an exploratory one. "Rather than just verifying, did I get it right or not, you can give people three different prototypes. By having contrast between them, you actually learn a lot more about their jobs and about their needs."

Progress tracking was the case in point. For years, Memrise had designed progress systems, tested them, shipped them after months of work, and still heard users say they wanted to understand their progress better. Now prototypes can be dropped into a live interview and adjusted on the spot. "It allows you to learn almost infinitely more about customer needs."

The constraints that remain

Two parts of the cycle are still hard. The first is the discovery interview itself, which depends

on reading people, probing and following threads. "I think it's going to be a while before AI can do a really good customer discovery interview."

The second is real usage data. "Anyone in their bedroom can build a system that can generate code and analyse customer interviews. But until you've actually got lots of users, you don't have any data." 

That realisation shaped Memrise's next chapter. The app gains around half a million new users a month organically with no marketing spend, giving it a steady flow of people to experiment with.

Refounding Memrise

Last year Ben pitched investors on turning Memrise into a place to work out what agile looks

like in the age of AI. The company was refounded as a new entity, Memrise Technologies, buying out the existing investors; the deal completed on Christmas Eve.

The results of the first full loop came back recently. AI analysed discovery transcripts and metrics, identified the highest-leverage opportunities, built prototypes, ran them through user testing, iterated, shipped, and analysed the outcome. It delivered a 20% uplift in soft-activated new users, "a better result than any single product feature built by the human product team in the previous three years."

Ben was clear that this isn't "AI analyses, humans decide". "We are there to engineer a system that gets the results. And if the results at the end aren't good, then we need to re-engineer the system."

A smaller, broader team

Memrise has gone from a peak of 120 people to 12. "We are moving infinitely fast. I can't even compare how much faster we're moving in terms of product shipping."

Specialists remain, but everyone is now a generalist team member who joins discovery interviews and builds across the stack. "They're no longer an Android developer who sits doing Android development waiting for tickets to be made for them." A breakthrough came when a backend developer realised he could ship on iOS and Android without reading that code, then asked why he was still reading backend code at all.

Ben was candid about how difficult the shift is. He has seen software architects thrive, but not traditional developers. "I've not seen someone who really takes joy in solving difficult engineering problems actually give that over to AI."

Early commercial signs are positive. "The leading indicators are moving, revenue is starting to go up. It had been on a slide, and that has flattened and is turning around."

What this means for app teams

Most of the AI conversation in app development still centres on one question: how do we write code faster? Ben's session is a useful reminder that this is the narrowest version of the opportunity. Once code stops being the constraint, every other stage of the product cycle is exposed as slow, simply because nobody had a reason to optimise it before.

The most interesting shift here isn't automation, it's what speed does to learning. When a prototype costs almost nothing, it stops being a test of whether you were right and becomes a tool for finding out what users actually need. That changes the role of research, design and product management far more than it changes engineering.

It also reframes what's scarce. If anyone can generate code and analyse data, competitive advantage moves to the things that can't be generated: real users, honest conversations with them, and teams skilled at drawing out the job behind the behaviour.

Memrise's organic user base is an advantage few studios have, but the underlying lesson applies at any scale. A small group of deeply understood users is more valuable than a sophisticated pipeline with nothing running through it.

The harder truth is organisational. Going from 120 people to 12 is an extreme example, but the direction is clear: specialists become generalists, and the job shifts from doing the work to designing the system that does it. Ben's observation that skilled developers often struggle most with this deserves attention. The teams that move fastest may not be the ones with the strongest engineers, but the ones most willing to let go of how they used to work.

None of this means human judgement disappears. It moves upstream, into how systems are designed and how well teams understand their users. For app companies weighing how far to go with AI, Boyd's Law is a useful test: if your current setup makes iteration hard, you're likely losing ground to competitors who've made it easy, regardless of how good each individual release is.