The thinking behind the work
How I approach
a problem.
Understand the person, follow the process, and make the next decision with evidence. Here’s how I would structure a product problem, using GradPlan as a worked example.
How to read this page. My GradPlan work includes journey mapping, requirements, prioritisation and development. The named frameworks below organise that work retrospectively; sample requirements, scoring and evaluation plans are illustrative, not a claim that I used each framework from day one.
See the actual screensStart with the person,
not a feature.
I would first ask what progress someone is trying to make, in what circumstances, and what gets in the way. Jobs to Be Done helps frame that question around the person’s situation rather than a list of product features.
GradPlan / a provisional job statement
“When I’m managing several applications, I want to see what needs doing next and keep the right context with it, so I can prepare without repeatedly starting over.”
A working hypothesis for this case study, not a quotation from a research participant.
What I would ask
Walk me through your last application. Where did the role, CV and preparation notes live? When did you have to find or repeat information?
What I would look for
Observed friction and workarounds, including where a spreadsheet or notes app already works well. I would look for evidence against my initial assumption too.
Output: a clearer user problem, with evidence separated from assumptions.
Explore broadly.
Then make the problem smaller.
The Double Diamond separates understanding and defining the problem from exploring and testing solutions. I would use it to avoid jumping from one observation straight into development.
Explore the current journey.
Choose the friction to address.
Compare possible approaches.
Try a small, useful version.
GradPlan / proposed problem framing
Make the next action clear.
Rather than trying to solve the whole job search at once, I would focus on whether someone can identify the next task for a saved application and access the context needed to complete it.
Explore first
Role context, application stage, a next action and access to preparation.
Keep out of this test
Social features, extensive visual customisation and automatic submissions.
Output: one problem statement, a bounded scope and a testable hypothesis. I would revisit the framing when evidence changes.
Choose what matters.
Be explicit about the trade-off.
For GradPlan, I’ve prioritised scope against user value, feasibility, cost and delivery effort. A framework such as RICE would add a structured comparison once there is enough evidence to estimate its inputs.
Who is affected, within a common period?
How much could the change help each person?
How strong is the evidence for the estimates?
What is the total work required?
I would not let a score override dependencies, necessary security work or a weakly understood problem. Without defensible inputs, I would compare the assumptions and run a smaller test instead of inventing precise numbers.
Try a RICE worked example
Interactive illustration only. Enter your own estimates. Nothing is pre-scored, saved or presented as GradPlan performance.
Output: a reasoned priority, the evidence behind it and what I’m choosing not to do.
Connect the screen
to the system behind it.
This is where my finance experience is particularly relevant: translating needs into specifications and tracing how information reaches the person making a decision. At Vista, that included Anaplan requirements and warehouse-to-platform data flows.
A generic financial-data journey
- Source data
- Transform & check
- Reporting model
- Visualisation
- Decision
Illustrative process, not a diagram of a confidential employer system or a claim about a specific Snowflake connector.
For GradPlan, I would map what the applicant sees alongside what the system needs to retain, retrieve or validate. Then I would define the smallest useful behaviour and its failure states.
Worked requirement: a next action for an application
Retrospective specification example, not an original dated project document.
As an applicant managing several opportunities, I want to save a next action against a role so that I can return to the right task with its context.
Given a saved application, when I add a next action and optional date, then the action is associated with that application and remains visible when I return.
Empty action, invalid date, cancelled edit, save failure and no next action yet. A failed save should not be shown as a success.
Automatic job submission and unrelated profile customisation are outside this example’s scope.
Output: a journey, a clear requirement, acceptance criteria and the dependencies needed to deliver it.
Build enough to learn.
Check more than the happy path.
My GradPlan work combines Jira backlog management with frontend development and APIs. I would keep a feature small enough to inspect, test and change, rather than treating a long feature list as evidence of progress.
Prototype the uncertain part
Check whether the workflow makes sense before committing to the full implementation.
Build a bounded change
Use the requirement and acceptance criteria to separate essential behaviour from later ideas.
Review the edges
Check permissions, missing input, errors, accessibility and dependencies as well as the successful journey.
Make an explicit release decision
Record what has actually been verified, what remains unresolved and what would justify release or a pause.
A real trade-off / release readiness
In the previously reported GradPlan upload review, new uploads remained paused while readiness questions were unresolved. Local fixes alone were not evidence that a feature was safe to reopen. This portfolio does not imply that the pause has since been lifted.
Output: a tested increment and a release decision supported by evidence, not simply a completed ticket.
Did it help?
What should change next?
I would connect each product goal to a signal and a measure. Google’s HEART research is a useful reference for choosing user-centred metrics rather than relying only on activity counts.
| Goal | Signal | Possible measure |
|---|---|---|
| Make the next task clear | Someone identifies an appropriate action without help. | Task success and time to identify that action in a usability session. |
| Keep preparation connected | Someone reaches preparation from the relevant role. | Completion of a defined role-to-preparation journey. |
| Support useful return visits | Someone returns to complete another meaningful action. | A defined return-action rate within a stated time window. |
I would define the cohort, denominator, time window and baseline before interpreting these measures. No results or targets have been invented for this case study.
For an AI-assisted feature: evaluate the output too
For CV suggestions, the proposed evaluation would compare a baseline with a revised approach using the same synthetic or de-identified cases. The applicant should be able to review, amend or reject the output.
Faithfulness — does it invent experience or qualifications?
Usefulness — is the suggestion relevant, and how much editing is needed?
Practicality — what are the response time, failed attempts and cost per acceptable output?
A proposed evaluation protocol. No experiment or model score is claimed here.
My next question would be simple:
“What did we learn that changes the next decision?”Read the development notes
Output: a finding, its limitations and a deliberate next iteration.
Framework references & evidence notes
The framework definitions draw on the original sources below. The GradPlan applications are worked examples written for this portfolio, informed by my experience.
- Christensen Institute — Jobs to Be Done
- Design Council — Double Diamond
- Intercom / Sean McBride — RICE prioritisation
- Rodden, Hutchinson & Fu / Google Research — User-centred metrics, CHI 2010
Professional and coursework details come from my CV. Screenshots are historical demo-site captures from 19 September 2026. The framework mapping does not imply that every method was part of the original project process.