Portfolio demonstration with synthetic data

Scoping a product proof of concept

A fictional SaaS support team needs to reproduce customer access reports. Its current request is broad: give support a way to see which access rules apply. The brief narrows that request to one testable workflow.

My role

I drafted product requirements and decision-record inputs for a contact-source reporting layer. This fictional access lookup shows how I’d scope a different request and define what a prototype needs to prove.

From support request to test plan

Define the support question
Choose the smallest workflow
Test synthetic scenarios
Decide whether to pilot

One-page product brief

User and problem: A support analyst needs to explain why a fictional user can or cannot open a workspace.
Prototype scope: A read-only lookup shows the workspace, the effective access decision, and the rule that produced it. The prototype uses a small set of fictional access records.
Scope boundary: Permission editing, bulk lookup, and production integration belong to a later phase.
Success criteria: Each test case returns the expected access decision and explains why. In a pilot, measure whether analysts can explain each outcome without engineering assistance.

Acceptance criteria

Synthetic scenarios for prototype review
Given	When	Expected result
A user has an active workspace grant.	The analyst looks up that user and workspace.	Show Allowed and identify the active grant.
A workspace grant has expired.	The analyst looks up that user and workspace.	Show Denied and identify the expired grant.
The workspace ID is missing from the test data.	The analyst runs a lookup.	Show Workspace unavailable and leave the access outcome undetermined.

Pilot decision

Move to a small support pilot after all test cases pass. If analysts can read the result but struggle to explain it, revise the reason text and rerun the same tasks.