Partner operations · Funding cycles · Outcome reporting
Partner & Donor Cycle Management
The product had to connect a long-term partner relationship, overlapping funding commitments and student outcomes without pretending those timelines move together.
Every product visual is labelled by provenance, so original work is never confused with a portfolio-created explanation.
A genuine working document, wireframe, screenshot or output that can be shown publicly.
A recreated product view grounded in the original work, using synthetic or anonymised information.
A simplified model created for this portfolio to explain system behaviour, workflow or product logic.
The operating problem behind donor reporting
The hard part was not registering a donor. It was preserving the relationship between commitments, students and outcomes after their timelines diverged.
Internal platforms · Partner operations · Funding cycles · Outcome reporting
A donor could fund multiple overlapping cycles across campuses, schools and cohorts. Students could move, progress at different rates or remain unresolved when the contractual period ended. Spreadsheet rows captured snapshots, but not the history, policy decisions and next actions required to manage the programme consistently.
One partner was being treated as one programme.
The organisational relationship could continue for years while each funding cycle had its own dates, cohort, commitments, campuses and closure state.
Funding end, student progress and outcome completion were different events.
A contract could end while students were still learning, awaiting placement or requiring an approved extension or operating decision.
Attendance, learning and placement truth lived in different systems.
The product had to bring those signals into the donor context without creating another competing source of operational truth.
One product connecting three independent timelines
The system had to preserve three clocks without forcing them into one status.
A donor agreement defines what was committed. The student journey records what is happening. Outcome completion determines when the commitment is actually resolved. The product connected those timelines while keeping their different meanings intact.
Partner · cycle · dates · cohort size · campuses · target outcomes
Registration · campus movement · attendance · learning progress
Placement · unresolved students · extension · closure · reporting
Three product decisions that made the model operable
The interface was downstream of the policy, timeline and relationship model.
The most consequential decisions were not field layouts. They defined what remained stable, what could overlap, what happened after a planned end date and which organisational disagreements had to be resolved before automation.
Separate the partner from each funding cycle.
The partner represented the durable organisational relationship. A donor cycle represented one bounded commitment with its own dates, cohort, campuses, target outcomes and extension state. One partner could therefore have several active or historical cycles without duplicating the relationship record.
Model overlap, extensions and closure as explicit states.
The system could not assume that cycles happened sequentially or ended cleanly on the contractual date. It needed to represent simultaneous cycles, planned end dates, cost or no-cost extensions, unresolved outcomes and final closure without rewriting the original commitment.
Resolve policy ambiguity before turning it into automation.
Successive PRD versions exposed a real organisational question: should unresolved students move to a bootcamp, transfer to another cycle, remain associated with the original cycle, or follow a linked-cycle rule? The product work made the disagreement visible before engineering encoded one interpretation as permanent behaviour.
Bring distributed evidence into the donor context
The platform integrated operational truth instead of duplicating every source system.
Registration, attendance, learning and placement remained owned by their respective systems. The donor-cycle product associated those signals with the correct partner, cycle and student context, then turned them into reports, progress views and proactive actions.
Progress against target outcomes and active-student count
Approaching cycle end requiring extension or closure review
Reporting deadline requiring data-quality action
From evolving policy to multi-campus production
I translated partnership policy into a product model that engineering and operations could execute consistently.
My scope included stakeholder discovery, partner and cycle entity design, business-rule modelling, PRD iteration, student-cycle association logic, reporting requirements, integrations, alerts, access needs, pilot preparation and phased rollout. The work also required surfacing policy conflicts instead of masking them with interface decisions.
Stakeholder discovery across Partnerships, campuses, leadership and finance
Partner, cycle and student-association domain model
Overlapping-cycle, extension and closure rules
PRD iteration and policy-conflict resolution
Integration, reporting and Slack alert requirements
Jashpur pilot preparation and phased multi-campus rollout
Do not automate an unresolved policy. Make the conflict visible, align stakeholders on the operating rule, then encode it as explicit states, validations and history.
Observed operational outcomes
Production evidence
What changed when relationships, commitments and outcomes became one operating system.
Reduced dependence on fragmented spreadsheet tracking for donor-cycle operations.
Improved visibility into long-term partner relationships and individual funding commitments.
Made student-to-cycle association and reporting context more reliable.
Improved handling of overlapping programmes, extensions and closure decisions.
Brought attendance, learning and placement evidence into a shared donor-reporting context.
Created better shared visibility across Partnerships, campus teams, finance and leadership.
The system progressed from design and development through a Jashpur pilot, phased multi-campus rollout and production use. Outcomes are presented as observed operational improvements; no unsupported quantitative impact claims are used.
The public views use synthetic partner, cycle and student data. Donor names, funding values, student identities, internal targets, agreements and reporting terms are not published.
What the work changed in how I think
Time, history and policy are first-class product data.
A relationship is not the same thing as a transaction.
The partner persists across time; each cycle is a bounded commitment. Keeping them separate made overlap, history and renewal manageable.
Contract dates and outcome dates are different truths.
Extensions and unresolved students require the product to preserve the original commitment while representing what happened afterward.
Policy ambiguity becomes software ambiguity.
Contradictory operating rules should be resolved before automation, otherwise the system merely hard-codes organisational disagreement.
Internal products should surface the next action.
Cycle-end and reporting alerts make the platform operational, not merely descriptive.