The software development process at 123onsites – an insight into our philosophy
How do software developers judge the success of their work? When is the software development process of an app successful and how can developers assess this? David Künnen, Head of Product Management at 123onsite, explains that while customers usually already have solution suggestions ready when they have software requests, the developers at 123onsite sometimes take the unconventional route via the construction site to find the best solution.
A cold, windy day, the sun shines only now and then between gray clouds. The path across the construction site leads over large puddles, the wind whistles through the windows of the shell. A lively conversation with foreman and employees – one keeps pointing to his smartphone. It’s down to the nitty-gritty, here on the construction site we’re talking straight, no one minces words. Today, it’s all about feedback from the field on the new app. Just another day at work – for our software developers.
Our software experts go where they see the software in action and get direct feedback from users.
That’s why we work not only in an office at the screen, but also on the construction site. The working day of our software developers can therefore also start outside. Because 123onsites develops construction site software for and together with people on the construction site. For example, we have done it at the
Matthäi company
made. The construction company had invited us to a highway construction site so that we could speak directly with the foremen. The foremen showed us how they work with their app. There we could just dive into the action and see the handling in practice. Not from the office, but live on site.
A demanding work environment needs perfectly fitting software solutions
The direct impression is important, because the work in the construction industry is often very complex. Therefore, software vendors need to understand and respond to users’ needs. That’s why we at 123onsites are in close contact with companies that use our software. Of course, this is done in the classical way via the Support and our Professional Service is also in contact with customers. Employees in product management also work closely with customers.
But the Matthäi example shows that our colleagues also go directly to the construction site to experience the software in action and talk to employees.
We closely analyze the feedback on the software
If customers then want an improvement in the planning, for example, we have an initial indication of what the issue is – and we know the requirements on the construction site. Because the office and the construction site are often different worlds. We analyze the feedback and also the user behavior. In most cases, customers already provide a solution suggestion with their feedback. You say something like, “We want to have a button where we can export our times in a certain way.”
Our product management then takes a step back and knocks off the five “whys.”
We ask: Why do you want to have a button that exports times to you? The customer then answers, for example: Because the evaluation is otherwise difficult. We ask again: Why is the evaluation otherwise difficult? Perhaps the answer is: Because we lack a list of times in this form so far. And so it goes on with the five whys until we come to the real problem at the end.
This is important for us, because we need to know: What does our customer actually want to solve? For us, it is important to identify this pain point. Sometimes we already have a solution for exactly this pain point that the customer just hasn’t found yet. Then it is simple. If, on the other hand, there is still no solution, then we consider how to arrive at one.
The goal in the software development process must always fit the product as well
Our product management knows: Everything we implement in the software development process must also fit the product. It should be a feature that is interesting for many customers, so that the product has added value . And it should not complicate the product. That’s why we are of course happy when customers bring the proposed solution to their problem right away – but we think things through thoroughly before we design the improvement.
We speak directly with customers who have reported a problem. We ask, “How would you like to see a solution?” We present our solution approach and ask for feedback. Then we test the solutions, let customers try out prototypes and ask for their opinion. This is how we approach this problem. This is our software development process at 123onsite.
THE 123ONSITE FEEDBACK FORUM
Customers have a first point of contact in our feedback forum. There you can find a collection of
FAQs
an
overview
and
new features
.
In the feedback forum, software users can also rate applications. This gives us a good indication of where the desires lie.
Our developers are in constant exchange with customers
Of course, customers can also write a classic e-mail. Then we ask if they are interested in exchanging ideas on a certain point. Because we want to find a good problem solution for it.
When it comes to exchange, we also try to bring the foreman into the conversation. To find a solution, we need to talk to people who work with the software directly on site. Because concrete feedback from the field leads to better and better products. And that’s what our customers want just as much as our developers.
Photo credits: 123onsite/Timo Lutz advertising photography; 123onsite
An article by
David Künnen
