Modern software like blink.it is primarily one thing for you as a user: Simple. Easy to use. Easy to understand. But behind "Software as a service" lies a lot of conceptual work. Product Owner David provides insight into the development of the learning platform blink.it - amidst customer wishes, prioritization, and vision.

About the person: David has been the Product Owner for the blink.it learning app since 2021. He acts as a communication bridge between management, the development team, and customers. His goal: To bring all wishes and requirements together to create the best possible blink.it for everyone!
Software is not just software. What are the biggest differences in a "Software as a service" concept like blink.it compared to traditional software?
Traditionally, software was released on CD or DVD. And the version that was on it had to fit. Nowadays, this has somewhat loosened; updates are possible. But what the customer installs on their PC is initially the final version of a software that the customer pays for once.
In contrast, software as a service is continuously developed and constantly improved in small steps. And unlike CD software, the customer doesn't install software but rather a browser and uses the software hosted on the provider's server. The software is available as an internet service for a rental fee.
Classic Software | Software-as-a-service, e.g., blink.it |
The software is installed | A browser is installed |
Software available on the computer | Software available via browser on the provider's server |
A relatively fixed version | Is continuously developed |
One-time payment upon purchase | Monthly or annual fee |
What are the biggest challenges for you as a Product Owner in the development of blink.it as a Software-as-a-service?
The first challenge arises from the very nature: The software must run on all possible browsers. These browsers are also continuously developed, so the software must be constantly adjusted to ensure everything works. It's similar with the services running on the server. Everything is constantly being developed by many parties. This requires ongoing development to remain compatible. However, this is mainly a challenge for the development team.
The second challenge, and essentially the first and greatest in my role, is the product vision. What do we actually want to achieve with the blink.it software? For example, a vision could be, “We want to make effective learning as easy as possible” or “The tool that connects online and in-person teaching most easily for all participants.” – The vision can also evolve over time in line with customer wishes.
The third challenge in the role as PO is the constant decision-making and prioritization: When should what be developed? And what impact does that have elsewhere? So many ideas and requests come in, both internally and from customers themselves. The decision FOR one development option is always also the decision AGAINST many others. The options are virtually endless. Every decision affects different people in very different ways.
How do you select the features that actually make it into the software?
This is where vision and prioritization meet: Of the many options available – which contribute the most now and in the future to helping as many users get closest to that goal? Additionally, a classic cost-benefit analysis is performed. Ideally, we want to take steps that provide the greatest benefit with the least effort.
The decision is never “yes” or “no,” but rather essentially “now” or “not now”. Just because a customer’s feature request is not implemented now does not mean it will never be. Perhaps just later. It can remain in the backlog, which is our large collection of ideas.
At the same time, it can also mean that an idea waits while new ideas continuously take precedence - “not now” can therefore also mean forever. This is not always easy to manage and often even more challenging to communicate. The goal is always: To do the most sensible thing now. Then we have made the best out of the possibilities.

This is how the selection of development options for the blink.it learning platform takes place. / Own representation
Some things are so essential for future developments that we must do them, even if they may not bring anything new right now. For example, the new design for blink.it that we are currently developing: It initially brings hardly any new features for customers. But with the new design, we are completely restructuring the underlying infrastructure, which customers don’t see at all. And this new structure is necessary for the many new functionalities in the future, and to be adaptable and develop with our vision!
Many wishes come in from customers to blink.it, as well as inquiries about why the implementation takes so long. What is the reason?
We receive great suggestions and wishes from our customers that I find very valuable! I would love to implement many of them right away. However, if we implemented them NOW, they would be running on the old infrastructure and in the old design. That would then block the development of the future.
So, unfortunately, we are currently putting many of these wishes on hold for the time being - as I said, they do not get lost. And we are first building the new foundation. THEN we can implement the wishes directly with the new technology. This also saves a lot of extra work in developing everything only to later adapt it completely for the new design.
"We are always looking for the 'Sweetspot' between effort, benefit, and vision."
And even then, prioritization is based again on benefit and effort. As mentioned, these are decisions in a complex environment. The goal is always to find the ideal balance, the “Sweetspot” between effort, benefit for customers, and product vision.
You say SaaS is developed in many small steps. How does a “small step” work at blink.it, and what makes it so complex?
First, we determine the specific goal for each idea that our users can achieve with it. This requires a lot of empathy. Together with designers and developers, I must understand and formulate exactly what the user wants to achieve. It is important to empathize with our customers and their everyday use of the software. Some of this we can resolve ourselves, and often we learn about it through follow-up questions.
With this goal in mind, we try to estimate what benefit it brings and what resources we need for it. Together, we try to assess the complexity. We compare different development options. Ultimately, prioritization is based on benefit and required resources. We then have a sequence in which we want to process the ideas.
"SaaS development is the combination of empathy for customers and technical know-how."
Finally, we discuss how many of these we can tackle in the next two weeks. A development interval, a “sprint,” spans two weeks for us.
With this goal formulation, we proceed to technical implementation. Developers and designers then collaborate on this. What is ready will be thoroughly tested: Does everything work in practice? Once that is ensured, the idea can be released as a finished feature for customers.

Every new idea goes through several process steps before it is released. / Own representation.
In some cases, like with the new design, the changes are not published immediately. Instead, the results from many “sprints” are bundled, and then made available to customers all at once on a specific day. It appears to customers as if we haven’t done anything for a long time. Of course, that is not true:
We are ALWAYS working on the platform. This bundling happens when many small things together deliver a rounded result for customers. Publishing a table at just one point in the platform could confuse users, for example. It can make sense to change tables at multiple locations simultaneously.
"To customers, everything looks kid-friendly and smooth. But the reality of software development is complex!"
Software is more than just writing code and publishing it. Alongside the software code for different components, the necessary infrastructure is also maintained. For example, the mechanisms that automatically start and stop servers based on current user loads to enable many simultaneous accesses. Ideally, users should see none of this! Users should have the flow in their own work without dealing with the complexity. No matter what happens in the background - it should be a simple experience.
This is the paradox of the matter: If we do it right, it looks childishly simple and very fast to customers. Understandably, it then creates the impression that there is nothing to it. However, the underlying aspects are often more complex than what is visible on the surface.