Founder Interviews: David Kofoed Wind of Peergrade

Learn how David and the Peergrade team found their first customers by manually reaching out to potential users one by one, eventually scaling their peer grading tool to over 7000 institutions.

Davis Baer: What’s your background, and what are you working on?

My name is David Kofoed Wind. I have a degree in applied math and computer science from The Technical University of Denmark and a Ph.D. in machine learning and learning analytics from the same place. I taught myself programming at a very young age in order to build games and worked as a software developer up through high school.

Peergrade is an educational tool that increases critical thinking and collaborative learning through peer to peer feedback. Teachers set up peer feedback sessions on Peergrade, students submit their work and then give constructive feedback to each other in an anonymous fashion. This way teachers can save some time while students learn more through giving and receiving feedback.

Today we have teachers from more than 7000 institutions in over 150 countries, and we have been growing between 200% and 400% each year.

What motivated you to get started with your company?

The idea for Peergrade came through my own teaching and research. During my studies, I spent some time as a Research Officer at University of New South Wales in Australia, working on statistical models for inferring fraudulent behavior in voting systems. A few years later I started my Ph.D. and got the possibility to teach a course on my own. I decided to teach a rather applied course in data science, which I called “Computational Tools for Big Data”. The course got immensely popular (I suspect due to the title), and 150 students enrolled in the course, making it one of our largest classes.

I had planned out the course with weekly lectures, plenty of exercises and weekly submissions of assignments. That plan didn’t really align with the fact that I had 150 students, and the grading work quickly added up to something like 1000 pages each week. Some of my colleagues recommended using a multiple choice exam instead of the weekly assignments, but I personally believe that continuous assessment is a great way to structure a course for high amounts of learning.

Earlier I had seen cases of using peer review in an education setting, but I could not find a good tool to do it myself. As a classical programmer decision, I started building my own system in my free time. The other part of the motivation was that I had a feeling that my research in fraudulent voters could be applied to find students who were poor graders.

When I had a prototype working, I talked to my supervisor Ole Winther, who recommended that I try and sell a license to our department. The timing was good, as our university was investing more resources into e-learning initiatives and our department bought licenses for a few courses, including my own. I called up my old high school friend Malthe Jørgensen and he joined as the CTO. We then spent the rest of the summer and fall building Peergrade while teaching (Malthe became my TA) the course and testing the system with all our students.

What went into building the initial product?

Building something for yourself is always a lot easier than building for someone else. Because I was my own first user, I had a very clear roadmap of things we needed to build to make this useful for myself. We started working in the early summer months and had a very scrappy MVP ready for 1st of September when the course started. It didn’t do much since students didn’t have to submit anything before the second week of the course. Week by week, we added the features relevant for students and ourselves.

When I started working on Peergrade I was mainly proficient in Python, R, Matlab, and C++. Due to this, I picked Python with Flask and MongoDB as the initial technologies in Peergrade. Malthe, being a much better web developer than me, accepted those decisions, but we have since changed Flask to Django and MongoDB to PostgreSQL. After the first semester, we found our third co-founder Simon Lind who is a designer and front-end developer.

Alongside developing Peergrade and teaching the course, I continued my Ph.D. research. Part of my research was around other things, such as analyzing data from a large number of smartphones, but I slowly started spending more time on theoretical investigations of what could be done to make Peergrade smarter. Working on my Ph.D. and Peergrade simultaneously was great in order to extend our runway, but clearly led to situations with a lot of work to do. I finished my Ph.D. at the end of 2018, working on it alongside Peergrade for 3 years.

One of the challenges when building a product for yourself is that it doesn’t force you to think about problems, solutions, and visions in the same way. It leads to a product-first strategy instead of a problem first strategy. You quickly fall in love with your own product and build very advanced functionality for yourself instead of thinking about all the other potential users you could get. If I could go back, I would probably have kept Peergrade simpler in the early days, and waited with more advanced functionality until I had more users to get feedback from.

How have you attracted users and grown your company?

The first two users were myself and my supervisor who immediately saw the potential for his own course. My next step was to send emails to other instructors around campus and go meet with different lecturers and department heads. Based on this, I managed to convince a few different lecturers in management science and construction engineering to try out Peergrade in their courses. After initial good results, I often observed people saying that Peergrade would only work in natural sciences since the humanities lacked clear definitions of what is good and bad (it is hard to judge a poem). To test this, I got a meeting at the department of humanities at the University of Copenhagen and managed to convince them to run Peergrade in 10 courses for the spring semester (it actually worked even better in humanities).

Most of our outreach, in the beginning, was just cold-emailing instructors and e-learning people at various institutions. One of the few good things about selling to educational institutions is that they have all their contact information available online. When I got in touch with someone, I would go to their office (by bike or bus), talk to them about their courses and show them Peergrade. Some of our early university deals required 100+ emails and 10+ meetings before becoming a reality. Today, these personal meetings are still a large driver of getting new customers and I personally spend many hours each week talking to instructors about their courses.

