At New Haircut, we recently did a design sprint with LRN, an education startup that developed an adaptive learning platform. Adaptive learning is the use of automated teaching to “adapt” the educational content to each student’s needs and abilities. Some consider it “the most ground-breaking tech innovation” in education.
The problem
LRN started building an adaptive learning platform back in 2015. Their goal was to improve the educational experience for everyone: students, teachers, and parents. Its founders had decades of experience in education systems, artificial intelligence, game theory, and intelligent tutoring systems—that’s pretty much every tool in the toolbox one needs when building such a platform.
But having a great product idea and the technical expertise is not enough to keep you out of trouble. After 12 months, LRN came to a standstill: The developer they hired built the wrong product. This caused spirited debates among the founders and inaction for fear of yet another failure. They weren’t wrong to have these fears: 15% of bootstrapped startups fail because they hire inexperienced people.
“15% of bootstrapped startups fail because they hire inexperienced people.”
The process
We use GV design sprints to take on big challenges, so I immediately knew LRN was a great candidate for such a sprint. A sprint works like “a superpower” by helping companies get customer feedback on their product in only 5 days. They needed to define their product, and there was no more time to waste.
Day 1: Understanding the issue
On the first day of the sprint, our 6-person team gathered information about the problem at hand and spoke to experts. Then we began mapping the challenge on a whiteboard. The rules of the sprint state that you have to pick a manageable piece of the problem that can be solved in one week. It’s tricky because everything on the whiteboard seems to scream back at you, “Pick me!”
LRN’s platform served several user groups: students, teachers, school districts. They all had different needs and pain points. But we could not tackle everything in 5 days. The first step was choosing one customer and one problem.
We knew parents enrolled their kids in private schools because teachers there could dedicate more attention to each kid. Our assumption was teachers could do that because classes in private schools were smaller. “Let’s focus on teachers,” said Malcolm, one of the LRN founders.
Now, reducing the size of a class wasn’t something an adaptive platform could do. But freeing up class time was possible. Teachers could use the platform to build personalized lessons. This way, they’d spend less time transmitting knowledge and more time guiding students through that knowledge.
Our design sprint goal was to understand how a technology platform could help teachers build personalized lessons fast.
Day 2: Sketching solutions
Day 2 was all about visualizing solutions. Everyone on the team sketched—even those reluctant to do so. The experts we spoke to on Monday pointed out that student reports would help teachers tailor educational content, so many of the solutions we sketched included student performance reports. Even so, they were wildly different from one another, which is the whole point of the exercise. A sprint should unearth a wide range of solutions.
Day 3: Choosing a solution
If the second day of the sprint is about finding a million ways to solve your problem, the third day is about turning those into a million-dollar idea. In our case, the official sprint deciders picked a solution that showed how the LRN platform could aggregate student performance data into individual and class reports. To be fair, it wasn’t (and it never is) just one solution, but rather scenes from several sketches linked together. The one pitfall of our winning solution was that LRN lacked the specific information about student learning goals and metrics. But we had an idea.
Day 4: Prototyping our solution
On Thursday morning, we put the prototyping on hold and scheduled a few extra interviews with experts. Deviating from the sprint schedule was a calculated-but-risky move. Our hope was that a second (and more targeted) foray into the minds of the experts would shed some light on the goals and metrics section. Try to stick to the rules if this is your first sprint.
When the interviews were done, we used InVision to start working on a prototype. The prototype was rather complex for a design sprint. It had 5 sections: Welcome, Dashboard, Goal Library, Learning Sessions, and Reports.
Day 5: Testing our prototype with real users
Given our attempt to screen more experts on Thursday, we were up against our deadline to complete the prototype in time for customer testing. In fact, we finalized it minutes before the first tester arrived.
“A sprint should unearth a wide range of solutions.”
A few patterns emerged by the end of the day. Teachers found the personalized learning sessions module to be confusing and time-consuming. We expected this since we missed key data in the goals and metrics section. And yet, they were receptive to the student and class reports. They believed such reports would allow teachers to take specific actions while the lessons were still underway.
We were able to test our hypothesis that reports were key in helping teachers build personalized lessons. We were not able to vet the goals or measure and confirm which students skills are important. But that would be open game for an upcoming sprint.
Takeaways
So did we know exactly what a successful adaptive platform should look like? Not yet. But the sprint helped us get closer. There’s more work to be done—at least one more sprint is required to confirm the goals and metrics section as well as our final MVP approach. But after just one intense week, we were ready to define LRN`s 6-month product roadmap.
Before the sprint, the LRN founders were stuck. They lost time and money building a learning management system. It was a product that wasn’t solving a market need or highlighting their strategic point of view. Their stress levels were through-the-roof. During the sprint, they had to let go of their differences and unrealistic goals, prototype a viable solution and test it with users.