Listen
Collect the documents, people, handoffs and exceptions that define the real work.
My fit for the Junior Product Owner role at Euna.
I build products by getting close to the work: listening to users, mapping the rules behind their decisions and turning what I learn into focused requirements a technical team can deliver. Across Acres, DriverSched and Get2Thr, I have carried that process from the first question to a working product.
The role, answered
What Euna asks for.
Where I can show the work.
What Euna needs to knowHow I have demonstrated it
Can you understand a complicated domain before deciding what to build?My approach is to understand how the work actually happens before discussing features. For DriverSched, I spoke with dispatchers about how they planned routes, collected driver availability, handled call-outs and calculated pay. Those conversations showed that the problem was not simply scheduling—information was divided between spreadsheets, PDFs, messages and people’s memory. I mapped that complete operating flow first. Each pain point then became a focused product capability with its own users, rules, data and exceptions. That is the same approach I would bring to procurement.
Can you turn a large feature into clear, sprint-sized stories?I start with the complete user flow and then divide it by behaviour rather than writing one large ticket. For DriverSched’s manifest workflow, I would not write a single story called “Build manifest import.” I would separate uploading the document, validating the file, extracting routes and stops, reviewing the result, adding it to the schedule and handling duplicate or failed uploads. Each story would have a clear outcome and acceptance criteria covering the normal path, errors, permissions and required data.
How do you use AI in product work?I use AI as an assistant for research, summarization, exploring alternatives and creating a first draft. I do not treat its response as a final answer or a source of truth. I verify important information against the original source, product data or someone who understands the domain. When an AI-supported product affects an important decision—such as an RFP response, eligibility decision, payment or safety-related action—I believe a person should remain in the loop. AI can accelerate the work, but a qualified person should review and own the decision.
Tell us about an AI-assisted product you have helped build.At Acres, we built a GPT-based system to help the company respond to RFPs using its previous project experience. The system divided an incoming RFP into meaningful sections and stored them semantically. Acres already had historical project information in Azure, so we also created a vector database for that material. The retrieval workflow matched new requirements with relevant previous work and supplied that context to the model through RAG. It produced a grounded first draft, while a collaborative workspace allowed team members to review, edit and approve the final response.
Can you work effectively with developers and technical leads?I am comfortable following a requirement from the interface into the API, data model and failure behaviour. While building DriverSched, I worked across React and Node-based product flows, integrations, operational data and technical edge cases. I use SQL to inspect relationships, validate behaviour and investigate questions involving drivers, routes, manifests, pay cycles and audit records. My responsibility is to explain the required behaviour, understand the technical implications, resolve ambiguity quickly and make the acceptance criteria specific enough for engineering and testing.
How do you treat compliance, privacy and audit requirements?I treat them as part of the feature—not as a final QA checklist. Get2Thr involved youth, families, sponsorship eligibility, financial information and safety-sensitive transportation. We had to define who could view information, who could approve an application, how supporting documents were handled and what happened when a normal ride or approval flow failed. Those rules influenced the roles, states, notifications and administrative workflows from the beginning. At Euna, I would apply the same discipline to WCAG, PII, audit trails, transparency and integration contracts.
Can you think about both the Buyer and Vendor experience?My strongest related example is the Acres RFP system. The RFP represented what the buyer required: the problem, constraints, evaluation criteria and expected evidence. The response workflow represented the vendor’s side: understanding those requirements, finding relevant company experience, creating an accurate response and coordinating review. That taught me that the two sides share a process but do not share the same goals, information or permissions. I would build on that experience at Euna by learning from procurement specialists, customers, implementation teams and support.
How would you contribute in a SAFe delivery environment?I have owned discovery, roadmaps, backlogs, release sequencing, requirements and working-product reviews, but I have not yet worked inside Euna’s specific SAFe cadence. What transfers is the discipline behind it: connect work to an outcome, keep the backlog understandable, expose dependencies early, make stories small enough to deliver and explain what shipped and why it mattered. I would learn Euna’s Planning, Review, Demo and PI practices directly from the team while bringing practical delivery habits from day one.
How I start
Before the backlog,
I learn the system.
Four deliberate moves turn an unfamiliar domain into product work that is clear enough to build, test and improve.
Frame
Map actors, decisions, permissions, information and failure points before choosing a solution.
Shape
Set a coherent outcome, split the work and make each requirement testable.
Deliver
Stay with engineering and design through the details, then learn from what ships.
Relevant product work
Three projects.
Three parts of the role.
01 · Closest domain bridge
RFP → requirementsAcres
We built a GPT-based bidding system that could retrieve an incoming RFP, understand its sections and help a team create a grounded first response from Acres’ previous work.
The problem was not simply text generation. A useful answer had to connect a new requirement to the right historical project evidence, keep the source context visible and give the team a shared place to review the bid before it moved forward.
MY PRODUCT CONTRIBUTION
I helped shape the retrieval-to-review workflow: how an RFP entered the system, how previous work was matched, where human review was required and how teammates collaborated on one response.
RFP → GROUNDED BIDACRES
01
INGESTBreak the RFP into semantic sections
Requirements · context · evaluation criteria
02
RETRIEVEMatch against Acres’ previous work
Azure records → embeddings → vector search
03
GENERATECreate a source-grounded first draft
GPT + RAG with relevant project context
04
COLLABORATEReview, edit and approve together
Shared ownership · comments · human judgment
System built with
GPT
RAG
Semantic chunking
Vector database
Azure data
Collaborative review
02 · Technical product delivery
Live product DriverSched
I built DriverSched from the ground up. Every major capability began with a dispatcher pain point and was designed through conversations with people running real fleets.
I treated each capability as a complete SaaS workflow—not a loose feature. It needed a clear user, rules, data, permissions, failure states, notifications and an operational result before it belonged in the product.
MY PRODUCT CONTRIBUTION
I owned discovery, problem framing, use cases, product and interaction design, roadmap sequencing, requirements, technical coordination, release decisions, packaging and the feedback loop after launch.
Run today’s station
Dashboard, schedule, routes, live map, vehicles and pre-trip inspections—one operating picture instead of several disconnected tools.
Know who can do the work
Team records, 14-day availability, performance, training and a passwordless driver experience designed for the phone.
Close the work defensibly
Payroll, adjustments, documents, agreements, manifest provenance and audit records that preserve who changed what.
Replace operational guesswork
Driver chat, route notifications, reminders and delivery history so important information is visible and replayable.
A configurable command centre bringing tomorrow’s preparation, live fleet state, communication and operational exceptions into one view.
What shipped
Scheduling
Routing
Live map
Vehicles
Pre-trips
Performance
Training
Payroll
Documents
Chat
Multi-station
Audit
03 · Trust, rules and exceptions
Visit organization Get2Thr
The problem was not simply “book a ride.” Transportation, eligibility, affordability, safety and family trust all had to work together.
We first defined the use cases and full service journey. Then we built the public website, family and rider experiences, the application and sponsorship approval flow, program discovery and requests, ride coordination, and an administrative platform for operations and billing.
I coordinated with URide to connect the systems for pre-scheduled rides, and worked across schools, activity programs and community stakeholders so the digital flow matched how the service would actually operate.
MY PRODUCT CONTRIBUTION
Use cases, service blueprint, partner requirements, approval logic, program onboarding, role design, integration coordination, admin workflows and end-to-end platform delivery.
ONE SERVICEGet2ThrAccess · safety · trust
FamiliesApply · approve
Program teamReview · govern
PartnersFund · coordinate
TransportDeliver · report
What we built
Website
Applications
Sponsorship approval
Program directory
Ride coordination
URide integration
Admin + billing
Apps
Technical range
Enough depth to ask better product questions.
I do not treat tools as the achievement. They help me follow a requirement into the interface, data model, API contract, test case and operational consequence.
SQL + data models
Querying and validating relationships, investigating product questions and reasoning about schemas, audit records and reporting.
GPT, RAG + vectors
Semantic chunking, embeddings, vector retrieval, grounding and human review for responsible AI-assisted workflows.
React, Node + APIs
Technical fluency across interfaces, backend behaviour, integrations, edge cases and acceptance criteria.
Figma + prototyping
User flows, wireframes, component states and rapid prototypes that make requirements easier to discuss and test.
The honest bridge
Procurement is a domain I would keep learning. Complex systems are work I already know how to enter.
01Multiple actorsBalance different goals without flattening the user model.
02Consequential rulesMake permissions, states and dependencies explicit.
03Defensible decisionsPreserve the record behind changes and approvals.
04Operational realityDesign for failure, recovery and the exception path.
One practical example
How I turn a vague request
into work a team can build.
Euna says the interview includes a procurement-style ticket exercise. This short example shows my approach—not prior work for Euna.
“Log every BidTable edit during the Open period.”
I would confirm four things.
Who can edit or view the history?
What counts as an edit?
Which data must be protected?
What happens if logging fails?
Record every successful, in-scope edit as an append-only audit event.
The event includes the actor, role, action, source and timestamp. Sensitive values follow the applicable data rule, and the application cannot report success when the required audit event fails.
Where AI helps
I would use AI to draft and critique the story, then personally verify the user, scope, permissions, failure behaviour and compliance rules before it reaches the team.
What I bring beyond experience
Commitment that grows into responsibility.
I am not approaching Euna as a short-term step. I want to learn the public procurement domain deeply, become someone the product and engineering teams can rely on, and take on greater ownership as I earn that trust.
Over time, I hope to grow into a product leader who understands Euna’s customers, systems and mission from the inside. My immediate goal is simpler: listen carefully, do dependable work and help the team make the product better with every iteration.
Learn the domain
Listen, ask precise questions and understand the rules behind the workflow.
Become dependable
Write clear work, close ambiguity and help the team deliver with confidence.
Earn greater ownership
Grow through contribution, context and trust—not title alone.
The short version
Experience gives me a starting point.
Commitment determines how far I can contribute.
I would bring zero-to-one product experience, technical fluency and the willingness to learn what responsible public-sector software demands.