These are the practices I favour when running a product or business systems function. They reflect my experience of owning roadmaps, setting process standards and looking after products over time.
01 / Requests
One route into the work.
I prefer requests to come through one place. Otherwise, it’s too easy for work to be agreed in a meeting or a message without anyone seeing what else the team has committed to.
A request needs to explain the problem, who it affects and what the business needs to achieve. If there’s a deadline, I want to understand what’s behind it. I wouldn’t expect the requester to write a technical specification; working out the requirement is part of our job.
Someone needs to review the request, ask any questions and let the requester know what happens next. Capturing it is the start of a discussion, rather than a promise of delivery.
02 / Priorities
One roadmap for the function.
I want one overall roadmap that the work feeds into. Teams can have their own backlogs, but we need a common view of priorities and commitments.
That includes maintenance, defects and improvements to existing products, as well as new work. The roadmap should show what the function is responsible for, rather than just the next set of launches.
Priorities need to be agreed with the business. If urgent work comes in, we should explain what it will displace. A new commitment doesn’t create more capacity.
03 / Process mapping
Map what actually happens.
I use process mapping to understand how the work is done before deciding what needs to change. I want the people doing it involved, including the teams on either side of a handover.
The exceptions and workarounds matter. They often explain why a process that looks straightforward on paper is difficult in practice.
I favour a consistent way of capturing processes so people can read and use maps produced by different teams. The level of detail depends on the decision we’re making. Once the process changes, the map needs to change too.
04 / Delivery
Keep people involved.
The conversation shouldn’t stop once a request reaches the backlog. I want the people who will use the change involved in clarifying requirements, reviewing it and testing it.
People should be able to find out where their request stands and why. If we decide against it, or the priority changes, they deserve an explanation.
After release, I want to know whether we addressed the original problem. Adoption and feedback tell us things that a completed ticket won’t.
05 / Adoption and change
Agree the starting point.
Adoption needs to be considered before we build or change a system. I want the teams involved to agree the baseline process: how the work is done today, where the problems are and what we’re proposing to change.
We also need to agree the key performance indicators (KPIs) and establish the baseline figures. Depending on the work, those might include system usage, processing time, errors or the amount of manual work involved. The measures need to tell us whether the change is helping.
People need to understand the new process and have a chance to test it before release. Afterwards, I want to review the agreed measures and hear from the people using it. If adoption is low, we need to understand why and act on it.
At Indigo Ag, my Salesforce improvement work increased adoption from approximately 40% to 90%. That’s an outcome worth measuring alongside whether the software was delivered.
06 / AI
Be clear about what AI is there to do.
I see AI as part of the product and systems roadmap. A proposal needs a clear use case, an owner and a way of assessing whether it helps.
The process baseline and KPIs matter here too. We should know what the work involves today before deciding where AI could help, and agree how we’ll compare the results. A useful pilot needs to test the quality of the output as well as any time saved.
I’d also want to understand what data it uses, where someone needs to check its work and how mistakes will be handled. My experience includes participating in a Salesforce Agentforce pilot for common support cases.
If a pilot proves useful, the next step is to plan how it will be supported and improved in normal use.
07 / Ownership
Keep looking after the product.
Launching a product is only part of the responsibility. It will need maintenance, changes and improvements as the business and its requirements develop.
At iPrism, that meant adding and maintaining a portfolio of more than 50 insurance products. That experience is one reason I see ongoing ownership as a core part of the function’s work.
There needs to be a clear owner after release, and time in the plan to look after what we already run.
Contact
I’m interested in director-level technology and product roles.