The situation
Vehicle maintenance is something people know they should track and consistently don’t, until something breaks. Service dates get missed, fuel patterns go unnoticed, and owners managing more than one vehicle have no system at all. The real obstacle wasn’t that owners didn’t know they should keep up with maintenance; it was how much friction stood between knowing and actually doing it. The existing tools were either too complex or too generic to stick.
What I was brought in to do
Own the product as Product Owner inside an Agile Scrum team, defining what got built, in what order, and to what standard, over four months and to a production-ready state.
What I built
I owned the backlog from day one, which covered the user stories, acceptance criteria, sprint prioritisation, and continuous refinement.
The app shipped supporting up to five vehicles per user, with maintenance reminders, mileage and fuel usage tracking, vehicle performance metrics, and a built-in traffic signs guide for safer driving awareness. I evaluated each feature against a single question: does this reduce friction for a vehicle owner, or does it add to it?
The multi-vehicle design needed careful data work, because users had to switch between vehicles cleanly while each vehicle’s history and reminders stayed completely separate. That structure was defined in the backlog before any development started.
QA cycles ran against real usage scenarios rather than only against feature checklists.
The result
I delivered a production-ready vehicle management app in four months. Users could manage multiple vehicles, track maintenance proactively, and stay ahead of their service schedules without much effort.