Mobility builders: find a real operating problem worth solving

A delayed handover, an uncertain vehicle status or a support request that keeps returning can be a better starting point than a broad ambition to transform mobility. The useful question is what repeatedly makes a particular job harder, for whom, and under which conditions. Before designing a product, find out how people currently get that job done.

That is a useful starting point for a conversation with Sparrow Mobility Labs: a specific operating problem, the people affected and what a builder wants to learn through access to real work.

Follow the problem through one working day

Describe a recent occurrence from beginning to end. Identify the trigger, the first person who notices, the information they have and the next action they take. Record where the process pauses and what finally moves it forward. A problem described only as “poor visibility” leaves too much room for different interpretations.

Ask whether the difficulty occurs every day, only during a busy window or when an unusual event happens. Keep reported experience separate from records you have inspected. A compelling account can justify investigation without establishing how common the issue is.

Find the decision that could change

Several people may experience the same interruption differently. A Captain needs to know whether to wait; a coordinator needs an available vehicle; a workshop needs approval to begin. Establish whose decision the proposed tool should improve, and whether that person has the authority to act on its output.

The OECD/Eurostat Oslo Manual distinguishes an implemented innovation from an idea or prototype. That distinction encourages a practical question: where would a change enter everyday use? A functioning demonstration matters less if nobody can use it to make the next decision.

Test the smallest useful assumption

Write down the assumption that would make the idea worth pursuing. Perhaps a clearer handover could prevent repeated calls, or an earlier maintenance signal could help a coordinator arrange support. Choose one assumption first. Avoid asking an initial test to prove demand, usability, commercial viability and long-term impact at once.

Agree what would count as evidence against the idea as well as evidence for it. If the existing process works adequately, or the proposed change adds more effort than it removes, the team should be able to recognise that without redefining success.

For example, a fictional handover problem could be written as: “When the evening coordinator takes over, a vehicle is marked ready without the time or person who checked it, so the coordinator calls again before assigning it.” A first test could add the check time and responsible role to the handover. If repeat calls remain because the physical condition is still uncertain, the record change has not solved the problem. That result would narrow the next question rather than justify adding more fields.

Bring a brief people can challenge

A useful brief names the setting, the current process, the affected people, the proposed change and the observation period. Include what access is needed and what work participants would have to do. The fleet operating context can help clarify the responsibilities around a vehicle before a builder proposes a new layer of software.

Leave space for the operating team to disagree with the problem statement. Their response may narrow the test, reveal a dependency or point to a simpler change. That is valuable progress before anyone commits time to building.