The discovery and design phase as the main component of product success

Quite recently, we delivered a project for one of our German clients, Inklusion Digital. Our task was to design and build an application for two groups of users: German teachers and students. Within the solutions provided, both groups had a common goal: to develop annual goals for students and verify their progress through feedback and self-reflection.

This is a fascinating example of an implementation in which we involved many different specialists; I had the pleasure of acting as the Product Owner of the entire idea. Today, I want to tell you the history of this whole project in several posts - so that you can understand the completed stages of the project, learn about the tools and practices... and learn from our mistakes.

We will start by analysing the discovery and design phases, allowing us to develop product design and UX tailored to users' needs.

In startups, the discovery and design phase is often overlooked and, as it later turns out, the most necessary. This stage of the product creation and development process aims to understand user problems, market needs, and technological possibilities. During this phase, the product team collects and analyses information to define the product's vision and determine its potential value and the risks associated with its implementation.

Suppose you are asking yourself what this is or are already answering this question by claiming that you do not see the relationship between the project's success and this phase. In that case, I will help you pragmatically out of this mistake.

According to the latest research by Nielsen Norman Group and MIT:

Product Discovery can help you lower the risk of failure by 75%.
Teams using Product Discovery report 83% 𝗼𝗳 𝗽𝗿𝗼𝗱𝘂𝗰𝘁 𝘀𝘂𝗰𝗰𝗲𝘀𝘀.
Discovery saves 50% of development rework time & 𝗰𝘂𝘁𝘀 𝗰𝗼𝘀𝘁𝘀 𝗯𝘆 33–50%.

The above information guided us and convinced us that it is worth investing money into the discovery phase, as the results at the delivery and launch stages can be much more profitable. Before we started the design phase, we decided to work with the client in several weekly sprints to understand the needs of our end users (teachers and students) and their most significant pain points. How did we do it?

Customer Journey - process mapping

We set out to build a tool for the German education market to digitize the existing manual process of creating and managing students' annual goals. Using customer journey mapping, we analyzed the current process in German schools and identified the associated challenges. The results exceeded our expectations—it became clear that goal cards are often lost or forgotten, and their current format needs to be updated and made more appealing. As a result, students are less motivated to achieve their goals.

We definitely obtained tips and information that—as it now turns out—were the core of building basic functionalities in both applications.

We have placed the map and all information in MIRO.

User Personas - who is our end-user?

In parallel to building the Customer Journey, we decided to deepen our knowledge about our potential users - teachers and students in Germany. We started from the level: we want to make applications for all children and teachers in Germany. We concluded that the needs and requirements for using different applications are different and depend, among others, on the age of children/teachers, the type of school, and the education regulations of a given Bundesland. And this is how we defined our end-users (in an extensive summary :)):

children and teenagers from various backgrounds, aged 10 to 16 (the most popular age group, we do not want to expose younger ones to technology), from secondary-level schools (business reasons for the client: gymnasium, Forderschule, Gesamtschule.. - the largest group of students)
teachers - of different ages (challenge here!), and secondary-level schools (the same as above). In addition to the specific characteristics of our users group - we have defined their key pain points, wishes and expectations in accordance to the build solutions.

Sample user personas template: https://miro.com/templates/personas/

Business Model Canvas + User Stories

What do we want to build, and what are its chances of success?

After completing work on the customer journey and user personas, we felt ready to define the scope of our new product—digital applications for teachers and students that will improve the process of achieving school goals—together with the client. We knew that:

We started developing a BMS and an Epic and User Stories outline. And we were like, wow - we create products tailored to the real needs of users! The Discovery Phase lasted about a month in total. After that, we started the design phase with full excitement.

Those needs were converted into user stories with a MoSCoW prioritisation. We ended up with two scopes of products: one for teachers and a second for students. Suddenly, we realised that we were creating products that truly meet user needs. The Discovery Phase lasted about two weeks, and we moved on to the design phase, which took about a month. Here, you can see the effects of the user stories slicing process: in the form of 2 maps in the Miro board.

The design was really smooth, primarily because of the great output from the discovery phase and the client’s involvement in the reviewing process. Teachers could expect a module as an add-on to the existing platform, and students would experience a separate app (independent of this platform). Teachers could, among other things, set annual goals together with students, leave feedback on progress, view results on an interactive chart, set a reward system and monitor students’ emotions. On the other hand, students carried out the self-assessment process, were recipients of rewards, collected points and shared their emotions. We have validated the design three times and, most of all - tested prototypes with teachers and students. We have received an enormous amount of input that has confirmed that we are ready for the development process.