MoveInSync · 2024–2025
One analytics suite for three transport products
Making operational numbers consistent, explainable, and useful.
My role Product ownership, customer discovery, SQL reporting and delivery
Context
Manufacturing customers used ETS Cab, Shuttle, and Rentlz, but their analytics lived in a separate catalogue of 100+ similarly named reports. Dashboard totals did not always agree with reports, and low performance numbers were hard to explain.
Decision
I brought the three offerings into a dedicated suite for the vertical. Every metric needed a consistent definition and a drilldown to the individual records behind it.
Outcome
The flagship client deployment established the suite, which reached 10+ enterprise customers on web and mobile. Operations teams could investigate low performance figures and improve data and operating practices. The clearer journey also helped demos and conversion.
Explanatory diagram based on my project account.
Evidence & scope
Customer reach is documented in my résumé. The decision, maintenance trade-off, and customer response come from my first-hand account. Demo and conversion improvements are qualitative.
A closer look
Open the parts you want to explore.
Why a dedicated suite?
ETS Cab handled dynamically routed home-to-office and office-to-home travel. Shuttle used fixed routes; Rentlz covered ad-hoc pickup and drop. Customers needed a shared operational view across these offerings, without finding their way through a general-purpose report catalogue.
The trade-off: consistency takes maintenance
Keeping the dashboard, reports and drilldowns aligned was extra work. I chose that investment because customers needed to trust the numbers before using them to change their operations. Low figures became useful once a team could trace them to specific records.
From a mismatch to something operations could use
The first customer problem was that dashboard metrics did not always match the reports, while low performance figures offered no route back to the underlying cause. In the dedicated suite, teams could follow a metric down to individual records, then improve data and operating practices with a clearer view of resource use.
The broader product work
The same manufacturing role included safety, attendance and distance logic, customer investigations, and Python/JavaScript utilities. A custom vendor-billing prototype was an example of shipping quickly around a platform gap. These were parts of the employer work, rather than separate portfolio projects.
The internal investigation tool
For the manufacturing vertical, I connected Jira, Amazon Redshift tables, and policy documentation via MCP. An LLM could query this context to help debug client feature flags and track engineering tickets.
Source notes
My project account and product/finance résumés. The diagram explains the information journey; it is not a product screenshot. Customer names and internal records are omitted.