Experience Report

Experiment with MVPs: the First “Startuppuccino” Steps to a Lean Edtech Startup

About this Publication

This experience report reflects on the first steps of a small software startup team, using Minimum Viable Products (MVPs) from the Lean Startup approach, blended with some agile practices, to experiment and validate their idea. The Startuppuccino experience reveals that MVPs play crucial and multiple roles in a startup life. To develop right MVPs to get validated learning, a startup needs to understand its unique value proposition. Neither could be achieved without continuous experimenting, reflecting and learning from the team.

1. INTRODUCTION

In the past several years, Lean Startup (Ries 2011) has become a prevailing approach applied by many startups. At the core of the approach is using build-measure-learn loops that allow a startup to quickly validate its business idea and to test different aspects of their business models, in order to acquire validated learning. As Ries argues, validated learning is the true measurement of the progress a startup makes (Ries 2011), especially at its early stage. Minimum Viable Products (MVPs) enable the team to conduct experiments and learn about the business and customer value with least effort, therefore it is important for startups to design proper MVPs in order to obtain validated learning. However, how to design MVPs so that a startup can learn the valuable lessons is a challenge for many early stage startups.

Startuppuccino is an educational platform that intends to help entrepreneurship educators to provide students with better learning experience with their courses. The team behind Startuppuccino intends to build an edtech (Education Technology) startup driven by this vision. The team intends to help entrepreneurship educators to understand if their students obtain true learning from their courses, which is the unique value proposition (UVP, Maurya 2012) of Startuppuccino. However to arrive at this UVP has not been an easy journey. To test it requires even more effort. In this process the team needs to constantly figure out what are the right MVPs to build, what is the validated learning the team wants to obtain through experimenting with MVPs, and where to look for opportunities to conduct experiments.

This experience report is yet another opportunity for the team to reflect and learn from its first steps as a small edtech startup, trying to navigate among many unclear assumptions and uncertainties and to figure out its own validated learning. The key lessons learnt are summarized and reflected upon.

2. Background

The journey of Startuppuccino started with the experience and observation of two team members who are university teachers. They teach together on a cross-faculty entrepreneurship course that intends to provide hands-on startup experience to students. Over several years of teaching and interaction with local startups, the two teachers have observed that there was a lack of support to early stage startups, especially student startup teams who badly need guidance and support on how to turn their ideas into concrete business. The initial idea of the teachers was to recommend good software tools to initiate and support startups that are missing key skills in their teams (e.g., design, web development).

After the discovery of several first-moving competitors and a revealing experience by participating in a local Startup Weekend event, the team discovered that early stage startups need to acquire basic knowledge about how to build a startup before they could realize what tools they need and how they can benefit from them. Based on this realization, the team decided to pivot to providing direct guidance to entrepreneurs by connecting them to a pool of mentors. However, the team proceeded very slowly towards this identified direction. No real development activity commenced. One key reason was that none of the team members had experience of community building, and the team was not in a position to do it since it required rich connections with local ecosystem players.

After several brainstorming sessions and realignment of the visions of different members, the team decided to focus on one thing that the team knew well and knew what potential pain points they could tackle: bring active learning to student entrepreneurs through better supporting the work of educators. This is the new direction that the team has committed to and has been working on since March 2016. Here is where the journey of Startuppuccino really starts.

3. JUST-IN-TIME DEVELOPMENT OF THE MINIMUM VIABLE PLATFORM

In the next several months following the discovery of the new direction, the team had intensive brainstorming sessions to share the new vision and to figure out how to start again in a lean manner. Customer journey mapping, a tool from Design Thinking, has been applied with the two teachers to get the understanding of the scope and initial set of requirements. However, the project was somehow stagnant, and no significant and exciting progress has been made. The team needed a push to make significant progress, and soon realized that there was one coming soon. In October 2016, the two teachers would start teaching the new edition of the entrepreneurial course. It would be a real and optimal opportunity to start the experiment of our idea. At that moment, the team believed that a concierge MVP (Ries 2011) is a correct way to go forward.  The two teachers would be the chosen customers and the team would gain a better understanding of the problem Startuppuccino intends to tackle as well as the solution it could offer. Figure 1 is a screenshot of Startuppuccino website that illustrates the concierge MVP concept.