Malthe and I decided to talk to our old high school teachers at some point, to see if there was a relevance for Peergrade in schools (our initial assumption was that it was not very relevant because the number of students was much smaller). To our surprise, they liked it a lot, and we started seeing Peergrade spread in the high school sector of Denmark. In January of 2017, we got an email from Jennifer Gonzales, saying that she was planning on featuring us in her blog post “6 Ed Tech Tools to Try in 2017” (https://www.cultofpedagogy.com/ed-tech-tools-2017/). We didn’ think much of this, but that blog post alone has given us more than 1,000 trackable signups (and continues to drive traffic). Today, most of our users are school teachers, and at least 80% of them come to us organically through referrals from colleagues and friends.

When you start out and want users on your product, it is very hard to not fall into the trap of wanting to scale too early. Going to potential (and often irrelevant) users one by one feels too slow. This often leads to a path of trying to find resellers, spending time on PR and working on scalable social media strategies. While those things feel good to do, I believe they are satisfying because you “feel” like you are doing what a startup should do, but often the most valuable activity is just talking to users one after the other, for extended periods of time.

What’s your business model, and how have you grown your revenue?

Our first two courses were paid for by our department. I was asked to name a price in the first meeting, and in a state of panic just threw out 5000 DKK per course per semester (around $750). This was accepted, and we kept that model for a while. Later we started doing larger deals (department-wide and university-wide), which gave our customers more courses at a discounted rate. Around 1–2 years after starting Peergrade, we decided to release a free version of our product, which meant that our sales immediately slowed down, but that our user growth accelerated.

Today we still have the free version and a paid version for individual users and institutions. Almost all of our revenue is coming from institutions, and we have recently added some corporate customers with a larger footprint in our revenue breakdown. We have managed to keep a revenue growth of around 12% month-over-month for the last two years. One of the most interesting things about our customers is that our total churn in 3 years is below 0.5% of revenue, indicating that our customers basically never churn once they are up and running with Peergrade. We have raised external capital twice and received some public grants. With the current amount of capital and growth, we will become profitable.

Whether to have a free version of your product or not is an old discussion with many arguments pointing in both directions. For us, I think it was important to have a free version due to the nature of educational software purchases (it is extremely slow, and the money is very tight compared to other markets). But it was equally important for us to prove (to ourselves, and to investors) that we could charge for the product. We have learned that if users like our product, we are able to charge the institution later. We have also learned that when an institution starts paying for Peergrade, they keep paying year after year. Based on these two things, we can comfortably run a freemium model backed by venture capital to grow faster.

What are your goals for the future?

While building Peergrade, we have collected and organized feedback from our users. Based on our database of more than 12,000 pieces of feedback, we are in the process of building a new version of Peergrade with a lot more functionality and with a wider appeal. We started this work recently, and hope to be able to launch something around summer 2019! The update we are building is not something that any individual customer has asked for, but the underlying solution to years of feedback and requests.

Making fundamental changes to your existing product is always hard. Customers depend on us to run their courses, teachers are training each other in using our product and some students use Peergrade very often. We owe it to our customers to provide them with a fantastic product, and we owe it to ourselves to build something we are truly proud of.

What are the biggest challenges you’ve faced and obstacles you’ve overcome? If you had to start over, what would you do differently?

One of the things we had to learn the hard way, was to hire when it was really needed, and not just when we had the money to do so. From the beginning, it was expected, both by ourselves and by our investors that we should hire salespeople to start scaling sales. Twice we made the mistake of hiring for sales too early and had to lay off people again. Laying people off that you recently hired is one of the worst things I have had to do. We also had periods where we had a lot of interns and part-time people employed in Peergrade, but always realized that the value added was not worth it compared to the cost and complexity of having more people.

If I could start over, I would spend a lot more time before making each hire, and always try to get away with fewer people for the job. When you are a young founder with a new company, you don’t feel like you have a lot to offer potential employees, but looking back I think we were a lot more attractive than we thought and could have been more selective in the early days.

Have you found anything particularly helpful or advantageous?

It should never be underestimated how big an advantage it is to be able to build something yourself. Being a technical founder of software companies is such a big advantage, that successful teams without technical founders are in my opinion all outliers. You don’t have to be a programming genius, but having the skills to launch something alone is incredibly effective in the early days.

Being a mathematician, I didn’t have any really strong foundational knowledge about building a company. I learned everything I know by reading books, reading blog posts and by talking to people. Before launching Peergrade, I moved into a co-living arrangement (Nest Copenhagen) with 20 entrepreneurial people. The network I became part of then has helped me countless times when I needed to write a founder agreement, find a good lawyer, meet investors etc.

Finally, going through Y Combinator in 2017 has been a huge advantage for us when it comes to fundraising, attracting talented employees and getting connected to thousands of smart founders.

What’s your advice for entrepreneurs who are just starting out?

Most if not all of the core beliefs I have about how to start a startup is taught in the YC curriculum (https://www.ycombinator.com/resources/). Almost every question I have ever received about entrepreneurship can be answered with a link to some resource in that library, and most of it with this blog post (https://blog.ycombinator.com/ycs-essential-startup-advice/). If you just follow that advice, everything will be fine.

The mistakes I continuously see people making is launching too late and trying to scale too quickly. I believe that both of these things relate to the same underlying challenge — some version of fearing to be rejected or proven wrong. The reason founders launch too late is because they are afraid that people will not like their product, and they keep this feeling away by not launching. The reason founders try to hire salespeople too early (we did this, twice) is because selling is uncomfortable, and getting told no hundreds of time sucks so hard. Building a business is hard, but you have to do it yourself — you can’t outsource the hardest and most important parts to employees or consultants.

Where can we go to learn more?

You can follow me personally on LinkedIn and Twitter. You can check out Peergrade at www.peergrade.io and follow our company account on Twitter.

I always love helping out new entrepreneurs, so if you have any questions, comments or requests, hit me up here below, on Twitter or send me an email at [email protected].

This interview is brought to you by OneUp, a tool to schedule and automatically repeat your posts on Facebook, Instagram, Twitter, Pinterest, LinkedIn, and Google My Business