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.

In the Royal Navy. From 1990 to 1996 it trained me as a weapons engineer, then sent me to sea on four ships, keeping radars, communications and a 4.5-inch gun working, from the South China Sea to the Persian Gulf.

It taught me to work to a standard, to plan around live operations, to find faults for myself, and to commit to a decision once it’s made. I use all four every week as a Product Owner, along with something I learned later: asking “are you sure?” before I commit. Testing, product work and plenty of certifications have built on that since.

Royal Navy: my university

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.

At a regulated professional body I was Account Manager and Product Owner on a programme to move their legacy on-premises reporting to a cloud BI platform on Azure: a data lake, Synapse Analytics and Power BI. The tricky part was that their own legacy systems were being migrated on separate upgrade paths at the same time, so we were building on ground that was still moving. They also needed cloud expertise they didn't have in house.

Our data architect led the technical design, customising Microsoft's accelerators to their infrastructure and lining them up with the identity and access set-up they already had. My job was to keep the client's project manager and stakeholders close: turning choices about data, governance and quality into decisions they could make, and keeping senior people informed with regular summaries that linked progress to the decisions and risks in front of them.

What I took from it: trust in data is as important as the trust you have in the people who give it to you.

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.

The work I enjoy most is where large amounts of data help people make better decisions about something that really matters. Two examples stand out.

At a global reinsurer I led the discovery work on an AI programme. The workshops covered how portfolios of commercial business are risk assessed, and the geospatial data available for judging each business's exposure to natural disasters. I liked seeing how location data changes the way risk is understood, and turning that into options the client could compare and choose between.

Earlier, I was Product Owner on a data platform for a life sciences research company. It gave researchers access to extensive data on cancer treatments, so they could build stronger cases for future drug trials. It was satisfying to work on a product where better access to data supports better research.

They all have their merits and their challenges. Large companies usually have a solid roadmap that fits their own commercial direction and ethos. Consultancies offer a huge variety of work across different clients, which is interesting and rewarding.

If you ask my head, either of those is a sound choice. My heart is with smaller, founder-led companies: teams that commit to a goal, are happy to fail fast, and build disruptive software to beat their competitors, not just keep up with them.

Not always, no. My longest engagement ran for more than four years, from 2021 to 2025, as Senior Product Owner on a clinical data platform for a life sciences research data company in London. Before that I owned the consultancy’s own in-house data science platform.

From mid 2025 I worked with several clients in parallel, for between five and eight months each, which is the nature of consultancy. I enjoyed both. The long engagement let me see a product grow over years and help the client’s team grow with it, and the shorter ones taught me to land quickly and earn trust fast.

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.

I think AI is hugely powerful, and often misunderstood. Some people expect it to do everything, and others don’t trust it at all. In my experience the biggest wins come when it’s pointed at a real, specific pain.

At a global reinsurer, analysts had a tight window to review large portfolios of claims. We built a tool that flagged claims that looked under-reserved, explained why in plain language, and left the final call with a person. Analysts could review several portfolios in the time one used to take, and it caught a claim that manual review had missed.

My job is to explain what AI can and can’t do in plain terms, find the problems where it genuinely helps, and make sure what we build solves the customer’s pain rather than just showing off the technology.

You don’t have to take my word for it. Managers, colleagues and people from the client side have written recommendations, and I’ve put them all on one page.

The things that come up most are that I bring clarity to complex problems, keep the end user in mind, help the people around me grow, and don’t shy away from the hard conversations when delivery gets difficult.

Read the testimonials

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.

I'm married to Emma, and we have a daughter, Beth, and too many dogs. Most of them are spaniels, and they tend to get involved in my calls and are my greatest cheerleaders.

We love our rather aged campervan and exploring parts of the UK. At home you'll usually find me trying to bake cakes or bread, repair watches I've bought, or listening to vinyl records and trying to re-capture my youth.