Figure 1
: The concierge MVP of Startuppuccino

To implement the concierge MVP, the team needed to build a minimum viable platform to be able to gather feedback from students. The assumption the team made was that, even though educators were the intended customers, students have to see value in the platform and be willing to use it before educators can benefit from it. However, the team had to speed up the initial development of the platform in order to start the build-measure-learn loops. There were two choices: 1) develop very intensively during the summer and have a running platform ready to use in the beginning of the course; or 2) take a more step-wise approach and develop the application along the course. Partially due to the limited development resources and time the team has, but more importantly due to the conviction the team has on developing in an agile and lean manner to avoid waste in developing something that is not going to be useful for the users, the team decided to go with the second choice.

Since the course had weekly sessions, the team adopted weekly iterations too. In order to decide what to be developed in each iteration and to prioritize the tasks, the argument of developing MVP has been used extensively. The team members constantly reminded each other that we were developing a minimum viable platform that should allow us to understand if students would use such a platform with the support of educators. Any addition of the new functionality was evaluated using the criteria of minimum and viable. In addition, the developers and the teachers were sitting in the same office space. The teachers played the onsite customer role and constantly discussed about what should be developed with the developers.

One decision made purposefully by the team that reflects the team’s understanding of MVP is not to develop the graphical user interface for educators, despite the shared understanding that they would be the paying customers of Startuppuccino. The teachers from the team modified database tables directly when certain changes were needed from the perspective of educators.

This just-in-time but intensive manner of development put much pressure on the developers to deliver the working functionality needed for each week. However, the benefit is visible too. The team get immediate feedback from the students and other intended users (e.g., mentors that support student projects) on the developed functionality, and if and what to develop more in the following week.

4. CONTINUOUS EXPERIMENTATION GUIDED BY THE UNIQUE VALUE PROPOSITION

The intensive development of the minimum viable product gave the team a sense of achievement and satisfaction. However, it also obscured the team’s vision of a more crucial aspect of the startup: what are the value propositions (Osterwalder and Pigneur 2010) that the platform provides to the users and customers? How unique are they (Maurya 2012)? How are we different from other existing platforms to support entrepreneurship courses?

In the middle of the course in November 2016, after the prototype development came into a stable stage, the team had the opportunity to support another course in another university, even though it was not an entrepreneurship course per se. The team failed to support this course due to the limited capacity at that moment. However, a big debate happened within the team as to whether we should support non-entrepreneurship courses, which turned out to be crucial for the team to question what were the unique value propositions of Startuppuccino. Several brainstorming sessions were dedicated to answer this question. Eventually the team agreed that providing the visibility of the learning of the student teams to the educators is the unique value proposition that we should focus on. This UVP became the compass that guided the subsequent development of Startuppuccino.

With this new understanding, the team realized that we needed to design new MVPs to find the answers to two key questions: 1) how to capture the learning from students, and 2) how to make it visible to educators.

Right from the beginning the team knew that, for entrepreneurship courses which generally have a prevalence of practical activities, a “learning by doing” style, conventional intermediate and final exams are not the appropriate devices to capture the true learning that students could achieve. The teachers of the course borrowed the practice of retrospectives from agile methods. As in the previous editions of the course, between November and December each student team has been required to attend a private retrospective session with the teaching staff, and another session at the end of the course. Originally the main goal of the retrospectives was for the teachers to get a clear idea on the status of all projects. Soon the Startuppuccino team realized that it could be a good occasion for the teachers to understand if the students have learnt properly. However, several drawbacks of this approach also emerged. Since there were only two retrospective sessions over the period of a semester (about four months), the students tended to forget what happened to their projects. Meanwhile, it was time consuming and resource intensive for the teachers to run retrospective sessions with all student teams (10 to 15 teams), even if they happened only twice per semester. Based on this observation, the Startuppuccino team realized that a feature that can support continuous retrospectives of student teams by themselves would achieve the goal of capturing learning more accurately, and save the time and energy of educators.

