Delivering someone else's product, on someone else's budget

Context

BRJ Super Portal is a recruitment platform for the Saudi market — job seekers on one side, companies on the other, and BRJ’s own administrators moderating both. Saudi nationals verify by national ID, expatriate users by mobile. Everything is bilingual, Arabic and English, and none of it is optional: a recruitment product that works properly in only one of the two languages its users speak is broken for half of them.

I was the product manager, working at Digitas ME, delivering for BRJ as the client. That sentence contains the whole difference between this study and the others on this site.

At DropX I decide what gets built and I live with it. Here the product belonged to someone else, the budget belonged to someone else, the team was a fixed size, and the platform was already live and taking real traffic. My job was the backlog, the release scope, and the conversations where those two meet.

The challenge

An agency engagement has a shape that a founder’s product does not. The client has a list of things they want. The team can build a known amount per sprint. Neither of those facts changes because everyone would like them to.

So the pressure lands in three places at once, all of them mine:

• Scope. Every new request either displaces something already planned or costs money. There is no third option, and pretending otherwise just moves the reckoning later.
• A live platform. Production incidents arrived alongside the roadmap — sign-in failures, registration errors, notification and template problems. They do not wait for the sprint boundary, and the person who reprioritises is me.
• Acceptance. The client tested each release and came back with findings. How those get handled decides whether the relationship is collaborative or adversarial.

What I did

Phased the events product, and wrote down what was not in it

The headline delivery was an events platform: BRJ runs hiring events, and companies and job seekers both needed to register, attend and follow up.

I split it into an MVP and three later phases, and the split was the work. The MVP was the smallest thing that made an event real: create it, let companies register, let job seekers register, let admins accept or reject, and move it through its lifecycle. Attendance scanning, candidate bookmarking and feedback collection went to the next phase. Interest signals, match scoring and shortlisting went to the one after. Notifications over WhatsApp were written down explicitly as optional, which is a more honest label than “later”.

Naming the phases mattered more than the order. Once a deferral is written down next to the thing that was kept, the conversation stops being “why isn’t this in” and becomes “which phase, and what does that cost” — a question with an answer.

Made the event lifecycle a sequence, not a switch

The design decision I would defend in an interview looks small on a state diagram. An event moves through created, published and completed — and who can register changes at each step. Companies can register while the event is being assembled; job seekers can only register once it has been published; once it completes, nobody can.

That ordering is the design. Companies commit before job seekers can see the event, so a job seeker never registers for an empty room, and BRJ can cancel a thin event before anyone has been invited to it. A single open-to-everyone registration window would have made both of those impossible to recover from.

Everything else in the lifecycle followed from that: what each role sees in each state, what the button says when registration is closed, what happens when someone tries to register twice.

Priced the changes instead of arguing about them

Change requests are where an agency relationship is won or lost. Mine went back with the work broken down and costed, and — where the request could be met more than one way — as options at different sizes and different prices, rather than a single number to accept or reject.

That reframes the conversation completely. “No” is a position and invites a fight. “Here is the full version, here is the version that covers your actual deadline, and here is what each costs” hands the decision back to the person whose budget it is. They are better placed to make it than I am, and they own the outcome afterwards.

Turned UAT findings into a queue

Each release went to the client for acceptance testing and came back as a document of things that were wrong or missing. I logged every item, split genuine defects from enhancement requests, categorised them by area, gave each a priority, and tracked them to resolution.

Separating those two categories is the part that does the work. A defect is something we owe them. An enhancement is a new request wearing a complaint’s clothing, and it belongs in the scope conversation above, not in a bug queue. Doing that sorting openly — rather than quietly declining half the list — is what kept acceptance from turning into a dispute.

Set a standard for how stories were written

I standardised the format: a story carries acceptance criteria that are clean, testable checkpoints, and a separate description carrying preconditions, the main flow, exceptions, validations and business rules.

The reason is QA. Acceptance criteria that have swollen into a behavioural essay cannot be tested item by item, so they get skimmed, and things ship untested because nobody could tell where one check ended and the next began. Splitting them kept the criteria sharp and gave developers and testers the context somewhere it did not dilute them.

Outcome

The events product was specified and released in the order the plan set, not in the order things were asked for. The MVP — lifecycle, registration for both sides, admin moderation — was written against the Figma and the scope document as stories with acceptance criteria in March 2026. Phase 1 and Phase 2 followed as their own specifications over the six weeks after it. Escrow arrived separately at the end of March, as a gap analysis against the existing backlog rather than as a fresh pile of stories.

The client’s acceptance rounds were absorbed rather than argued. The April return was logged item by item, split into defects and enhancement requests, prioritised, and tracked to resolution — with the enhancements routed into the scope conversation where they cost something, instead of being quietly declined or silently absorbed.

Being precise about the boundary, because it is the one an agency engagement blurs: what I owned was the backlog, the specifications, the release scope and the acceptance queue. The software was built by the team. The measure of that job is whether the team always knew what to build next, and whether the client always knew what a change would cost before agreeing to it — and through an MVP, two phases and a round of acceptance testing, they did.