Led the launch of careers.fortescue.com, connecting the SuccessFactors job feed and managing redirects, then workshopped a roadmap of improvements with the careers team once the MVP was live.
→ Live SuccessFactors integration, redirects preserved, roadmap agreed with the careers team.
Problem
Fortescue needed a new careers site live at careers.fortescue.com, pulling live vacancies from SuccessFactors, the system the careers team already used to manage recruitment. The site had to replace whatever previously sat at that part of the domain without breaking existing links, and the careers team needed a clear view of what would come after the initial launch rather than treating the MVP as the finished product.
Context
As Global Digital Product Lead I owned this alongside the wider Fortescue platform work. The careers team were the business owners of the content and the hiring process, but had no visibility into what a web platform launch actually involved, so part of the role was translating between their hiring priorities and what the technical build could realistically deliver in the MVP.
Business objective
Get a working careers site live at careers.fortescue.com with a genuine, live connection to SuccessFactors, so vacancies stayed accurate without manual duplication, and do it without breaking existing inbound links to the old careers content.
Customer/user objective
The careers team needed a site that reflected real, current vacancies without them having to maintain two systems in parallel. Job seekers needed the redirects to work cleanly, so anyone arriving via an old bookmark or search result landed on the right page rather than a broken link.
Constraints
The job feed depended entirely on SuccessFactors being connected correctly, since that was the single source of truth the careers team already worked from. Redirects had to cover however the previous careers content was structured, which meant mapping old URLs before any new ones went live. The careers team's list of wanted features was long, and the MVP had to draw a clear line around what shipped at launch versus what became the next phase.
Stakeholders
The Fortescue careers team, who owned the hiring process and the site content, and whoever administered SuccessFactors on their side for the job feed integration. Wider marketing and web stakeholders had an interest in the redirect mapping, since a careers site sits inside the main fortescue.com domain.
Research and discovery
I mapped the existing careers URLs that needed redirecting before touching the new build, including the DNS switchover the new domain required, and worked through how the SuccessFactors feed actually needed to be consumed so vacancies would populate correctly and stay current without manual re-entry.
Options considered
One option was to launch everything the careers team wanted in a single release. Given the length of their feature list, that risked a slower launch and a harder scope to manage. I chose to define a genuine MVP, live vacancies and working redirects, and treat the rest as a prioritised roadmap agreed with the team rather than a backlog nobody owned.
Prioritisation
Getting the SuccessFactors feed and the redirects right came first, since neither is visible or exciting but both are what make the site actually trustworthy and functional on day one. Everything else the careers team wanted was sequenced into the roadmap we built together after that.
Delivery
I led the launch of careers.fortescue.com, connecting the site to SuccessFactors so live vacancies fed through automatically, and managing the redirect mapping from the previous careers content so existing links continued to resolve correctly. Once the MVP was live, I ran workshops with the careers team to build a prioritised roadmap of the features they wanted next.
Decisions made
I decided to scope the launch strictly around a working job feed and clean redirects, rather than trying to include the careers team's full wishlist in the first release. That meant some visible features waited for phase two, but it kept the MVP achievable and gave the team a real, working platform to react to rather than a delayed, over-scoped one.
Trade-offs
Holding firm on a smaller MVP meant the careers team didn't get everything they wanted at launch. I worked through their list using MoSCoW, must, should, could, and won't have, and managed expectations against that, rather than treating every request as equally urgent. I judged that a working, on-time platform with a clear next-phase roadmap was worth more than a delayed launch trying to do everything at once.
Business outcome
careers.fortescue.com launched with a live SuccessFactors job feed and working redirects from the previous careers content. A prioritised roadmap of post-MVP features was agreed directly with the careers team.
Customer outcome
The careers team got a working platform reflecting real vacancies without maintaining two separate systems, plus a clear, agreed view of what was coming next rather than an open-ended list of asks.
Lessons learned
A careers site lives or dies on whether the job feed is trustworthy, not on how the page looks. Getting SuccessFactors integration and redirects right first, before any of the more visible feature requests, meant the platform was credible from day one. Workshopping the roadmap with the team after launch, rather than trying to pre-negotiate scope before they'd seen anything working, made prioritisation easier because they were reacting to something real.
What I'd improve today
I made a point of getting IT, the SuccessFactors team, and Dev into a joint session early, time zones permitting, so the job feed integration was aligned with both the MVP scope and the future roadmap from the outset. That's the habit I'd keep for any similar launch.
