Case study: The Raspberry Pi Foundation’s Code Editor for Education
How the Raspberry Pi Foundation spotted an opportunity and made it their own.
👋 This week, a case study on doing product discovery when you spot a void to fill…
Get something in the diary for the new year: our online meetup on 14 January with Ian from the V&A Academy and our pre-Bett meet up at Zen Educate on 21 January. Plus, our January courses here.
“If we'd relied just on our secondary research, it might have sent us in completely the wrong direction,” says Melissa Farrington, Product Manager at The Raspberry Pi Foundation. “We would have assumed we needed many more complex features. It would have made the whole process a lot more challenging.”
Mel is reflecting on The Raspberry Pi Foundation’s recent launch of classroom management features for their Code Editor. Back in November 2023, Replit announced that they were discontinuing their ‘For Education’ plan, which included a code editor used by many educators and schools to teach coding in the classroom.
Watching the outcry happening in online forums, the team at The Raspberry Pi Foundation spotted a potential opportunity to help.
The Raspberry Pi Foundation is a global charity headquartered in Cambridge, UK, with the mission to enable young people to realise their full potential through the power of computing and digital technologies.
Developing the Code Editor aligned with their product strategy to help young people at the start of their coding journey and provide resources that can support educators in the classroom.
“If it's your first experience with text based coding, then you need a simple, clear and age appropriate interface,” says Mel. “And seeing the reaction to that news on forums made us start to think about the solutions educators would use instead.”
They didn't immediately commit to building out the Code Editor for use in the classroom. “But we made a decision to rapidly conduct discovery into what would be needed,” says Mel.
Exploring the opportunity
They started by quickly creating a survey. “We shared it on social media to gather initial reactions and understand the high level user needs,” explains Mel. The survey finished by asking if people would opt into further research. “Off the back of that, we did a series of interviews to understand more.”
The team was conscious of schools’ time lines. They knew they would have to decide quickly if they were going to commit to offering something for the next academic year. Replit were going to stop offering their solution on 1 August 2024.
“We completed all of the user interviews by the end of December, to help us assess the opportunity and develop a hypothesis about what a minimum viable product (MVP) would need to offer,” says Mel. “Early in the new year we developed a design prototype and then tested that again with users to understand their initial feedback.” In total, the team held over 20 user research interviews during the discovery stage.
This process helped them validate some of their hypotheses they had developed from the initial research interviews and better understand the core functionality needed to build a starting set of features.
“We knew that we wouldn't be able to offer everything Replit had offered, at least to begin with,” says Mel. “So we really had to try and dig into what the real core features were.”
The team had decided upon four or five big things to test. They wanted to understand what was core and what could wait. I asked for examples of what they found out.
“We wanted to understand if predefined or pre-written content based on a certain curriculum would be useful: lesson templates or project templates that educators could use,” remembers Mel. “But our research suggested that educators just needed to be able to create their own projects they can share with students and that that was enough to get started.” Providing templates was something that should be on the horizon, but could wait.
The prototype testing helped them prioritise a list of features. “We had to scope what we were able to deliver in the time frame. It was a balance of making sure we had everything we needed to be ready for a cohort starting in September.”
Balancing market analysis with primary research
Whilst they were conducting research interviews, the team had also done some analysis of other tools that were available and the other organisations operating in the space. This helped them consider their own positioning.
Whilst it also gave them ideas about potential features, Mel suggests that if they’d have relied on that alone, they’d have built something that missed the mark for their specialised audience. “Balancing what was out there with understanding what users thought was most important was absolutely crucial,” reckons Mel.
One example was collaborative coding functionality that many of the tools aimed at professionals offered. “This did come up in some interviews,” says Mel. “But when put in comparison to other key features it came a lot lower down the list. For example, when compared to giving individual feedback, group work was nice to have. The functionality focused on the individual was most interesting to educators teaching text-based programming to young people.”
Having initially explored the idea with a UX Researcher, a designer and some input from engineering, Mel was then joined by a small team with the goal to deliver the product in six months.
Keeping people interested
Once they had committed to delivering on the opportunity, the next challenge was keeping their initial audience interested. Mel worked extremely closely with the marketing lead to develop a plan that worked for both marketing and product development.
“We got people to register their interest for updates so that we could reach out to them when we had things to share,” says Mel. The team knew that they also needed to be clear about the offer before schools broke up for summer.
“We had to share something in June that helped educators understand what would be on offer in the autumn term,” says Mel. “We also developed a preregistration journey that enabled schools to get verified early. This enabled us to get the word out and schools registered early, as well as being able to understand the demand and be ready to handle the capacity.”
Over the summer over 250 schools preregistered as educators explored alternative options before the new year began. Since the launch in September, over 400 schools have access and have started to use the product.
Future opportunities
Mel says that they prioritised the features most important to educators to get to market. Now, they are innovating based on the feedback that they’re collecting from people using it in the classroom. This includes things like being able to give more contextual instructions and feedback to students. I wonder about how the team is thinking about AI?
“AI is something that we did explore and it is something now appearing in professional IDEs,” says Mel. “But there are mixed views on it at the moment about whether it is helpful in an environment where you are learning to code and how best to use it. We saw different reactions in our interviews.”
The first version doesn’t include any AI features, but there is a lot of research going on at the Foundation to understand how AI might support the teaching and learning of programming.
“AI is definitely on our radar, but it's about how we can draw insight from research in this area to inform how we develop the Code Editor,” explains Mel. “We are extremely mindful about doing that in a pedagogically sound way that is going to be helpful in this context.”
Summary
We reflect on the conversation and the things that might be useful to others.
Bring users into the process early. Sense check the decisions you’re making along the way.
Do your market research. But resist the temptation just to rely on that, validate it with your own users.
Think about the seasonality and how you can introduce milestones that keep people engaged and excited about what you’re doing.
“Keep revalidating that you're on the right path,” advises Mel. “At some point you have to commit to your direction and feel confident in that judgment. Definitely do the market research and analysis of what's out there. But try to resist the temptation of relying entirely on that. Always speak to users. Whether that takes the form of a survey or interviews or both. Making sure that you're getting that information early will help steer you later on.”
You can find out more about the Raspberry Pi Foundation’s Code Editor for Education here. You can also try out the Code Editor here. Mel and the team are interested in hearing more feedback so get in touch! The Code Editor is open source so you can also contribute and help them further their mission by reaching more people.
Mel also recommends this podcast on the keys to a successful product launch and this article on iterative development.