Martin Bartlett

On my projects the Product Manager owned the roadmap: where the product was heading and why. I took a slice of that roadmap, broke it into features and stories, got it estimated and scheduled it into sprints. I've also done work that sits on the Product Manager side of the line, mainly discovery: running workshops, mapping how things work today, building the value case and recommending where to start. The titles matter less to me than being clear about who decides what.

I was a tester at an insurance software company when I was moved into a Product Owner role on its support stream. I already knew the product and what hurt customers, which helped. The first thing I did was suggest the team move from firefighting complaints to short sprints with a simple Kanban board, so developers had clear priorities and the Support Manager had one person to negotiate them with.

A global reinsurer wanted to use AI and had a list of candidate use cases. I ran workshops with their sponsors, project group, analyst and subject matter experts to map how each process works today, where it hurts and what it is worth. I took each one to our architects and senior developers to judge complexity, then presented everything back with a scored recommendation. The client chose one for a proof of concept, and it went on into production as a live reporting tool.

On one engagement the scope was already fixed in a statement of work, so the job wasn't to reprioritise it. It was to make it buildable. I turned each item into user stories with acceptance criteria, grouped them under features, took them through refinement and estimation, and scheduled sprints by complexity. I checked the work with the client's analysts, finance managers, project manager and sponsors at each stage, and dealt with scope changes as they came up.

I build Power BI reports on top of Azure DevOps data so people can see how delivery is really going, not just what the standard boards show. One example compares original estimates with actual delivery time using ticket timestamps, split by developers and testers. For steering committees I prepared the delivery section: throughput, story points against previous months and projections, costs and resourcing.

I bring the questions and let the experts do the analysis. When a client's security scan raised a set of alerts, our lead developer analysed them and I worked with him to separate the quick fixes from the ones that needed a major framework upgrade. I wrote up the recommendations and a costed proposal, with team make-up and rates, and handed it to our sales and account team.

At an aviation safety software company I was Product Owner for the features built into a large US airline's version of the product. One was in-flight report capture, so cabin crew could log incidents when they happened instead of waiting until they were back on the ground. The airline's safety office saw weekly submissions rise sharply within months of go-live.

I build it around what the support team needs, not around a changelog. For one handover I put together a pack and ran the session for first and second line support, covering what they would see reported and how to think about fixing it. I developed it with the lead developer, and both support teams and the client's stakeholders gave very positive feedback.

To speed up drafting. I've used Microsoft Copilot to turn statement of work items into user stories, and Claude to help with acceptance criteria and a support handover pack. I still own the result, because I know the client and the context. I've also completed three Anthropic certifications.

A Product Manager or Product Owner role, ideally remote or within reach of Bristol, where I can work from discovery through to delivery. I also enjoy mentoring: I regularly help junior colleagues and other Product Owners grow, including finding the right training.