The 45-second version
Problem, ownership, response, and outcome
- Problem
- Broad Responsible AI guidance competed with survival, sales, and immediate product work for early-stage teams.
- What I owned
- Product vision, research strategy, synthesis, framing, requirements, prioritization, product flow, intended AI architecture, and coordination.
- Product response
- Tailored questions, explanations, visible input-to-output mapping, editable reports, and actionable next steps.
- What changed
- Research redirected the team to transparency, and seven formative tests exposed exactly where trust broke in the experience.
- Boundary
- Hosted interactive prototype; scoring and generated guidance were not production-validated.
The user and stakes
“Be responsible” is not an actionable product requirement.
Responsible Innovation Labs asked our team to research and develop a tool for AI startup founders and investors to examine risk, strengthen trustworthiness, expand responsible adoption, and help shape regulatory conversations.
Early-stage teams face expectations around privacy, safety, fairness, transparency, and accountability, but much of the guidance assumes legal, policy, and governance resources they do not have. Founders needed a practical entry point: what matters to this product, why now, what to do next, and how to communicate current practice honestly.
The research recovery
We stopped asking founders to care more.
Our original research plan depended heavily on interviews with early-stage AI founders. After 400+ cold-outreach attempts yielded too little participation, I led the research-strategy recovery and we broadened discovery through investor, technical, design, healthcare, policy, founder, and Responsible AI perspectives.
The synthesis revealed a product constraint, not a values problem: founders could care about Responsible AI while survival, sales, and immediate product work still came first. I led the synthesis and pivot narrative that helped the team choose transparency as an actionable entry point.
That decision shifted the product from broad guidance toward guided decision support: tailored questions, explanations of why they mattered, visible input-to-output relationships, a human-editable report, and prioritized next steps.
Transparency became the connective layer between current product practice, customer trust, and the next decision a team could actually take.
What I actually did
My role and decision authority
I functioned as the strategy lead on a four-student team whose members all brought product or UX backgrounds. We worked collaboratively; I led the core framing and product-strategy workstreams while contributing across delivery and evaluation.
Trust, translated
The decisions that changed the product
From decision to system
A hosted prototype built to make the direction testable
Without a dedicated engineering team, we used a low-code stack. The workflow evolved across the capstone—from early RAG exploration, to a Webflow/Zapier/Sheets/OpenAI prototype plan, to a later Firestore, rules, model-assisted generation, CMS, and PDF handoff.
- 01
Onboard
Capture domain, base model, core function, intended use, audience, and current Responsible AI practices.
- 02
Tailor
Map product context to relevant questionnaire modules across privacy, fairness, safety, misuse, and synthetic content.
- 03
Assess and explain
Combine answers, rule-based scoring, and model-assisted analysis to assemble risk areas and recommendations.
- 04
Review, edit, and export
Render a draft disclosure report that the user can inspect, modify, and download before external use.

Working or demonstrated
- Structured onboarding and product-context inputs
- Tailored Responsible AI questionnaire modules and guidance
- Submission and report-generation flow
- Rendered report with review, limited editing, and download path
- Configured low-code data/model workflows and technical handoff documentation
Not production-ready
- Independent validation of generated guidance or reliable assessment
- Calibrated scoring, confidence, and source-grounded recommendations
- Production-grade security, privacy, access controls, and monitoring
- A completed RAG system or verified post-handoff adoption
What the evidence says
Seven formative tests showed exactly where trust broke.
Seven-person formative evaluation spanning technical practice, AI startups, product design, and AI transparency. The metrics describe this small study only and are not evidence of market adoption or assessment accuracy.
The topline numbers helped locate friction; the questions underneath them drove the product changes.
- 85%
- reported task completion in the formative study
- 1.2
- reported errors per participant
- 7 min
- reported time per module
- 4.2 / 5
- reported average satisfaction
- People struggled to see how early inputs mapped to questionnaire modules and report outputs.
- They questioned sensitive-data handling, the trustworthiness of generated content, and what scores meant.
- Guidance, progress, and download controls were too easy to miss.
- The team prioritized clearer progress, terminology, input-to-output mapping, report structure, next steps, and explanations for requested data.
Outcome and impact
A broad brief became a concrete, testable product direction.
The team delivered and handed off a hosted interactive application prototype plus technical reconstruction guidance. A real user could complete onboarding, answer tailored questions, wait for report generation, review and modify the draft, and download it.
The product and team impact is clear: a recovered research plan, a shared transparency-first direction, a testable workflow, and evidence-backed changes. The scoring and AI guidance remained partially simulated or unvalidated, and sponsor continuation after handoff is unknown.
- Strategy impact
- broad brief → transparency wedge
- Product impact
- hosted human-editable prototype
- User evidence
- seven-person formative study
- Handoff
- prototype + technical guidance
Current boundary
What this work does not establish
- The deliverable was a hosted interactive prototype, not a validated compliance or risk-assessment system.
- The low-code data, scoring, and generation workflow was partially implemented and changed across the project.
- Security, privacy, access control, monitoring, calibrated confidence, and generated guidance were not production-validated.
- Grounded retrieval and production RAG were future architecture, not completed capability.
- The project was handed off; sponsor continuation and adoption are unknown.
The next honest release
What I would build next
Reflection
Trust is not the polish added after an AI feature works. It is the behavior that lets people understand why information is requested, trace how inputs become outputs, question uncertainty, and retain authority.