In order to act quickly (half semester has already passed), the team applied the concept of “piecemeal MVP” from the Lean Startup approach, Rather than developing a native form in the platform, which takes more time, the team quickly designed a Google form, which allowed us to test what should be collected from the students and how to collect them. This form has been our MVP to validate the risky assumptions that “educators can evaluate the learning of students with the information collected by the form”, and “students are able to interpret and provide valuable information through the questions asked in the form”. After being instructed on how to use the form, the students had not been forced to fill the form. In the end we collected only few answers, and even less were those with valuable content that can give a good visibility of the students’ learning to educators. The experiment result with the Google form MVP was not positive, but it still offered some validated learning. The team realized that, in order to gather the learning from students regularly, a form only may not be sufficient.

Meantime, to understand how to visualize the learning has proven to be even more difficult. The team went back to the retrospective charts drawn by the students from the previous courses. However, since the teachers have been giving students instructions on how to draw the retrospective charts (e.g., draw a timeline of what happened), the team was not sure if this was really the correct way to visualize the learning. In order to experiment on the visualization part, when the current edition of the course ended in late January 2017, the Startuppuccino team did final retrospectives with each student team, and left open to the students to illustrate their learning on flipcharts. After all charts were drawn, the team analyzed them collectively to identify common elements and to evaluate their effectiveness of representing learning. One main validation from this experiment was that the majority of the student teams did actually follow a timeline flow even when they were left open to draw their learning in any format. We also asked the members of the Startuppuccino team that were less exposed to the course to interpret the charts, to see which ones were easier for them to understand the project and learning points. The charts that followed a timeline were easier to interpret.

At this point, the team started to design the learning chart and its components that would be eventually implemented in the Startuppuccino platform. In order to implement this part in a lean manner, we needed new opportunities to experiment the solution. Since we were running out of time and students, we decided to consider our own startup experience with Startuppuccino in order to test our design of “collection and visualization of the learning”. Mockup MVP is the device we used to experiment the solution. We used flipchart with post-it notes to simulate the interface of online learning chart. As a result, we created our own learning chart (see Figure 2).

Note: Post-it notes with green text – What happened; Post-it notes with red text – What we have learnt

Figure 2: The Startuppuccino Learning Chart

At the end of this experiment all the team members were satisfied with the experience and the general feeling was a happy surprise from the work and achievement we obtained. The feeling of being surprised was due to the memory of many crucial events forgotten by any single team member. The experiment on ourselves showed us the value of having a place, in this case the A1-sized flipchart, to collect all the information, and the need for collaboration of all the team members to build the learning chart. It also led us to the realization that the Google form MVP could be useful only in the context of team retrospectives.

However, we were aware of the limitation of this experiment using our own experience, and the possibility of biases. Moreover, it was a one-off rather than continuous retrospective intended by our solution. This was the reason why we looked for more opportunities to run the full experiment. A new opportunity came along when two team members were invited to run a one-week intensive Lean Startup course in a large university in early March 2017. At the end of each day, the students were asked to conduct the retrospective and provide the learning using the Mockup MVP we provided. We observed how the students used the Mockup MVP to create their learning chart, if they followed our instruction, and collected the feedback from them. The result experience was positive, and allowed us to learn about more detailed aspects of our solution. One main validation came from two students who were professors in another institute. They found the learning chart was very good way to understand students’ learning, and told us that they would go back to try with their students!

Based on the learning from this set of experiments guided by the UVP, the Startuppuccino team will focus on delivering the online learning chart in the coming months.

5. WHAT WE LEARNED

