Product Manager.

I led the product from inception through to live operation, working directly with the management team on the original concept, then spending time with the people who’d actually use the software, rail controllers, to understand their day-to-day problems, workflows and constraints. I turned this into user stories and requirement specs, then worked with our designers to build prototypes that went back in front of users for feedback. This research-build-test loop ran continuously throughout the project.

In parallel, I worked with the dev team on how to structure the underlying rail data: UK rail data is notoriously inconsistent. So a large part of this was manual analysis to understand it well enough to know how it should be displayed. I worked with engineering and design to translate that into a usable interface, ran extensive validation to make sure real-time data was accurate, and led the digitisation of several manual, paper-based processes that were still standard practice in the industry.

The software integrates with CEIS. An expert system with a machine learning layer that helps generate automated disruption plans and passenger communications, I worked closely with the team building this to make sure the two systems worked together for the end user.

Post-launch, I stayed closely involved: ongoing maintenance, feature updates driven by user feedback, and regular time in the control room to see the product in use and spot what needed improving.

Impact:

• Reduced decision-making time for controllers by 5 minutes per decision
• Contributed to a £100k reduction in Delay Repay costs

Team:

• Internal: 4 developers, 1 designer (small in-house team, working directly alongside me)
• External/wider stakeholders: 15 control room staff, 8-person management team, plus a research partnership with UEA on the CEIS system

I led this product from discovery through to launch, working with station and platform staff, the people who’d use the app day to day, to understand how they support passengers on the ground: what questions they get asked most, where they currently have no good way to answer them, and the constraints of using a device while working a platform or gate line. I turned this into user stories and specs, then worked with designers to prototype the app and test it directly with staff before building it out.

The app covers journey planning, ticket prices, a live train map, live departures and disruption information, all designed to be usable quickly in a live, often noisy environment rather than sat at a desk. We built a custom content management system so management staff could keep that information current to their staff, which meant thinking through the handoff between the people updating information and the people using it on the platform.

As with my other rail projects, I ran a continuous research-build-test loop: prototypes went back in front of frontline staff regularly, and their feedback shaped what made it into each release. I also worked closely with the wider technical and design teams to validate real-time data feeds so the information shown to staff (and by extension, passengers) was accurate.

Impact:

• 300K+ passenger journeys assisted through the app
• Reduced average time per staff interaction by 3 minutes

Team:

• Internal: 5-8 people (small in-house team I worked with directly)
• External/wider stakeholders: 18-person team, spanning engineering, design and station operations

Northern’s driving staff got safety bulletins, union notices, speed restrictions and compliance updates via paper boards in depots, with no reliable way to confirm who had actually seen them. I was responsible for the design and delivery of an Android app that replaced those boards with screens in the depot, working with depot and safety teams to define the notice types and how staff would sign in and confirm each one had been read.

Staff sign in using NFC, and each notice has to be opened and marked as read before it can be dismissed, which creates a record of acknowledgement that didn’t exist digitally before. A lot of the early work was in conversations with safety teams about what “read” should mean for different notice types, and with depot staff about how the sign-in flow needed to fit around a shift pattern where people are moving in and out of the depot constantly.

As with the other projects, I ran discovery and spec work myself, then worked closely with design and engineering through build and rollout, testing directly with depot staff before wider release. Stakeholder alignment here meant balancing a small in-house build team against the operational and safety priorities of a much larger depot workforce.

Before this project, on-the-day changes to train plans, delays, cancellations, platform alterations, were communicated to customers and staff through separate systems, often at different times, so the two audiences weren’t always hearing the same thing. CEIS is a single system for communicating revised plans and timetables consistently to both, across every channel, in a simple and plain way.

The system integrates directly with the Decision Support tool, the same expert system with a machine learning layer that generates automated disruption plans. When a plan changes at the decision-support level, that change flows straight through into what customers and staff at SWR see, so the two systems and the people relying on them stay in sync. My focus was on the handoff points in that process: where a plan changes, who is notified first, and in what order the information reaches each audience.

This project involved a similarly small in-house team working alongside a larger external delivery group, and close alignment with SWR’s operations and customer experience stakeholders to agree what “consistent” should actually look like across channels.

The dashboard was built to catch a specific problem that isn’t visible from the timetable alone: more than one cancelled service in a row at the same stop. SID measures the real-time gap between services at each stop across the network and compares it to the timetable, alerting customer experience and control room staff as soon as that pattern appears, running on both mobile and desktop so it’s usable wherever staff are working.

The design work was about separating this specific pattern out from the wider noise of individual delay and cancellation alerts, so staff could act on the thing that actually affects a passenger standing on a platform, a run of no trains, rather than getting lost in every minor timetable variance.

I ran discovery with control room and customer experience staff to confirm this was the right pattern to surface, then worked with design and engineering to build and test the alerting logic.

Train arrival data and platform announcements for the same service hadn’t previously been compared directly, so there was no reliable way to check whether a change had actually been communicated to passengers before it happened. CIS pulls arrival times from two sources, Darwin and TRUST, and compares them against the platform audio announcement for each service, to check whether a change was communicated before the train’s original scheduled arrival time.

Much of the work was in reconciling two data sources that don’t always agree with each other, while keeping the comparison focused on the thing that actually mattered: whether the announcement happened in time, not just the discrepancy between the two feeds. That meant working closely with data and engineering teams to understand where and why Darwin and TRUST diverge before building the comparison logic around it.