Machine learning is no longer just a buzzword—it is a powerful tool in product development when you pair it with clear use cases and high-quality data. In practice, I keep seeing the same lesson: the model is only as good as the data it is trained on. In this article I share how I apply ML in different products, from empathetic interaction in elderly care to smart navigation for heavy transport, and what I have learned about building and using training data.
Whether it is a robot that needs to communicate naturally with older adults or software that recognises roundabouts for truck routing: the same principles apply. In this blog I walk you through concrete applications, the role of training data, and some practical lessons that can help when you want to integrate machine learning into a product yourself.
Why machine learning in product development?
Products are getting smarter: they respond to behaviour, recognise patterns, and support users proactively. That requires more than fixed rules and if-then logic. Machine learning makes it possible to learn patterns from raw data—sensors, images, interactions—and make decisions that adapt to context. That is valuable in healthcare, logistics, industry, and consumer products.
The challenge is not building a model per se, but defining the right problem, gathering representative data, and translating model output into product behaviour. That is what this article is about: how to embed ML in real products and what works in practice.
Where ML really helps
- Pattern recognition in sensor data
- Natural, context-dependent interaction
- Automatic interpretation of images or environment
- Personalisation based on behaviour
- Prediction and decision support
What to watch for
- Quality and representativeness of data
- Definition of success and metrics
- Edge cases and safety
- Deployment on embedded or edge hardware
- Maintenance and retraining
Training data: the foundation of every good model
The main lesson I encounter project after project: training data is decisive. A clever algorithm with poor or biased data produces poor results. Good, annotated, representative data is what separates a prototype that “sometimes works” from a product that performs reliably in the real world.
That means thinking early about what data you need, how you collect it (in the field, with real users or conditions), and how you structure labels or feedback. Sometimes collecting and cleaning data is the heaviest part of the project—but it is also the most decisive. Invest time there; it pays off in model quality and less corrective work later.
Representativeness
Data must reflect the variation in the real world. Narrow datasets lead to models that only work in “ideal” conditions and fail in edge cases.
Label quality
Incorrect or inconsistent labels undermine learning. Clear annotation guidelines and, where useful, multiple annotators improve reliability.
Volume and iteration
An initial dataset is often not enough. Plan for repeated data rounds: collect more data where the model fails and retrain.
Example: an empathetic interaction model in elderly care
In a project for elderly care, I worked on a robot-style companion that supports older adults. The product already offered features such as reminders, simple games, and sensors for heart rate and movement patterns. The main challenge was not the hardware or sensors, but how the companion communicates with the user: in a way that feels natural and builds empathy, rather than rigid answers or scripted dialogues.
For that I designed and trained an interaction model with machine learning. The model learns from behaviour, context, and feedback when which tone, pace, and content are most appropriate. The goal was not to build “a chatbot”, but to align the companion’s communication with the user—so that the interaction becomes more human and supportive. Sensor data (heart rate, patterns, unusual behaviour) acts as extra input: the model can respond by communicating more calmly or by encouraging more activity, for example.
Here, the quality of the training data was crucial: examples of human conversations and desired responses in different situations, combined with domain knowledge of care and communication. Without that foundation the model would feel generic and less empathetic; with the right data, the interaction became noticeably more natural and better tailored to the end user.
Example: smart navigation for heavy transport
Another practical example is navigation for large trucks. Not every roundabout is suitable for every vehicle combination: dimensions, turning circle, and height determine whether a route is feasible. Manually mapping every roundabout is expensive and hard to keep up to date. So I developed a solution that uses satellite imagery to automatically detect roundabouts, estimate their dimensions, and assess whether a given truck can use that roundabout.
The system combines computer vision and machine learning: it detects roundabouts in imagery, extracts geometric features, and links them to vehicle specifications. Navigation routing can then be adapted—so drivers only get routes that are actually passable. Here too training data was essential: enough examples of roundabouts in different environments, with correct dimensions and labels, so the model generalises to new locations.
This example shows that ML in product development is not only about “talking” or “behaviour”: it can also solve very concrete spatial and logistical problems, as long as the data and the definition of success are clear.
Practical lessons and next steps
Based on these and other projects, I would pass on the following when you want to use machine learning in a product:
Start with the problem and the data
Define what “good” behaviour is and what data you need for it. Only then choose architecture and tools.
Invest in training data
Plan time and budget for collecting, cleaning, and annotating. This is often the bottleneck and the biggest quality driver.
Test in real context
Models that perform well on test sets can disappoint in the field. Validate with real users or in the real environment.
Consider edge cases and safety
Especially in care and mobility: what if the model is uncertain or wrong? Build in fallbacks and human override where needed.
Machine learning in product development is not magic—it is about defining the problem well, gathering the right data, and iterating. With that approach you can build products that are genuinely smarter and more user-friendly.
Do you have questions about applying machine learning in your product or want to discuss data and use cases? Feel free to get in touch. I am happy to think along about how to apply ML in a practical and responsible way in product development.