Owning an internal product from a one-week MVP to an organisation-wide launch

to ship the MVP

1 week

to ship the MVP

trainees placed through the MVP

90+

trainees placed through the MVP

from first sprint to organisation-wide v1.0

5 months

from first sprint to organisation-wide v1.0

UAT pass rate before the pilot

90%+

UAT pass rate before the pilot

quarterly objectives delivered

4 of 5

quarterly objectives delivered

faster under load after the performance fix

28×

faster under load after the performance fix

The brief

Staffing requests arrived through Jira, Slack and email. The staffing team tracked them in spreadsheets, and employees heard about roles informally. Research with employees, the staffing team and account managers put numbers on it: employees rated finding open roles 2.3 out of 5 and the process 2.8, and some felt roles were filled before they were ever posted.

My job was to turn that into one product that business development managers (BDMs), the staffing team, employees and admins would all actually use.

What I owned

• Product direction: the vision, a six-phase roadmap and quarterly objectives, agreed and signed off with stakeholders.
• Discovery: research with three user groups, turned into personas and journey maps with our UX designer.
• The backlog: epics, user stories and acceptance criteria, plus binding business rules and a traceability matrix linking every requirement to its story and test.
• Stakeholders: business development, staffing and delivery leads, and five dependent teams whose systems Entra integrates with.
• Delivery: two-week sprints inside quarterly planning increments, with a team of nine across UX, frontend, backend, QA, DevOps and security. We hit 100% sprint completion by Sprint 2 and held it through Sprints 3 and 4.
• Quality and release: UAT with real users, the go/no-go call, release notes, and the move to a monthly release cadence.

Five decisions that shaped it

The calls a product owner is there to make: what to cut, what to protect, and when to change the plan.

How I work

• Objectives over story lists. Stakeholders sign off what we commit to, and at the end of each quarter I record what actually happened, including what moved and why. Four of five objectives landed; the stretch goal became its own phase.
• Decisions in writing. Business rules are binding and owned by the product owner, so the reasoning survives handovers and new team members.
• Testing with the people who’ll use it. Real BDMs, staffing and employees in every UAT round, a named signatory per area, and a go/no-go call. For v1.0 I ran a month-long rolling round so defects were fixed and re-tested inside it.
• Catching problems while they’re cheap. I spotted a dependent team building into the same space and called an alignment session before work overlapped. When the backend architecture needed rework, I paused new features mid-quarter to fix it before the debt compounded.
• Dependencies in the open. AI features stay off the numbered roadmap until model access and a data-residency review clear, instead of sitting in a phase they would make undeliverable.
• Releases people can follow. Every release ships with plain-language notes for the people who use it.

The product

One place for the whole staffing flow: BDMs raise and track requests, the staffing team runs postings and the applicant pipeline, employees see their fit before they apply, and admins control access with a full audit trail. The name comes from the Latin entrare, “to enter”: it’s named after the person’s journey rather than the process, which is also why the score never blocks anyone.

How it’s built

• An Angular 21 app, written in strict TypeScript, built entirely on the company’s design system, so it supports light and dark mode out of the box.
• Seven roles: admins, product owners, supervisory product owners, trainees, employees, BDMs and the staffing team. One person can hold several roles and switch between them, and each role gets its own dashboard.
• Admins can grant someone a single permission, such as raising staffing requests, without changing their role, and every admin action lands in an audit trail.
• Applications move through ten statuses, from submitted to placed on a project, and staffing requests have their own lifecycle from profile needed to filled.
• Company single sign-on, employee records and CVs pulled from the company’s HR system, and live notifications and request updates pushed to the browser as they happen.
• Every pull request runs tests, linting, code-quality and secret scans before it can merge.

What I’d do differently

Name UAT signatories at the start of a round, not the end: three areas reached the go/no-go call with nobody nominated to accept them, and it’s now an entry criterion. Reserve release-hardening capacity in the plan for late sprints instead of letting it displace features mid-sprint. And audit shared components for accessibility earlier, since most issues the pre-launch audit found traced back to a handful of them.