Restructured a delivery-oriented team at Fortude and personally coached 5 project managers with no product background into product managers making their own prioritisation calls.
1. Context & Business Problem
Turn a delivery-oriented team into a product organisation that could make its own prioritisation calls, not just execute tickets.
When I joined Fortude, the team around the AI products looked like a delivery function: project managers running tickets rather than product people making prioritisation calls. Sprint planning was structured for output, not for learning, and delivery managers with no product background were making feature decisions with no shared method to reason through trade-offs.
2. My Role & Ownership
Alongside my product strategy remit, I owned restructuring the team itself. I ran 1:1s designed to surface problems early rather than just track task status, built KPIs tied to what each person needed to learn next, and personally coached five delivery project managers with no product background through the shift into product management.
3. Constraints
No headcount to hire experienced product managers externally, the team had to be grown from inside the existing delivery bench. People had built their careers around delivery metrics, so changing how they were evaluated had to be done without eroding trust. This had to happen alongside live roadmap work, not as a separate off-cycle initiative.
4. Discovery & Key Insights
1:1s revealed people could execute against a spec but had no shared method for deciding what to build next, whether to cut a feature, or how to defend a call with data. The team wasn't under-skilled, it was missing a common language and process for product thinking, the same gap I'd already closed once with a similar team at Sling Mobility.
5. Key Decisions
Restructured the team so it was organised around product ownership areas rather than delivery workstreams. Rebuilt KPIs around what each person was learning next, not just what they'd shipped that sprint. Introduced sprint planning and user-story formats adapted for product lifecycle decisions rather than single tickets, and a defined way to weigh feature trade-offs.
6. The Trade-off
I chose to spend the first stretch of my time restructuring the team and coaching individuals rather than pushing straight into roadmap execution, a slower start on visible delivery in exchange for a team that could eventually make its own prioritisation calls without me in every decision. That meant some near-term roadmap items moved slower while five people were being coached through a genuinely different way of working.
7. Execution Snapshot
Ran regular 1:1s built around surfacing problems early and tying each person's KPIs to a specific thing they needed to learn next. Delivered training sessions on product and project process so the team worked from one shared method. Coached five delivery project managers individually through the shift from execution to ownership, sitting with them on real prioritisation calls rather than teaching it abstractly.
8. Outcomes & Impact
Trained five delivery project managers with no prior product background into product managers making their own prioritisation and trade-off calls. Restructured the team so it functioned as an actual product department rather than a delivery function reporting up through project status. Decisions about what to keep or cut started coming from the team itself, backed by data, rather than escalating to me by default.
9. Learnings & What I'd Do Differently
Tying KPIs to what someone needed to learn next, not just what they shipped, is what actually changed behaviour, not the training sessions themselves.
I'd formalise the trade-off framework in writing earlier, so the five PMs had something concrete to point back to when defending a call to stakeholders.
Interested in how I approach similar product challenges?
Whether that means a full-time role or consulting on a specific project.