Research,
connected.
How I built Hinge’s living research wiki
Cesar Cardenas
Program management in research
A career
across disciplines
Treasury
Product
Research
Understanding different teams. Connecting their work. Turning ambiguity into something useful.
Hinge’s first ResearchOps hire. Building from zero to one.
Inside the program
- Context & goal
- People & ownership
- Execution
- Architecture & validation
- Results
- Setbacks & learnings
- Reflection
Recreated diagrams. Relative metrics. No confidential research findings.
My first bet:
AI-powered research search
Found Marvin in beta
Research-focused AI search, early in its development.
Worked with the cofounder
Onboarded about three months later and shaped the fit for Hinge.
Brought it into Slack
Zapier flows helped research reach the places people worked.
~10× monthly queries · ~85% less filing time
Earlier repository results, not wiki outcomes. A strong solution for that stage.
Why build the next
version in-house?
Own the corpus
Research controls the evidence collection and its structure.
Connect more workflows
Different sources and entry points, shared research rules.
Maintain what we build
Validation, publishing, permissions and support.
Control and flexibility come with ongoing ownership. Inspired by Andrej Karpathy’s LLM Wiki idea.
Different teams.
Different questions.
Engineering
Evidence for a decision or an upcoming experiment.
Leadership
An issue understood through the lens of a persona.
New hires
A starting point for understanding daters’ experiences.
Shared evidence, different entry points. Research owners preserve the context behind the answer.
I built it with partners
across the organization
Program & initial build
Taxonomy, source-specific ingestion, partner discovery and adoption.
Engineering
Company-wide access, implementation and delivery.
Research & data science
Source context, experiment insights and review.
ML partners
Relevance, freshness and the quality of the output.
My role: make the needs, decisions and handoffs concrete enough to build.
An August start.
A planning milestone.
Target: a presentable V1 for product and engineering leads ahead of September 1 planning.
Useful first version
The right sources, taxonomy and ingestion rules.
Organization access
A PR through the shared environment, beyond my laptop.
Lead demos & feedback
Show the V1 and understand each team’s use.
The date is the target. Availability and rollout are separate milestones.
Workstreams
and dependencies
Research & corpus
Source-linked knowledge
Eligible material + evidence owners
Build & publishing
Pages and reader outputs
An agreed page structure
Platform
Connections that keep running
Access + deployment + an owner
Validation
Checks before and after changes
Expected outcomes + known failures
A shared schema lets work proceed in parallel. Changing it affects the writers, checks and readers.
How the wiki works
Find it automatically.
Publish it deliberately.
Notice what changed
Selected sources become candidates for review.
Identify the source type
A research question is not a research finding.
Review the proposed change
Keep a human owner connected to the evidence.
A daily Slack message brings eligible PRs to my attention.
Discovery, proposed changes and publication are different steps. A notification is not an approval.
A finding needs
its context
What do we know,
and where does it apply?
- Evidence
- Finding, proposal, or interpretation?
- Scope
- Which population and period?
- Provenance
- Original source and verified location
- Lineage
- New evidence or a summary of an existing study?
- Review state
- What has actually been checked?
I designed the taxonomy and source-specific ingestion rules to preserve these distinctions across different kinds of research.
One wiki.
Three ways to use it.
Maintained wiki
Source-linked pages with research ownership.
Wiki website
Browse pages and the insights researchers manage.
Notion mirror
Bring changes into an existing workspace.
Claude Code skill
Meet engineers in their working environment.
Illustrative page, not internal UI. Every reader still needs clear synchronization and access behavior.
Human judgment,
supported by checks
A person behind the page
The researcher or project owner brings context to review.
Structure + regressions
Check the record and catch known behaviors breaking after a change.
Recurring answer evaluation
Sample whether answers are supported, useful and appropriately qualified.
Owner review is not the same as recurring answer evaluation. A departed owner leaves a real coverage gap.
A recent sync can
carry old research
Publication freshness
When did this reader receive the wiki content?
Evidence freshness
When was the underlying finding last checked?
The system distinguishes these clocks. A new copy does not prove the underlying claim is still valid.
Adoption, usefulness
and content health
fewer flagged
metadata issues
Not an answer-accuracy score.
Research returned to planning
Early examples of older work informing current questions.
Team-specific entry points
Different ways to use shared evidence.
Measure the next layer
Repeat use, useful answers and source support.
Content health and user outcomes are different signals. Keep audit scope and rules with the result.
Give each team
a reason to try it.
Roadshows with real questions
Make the value recognizable in each team’s work.
Feedback becomes refinement
Watch where people need a different entry point or clearer context.
The use case earns repeat use. The launch gives people a reason to begin.
I involved leaders early.
I needed more ICs.
Move quickly with leaders
Understand priorities and show a concrete V1.
More workflows surfaced
Roadshows revealed needs beyond the initial picture.
More refinement than expected
Next time, test real tasks with people at different levels earlier.
Leadership alignment is valuable. It does not replace hands-on workflow discovery.
How I work,
throughout the program
Human centered
I build systems where AI handles the repetitive stuff and people keep what matters most: empathy, ethics, and the tricky decisions.
Intentional collaborator
I proactively, openly, and dependably partner to drive outcomes.
Adaptive
I creatively adapt to help teams reach shared goals, balancing quality with constraints.
Impactful
I strategically elevate the workflows and impact of those around me.
A working core,
with a next phase
Wiki + readers
Website, Notion mirror and Claude Code. Slack supports the review workflow.
Live MCP service
A possible path to a ChatGPT experience, with service and access work still needed.
Measure usefulness
Recurring answer evaluation and clearer repeat-use measures.
Current experience shown above. Live MCP and ChatGPT remain a separate delivery phase.
Let’s get into
your questions.
Curiosity. Kindness. Experimentation. Collaboration.
A little levity.
From an ambiguous ask to an AI-enabled knowledge program.
cesar cardenas · program management · research enablement
a case study
I build the connective tissue that helps teams move.
At Salesforce, Instagram, and Hinge, I have worked on the systems that help technical teams move. ResearchOps is where I found the intersection I love: program management, technical experimentation, and enabling researchers to take on complex work with confidence.
first research ops hire at hinge · the 0→1 phase is my favorite place to build
ResearchOps was the setting. Program management was the work.
The work spans research enablement, but the program is familiar: turn an ambiguous systems problem into a shared plan, align internal teams with an external partner, then build the adoption loop that makes a new capability stick. This is one example, and it ended with one of Hinge's first internal AI tools.
Where we're headed.
Context
An underused repository becomes a bigger program.
Program approach
Scope the problem, set the bar, align the right partners.
Complexities
The delivery work after the agreement was signed.
Implementation
Building an adoption system, not just a launch.
What is next
The next connected iteration, now in flight.
Final reflections
What the program taught me about building systems.
Q&A
Your sticky notes, answered live.
every visual recreated · metrics relative only · no confidential insights anywhere
01 · context
A repository problem can become a deployment problem.
The tool matters, but the real challenge is designing a system people trust, can maintain, and will reach for at the moment it matters.
era 01 · the filing cabinet
context · the original askThe starting ask: "our repo is half-baked. make it better."
Maybe move it to Confluence. Maybe choose a different repository. Reasonable options, but the more I learned, the clearer it became that the work was bigger than a filing system: it was a program to change how knowledge moved through the company.
spoiler: that is not what happened.
era 01 · the filing cabinet
context · the struggleWhere the system broke down.
Underutilized
XFN rarely touched it. Insights landed in a drawer, not in decisions.
Time consuming
Manual on both sides: researchers hand-filing, partners digging.
Not sustainable
A growing team and function on a system that didn't scale with them.
No innovation
If I see a manual process, I am going to ask what we can do to give it some glam.
The problem was clear. The program path was not.
…yet. personally? this gap is my favorite place in a project. it's where most of what i've built has started.
Build a knowledge program that makes trusted insight easy to reach, lightweight to maintain, and ready to grow.
02 · program approach
Turning an ambiguous ask into a deployable program.
First: the principles I bring to every program.
Human centered.
I build systems where AI handles the repetitive stuff and people keep what matters most: empathy, ethics, and the tricky decisions.
Intentional collaborator.
I proactively, openly, and dependably partner to drive outcomes.
Adaptive.
I creatively adapt to help teams reach shared goals, balancing quality with constraints.
Impactful.
I strategically elevate the workflows and impact of those around me.
How I ran the program.
01 · Map the system
Met with every researcher and with partners across the org to see the workflow, bottlenecks, and stakes from every point of view.
02 · Set the shared bar
Turned what I learned into decision criteria every tool and vendor would need to clear.
03 · Align the partners
Formed a point of view, made the recommendation, and brought leadership, internal teams, and the vendor into a shared plan.
04 · Design the rollout
Treated workflow change and adoption as part of the technical decision from the start, not as a handoff at the end.
Alignment was a delivery mechanism.
Those conversations were not a consensus exercise. I used them to form a clear point of view, surface the tradeoffs, and bring the people who would live with the system into the decisions that affected them.
You build WITH people, not FOR them. That created the support needed to make a real recommendation, and later, to make the new workflow stick.
The decision criteria came before the tool.
Budget, honestly
What could we actually spend, in money and time?
Speed to value
Could we prove usefulness quickly enough to earn confidence for the work that came next?
Sustainable at scale
Will it still work as the team and volume grow? Who maintains it on a random Tuesday?
Measurable success
If we can't track engagement, we're guessing. Adoption should be a number, not a vibe.
I evaluated the market, then made a recommendation.
i scanned everything to make sure we found the right tool for exactly what we needed.
Countless contenders. One fit.
judged against the four questions, not the demos
A technical decision and a partnership decision.
I recommended HeyMarvin: an AI-powered repository, when that was still an unusual move. It was not the most finished tool. It was the partner most able to meet the program we were trying to build.
Why it won
· Early AI capability that fit the opportunity
· Affordable enough to build a real business case
· A small, responsive partner: direct access to the co-founder and a credible path to shape the functionality our team needed
03 · complexities
A signed agreement is not a deployed program.
The work began after selection.
×Product limitations.
The tool couldn't cite its sources, and one-shot answers meant no follow-up questions.
×How could we track success?
No analytics out of the box. Adoption needed to be a number, not a vibe.
×A new tool meant a new workflow.
Researchers, XFN, and every future new hire would need to come along for the change.
I turned the gaps into an operating plan.
× Product limitations
No citations, no follow-up questions.
✓ Built a working cadence with the vendor
As one of their earliest customers, I held biweekly meetings with the co-founder. I translated the team's needs into a feature plan, citations shipped quickly, and the steady cadence made the tool feel built with us.
× How could we track success?
No analytics out of the box.
✓ Made usage observable
Specified custom query reports, then built a Slack bot that routed signals to me for fast triage. Adoption became a number we watched, not an assumption we made.
× A new tool meant a new workflow
Researchers, XFN, and every new hire.
✓ Designed the rollout, short and long term
Created an implementation plan for researchers, cross-functional partners, and future new hires. Which brings us to the next chapter…
04 · implementation
Deployment is a program, not a launch.
era 02 · the first ai bet
implementationA rollout designed for real ownership.
Research experts first
Working sessions until every researcher understood the system end to end. Owners and advocates, not downstream users.
Roadshows, pod by pod
Hands-on sessions with every pod, honest about what the tool did and did not do. That honesty built trust.
Company-wide launch
One shared moment to establish the new behavior, then the follow-through that made it routine.
Research 101 in onboarding
Every new-hire group got a tour of how daters think, then one live prompt. Adoption by default.
What changed when the program landed.
of sustained, company-wide use. Not a launch spike: a habit.
growth in monthly query volume since launch
employee empathy score, now sustained at 85 to 90
researcher upkeep time: filing a study fell from ~14 minutes of manual work to under 2
The quiet metric: "do we know anything about…" started going to the repository before it went to a researcher's DMs. The empathy score reflects a broader company effort, and this program was one contributor to it.
What the program unlocked.
✓One of the first internal AI workflows at Hinge.
Live for employees before ChatGPT enterprise access existed, built out of research ops.
✓Leadership still cites it.
Execs point to this work as a place Hinge was ahead of the curve on AI.
✓Our advocacy became product.
Citations, reporting, and more shipped because we pushed. The tool got better for every customer.
✓It became part of Hinge culture.
Every employee knows HeyMarvin: we wove it into Hinge onboarding 101, so the repository is naturally part of the company's infrastructure. Even researcher setup docs lived inside it.
From an ambiguous ask to a shared practice.
Watching a system become a normal, invisible part of people's workflows is the deep joy of program work: building the connective tissue that shapes how teams do their best work.
05 · so what now?
Every great thing evolves at the right moment.
era 03 · the connected brain
so what now · the turnThe next program: a connected knowledge system.
→The org's tool priorities changed significantly.
Center of gravity moved to Notion and Claude, and query volume began stalling.
→Marvin's MCP abilities remained limited.
I built workarounds through Zapier and API connections, but workarounds only carry you so far.
→My own fluency kept growing.
Technology experimentation was pushing me toward building an even stronger system.
The architecture
Shared synthesis,
maintained over time
An LLM wiki stores linked research pages. An ingestion workflow reads eligible sources and proposes updates to that shared knowledge.
Reuse the synthesis
Later questions can draw on existing pages. Changed sources still need to be revisited.
Define the rules
Taxonomy, ingestion instructions, review, and software checks guide what becomes part of the wiki.
Inspired by Andrej Karpathy’s LLM Wiki idea.
The tradeoff:
control and maintenance
Extend an existing product
Less infrastructure to own, with integration timing shaped by a vendor’s priorities.
Use the existing workspace
A familiar destination. Evaluate its fit against research structure, source traceability, and review needs.
Maintain a shared wiki
More control over structure and distribution, with responsibility for validation, publishing, and ongoing support.
One maintained wiki.
Several ways to reach it.
Canonical wiki
Reviewed, versioned content
Claude plugin Shipped
Generated content available in the reader workflow.
Browser viewer Shipped
A readable destination for wiki pages and source links.
Live MCP + ChatGPT In progress / planned
A live service is a prerequisite for the planned ChatGPT experience.
Snapshot delivery reduces dependence on a live content service, but introduces freshness and synchronization work.
A working core,
with a next phase
Wiki + readers
Maintained content, plugin, browser viewer, scheduled discovery, and automated checks.
More connections
Live MCP service. ChatGPT experience depends on it. Slack bot is not deployed.
Stronger evidence
Regular human evaluation, systematic claim verification, and usage measurement.
The implementation reflects Hinge’s tool environment. The program choices concern access, maintenance, and research quality.
06 · final reflections
What this taught me about building programs.
The practices I would carry forward.
Name the real problem
Deep understanding made the recommendation stronger and helped people see the program they were being asked to join.
Partnership is part of the architecture
The vendor relationship, internal alignment, and technical requirements were all parts of one delivery system.
Implementation defines value
A good capability only matters when people can trust it, use it, and carry it into their everyday work.
One starting ask. Three eras. Still evolving.
the tool changed twice. the operating system never did.
Questions? Thoughts? Stick them on.
Anything you wanted to ask and didn't: leave it here. Every note lands on my board tagged to the slide it came from, and the ones we don't get to live in the parking lot until I follow up.
Yes, this is a working intake system inside a presentation about building intake systems. It felt right.
tagged to: closing questions
thank you for reading · come say hi.
→ recorded questions · open the boardtagged to: …