Insight A: Focus on what the team knows the best, and acquire the new knowledge along the way.

Originally we wanted to build a community supported by an online platform, which could connect early stage startup companies and entrepreneurs with the resources and guidance they need. However, community building demands the expertise that the team did not have and were not familiar with. As a consequence, the team moved slowly and lacked momentum to make real progress. After pivoting to the idea of building an active learning environment to support educators to better serve student entrepreneurs, the team found their home ground. Two key members of the team are educators themselves. They run entrepreneurial courses and know what students like and do not like about the courses. The pain points that the team targets at are the pain points felt by them directly. Starting with what the team knows best, we could quickly identify where and how to proceed in a more confident manner.

Insight B: Need for a strong business driver.

The experience of developing the minimum viable platform described in Section 3 made us realize the need and effectiveness of having a strong business driver. Even though we decided and started with what we knew the best, the speed of the development still suffered until we had identified one business case, which was to support the upcoming entrepreneurship course. The course provided a sense of real business and urgency, which put the team into real action and motivated us to produce tangible results. The two educators acted as super early adopter of the idea and onsite customer of the solution development, and provided continuous drive for the team to push the idea forward.

Insight C: Obtain unique value proposition along the way.

In retrospect, the main purpose of the concierge MVP we created was to start the learning loop. It was developed without a good understanding of what the unique value proposition of our startup was. However, it does not mean the effort of developing the minimum viable platform was a waste. We would not have been able to achieve the understanding of our UVP without doing it. In this sense, you get your unique value proposition not upfront, but along the way of continuous experimentation. A clearly identified UVP provide a good target and guidance for experiments with MVPs. After we understood what our UVP is, we had been able to utilize all the possible opportunities we could grab to conduct a set of experiments, with a set of MVPs.

Insight D: Grab any opportunity or create it yourself to experiment with MVPs.

We utilized different MVPs to conduct the experiments that allow us to obtain validated learning on our business idea before investing significantly to develop the full solution. We started with the concierge MVP with the support of a minimum viable platform that we developed in a just-in-time manner with the help of several agile practices. We learnt the value in piecemeal delivery that allowed us to obtain constant feedback and adjust our course accordingly. In addition, as a small startup with limited resources, we need to seize every possible opportunity, and even proactively create new opportunities, in order to conduct the experiments with MVPs that allow us to obtain validated learning. We need to experiment, reflect and learn in a continuous manner. Validated learning is the true measurement of the progress of a early stage startup, and you would not be able to obtain validated learning without experimenting and reflecting constantly!

Acknowledgement

We would like to thank the shepherd of our experience report, Lise Hvatum, for her careful review, valuable recommendations and timely push. Without her help, we couldn’t have made to the end of this learning journey.

REFERENCES

[Maurya 2012] Maurya, Ash “Why Lean Canvas vs Business Model Canvas?” https://blog.leanstack.com/why-lean-canvas-vs-business-model-canvas-af62c0f250f0 [last access date: 08-04-2017]

[Osterwalder and Pigneur 2010] Osterwalder, Alexander and Pigneur, Yves “Business Model Generation: A Handbook for Visionaries, Game Changers, and Challengers. A handbook for visionaries, game changers, and challengers.” John Wiley & Sons, Inc., 2010.

[Ries 2011] Ries, Eric “The Lean Startup: How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses.” Crown Publishing Group (USA), 2011.

Add to Bookmarks Remove Bookmark
Add to Bookmarks Remove from Bookmarks
Add to Bookmarks Remove from Bookmarks
XP 2017

Your Bookmarks

No favorites to display. You must have cookies enabled to add bookmarks.

Have a comment? Join the conversation

Related Agile Experience Reports

Discover the many benefits of membership

Your membership enables Agile Alliance to offer a wealth of first-rate resources, present renowned international events, support global community groups, and more — all geared toward helping Agile practitioners reach their full potential and deliver innovative, Agile solutions.

Not yet a member? Sign up now