In the last year I ran about 75 customer interviews across two very different products, designed and analyzed a controlled experiment, and started producing a 100-person online conference from the event page to the live production on the day. The pattern across all three is the same, understand how someone works, build the plan around it, and write it up so the next person can act on it. I'm looking for operations, project coordination, consulting and research roles. I'm based between Madison, Denver and Las Vegas and open to relocation.
I'm Conor Caldwell-Gibbons, a 2026 graduate of the University of Colorado Boulder with a B.A. in Psychology and a minor in Business. My degree was heavy on research methods and consumer behaviour, and this year I've been doing the applied version of both: running customer discovery for an AI startup, building a research database for an awards outreach campaign, and now producing a paid online conference for heads of AI enablement at large companies, from the event page through to the technical side on the day.
What ties that work together is a single question I keep coming back to. Most companies measure AI by how many licences they've bought and how often people log in, but what I find more interesting is what happens to the person using it, whether they get more accurate, whether they get more confident, and whether those two things still move together once the tool is in the loop. That's a psychology question as much as a technology one, and it's the one I designed an experiment around in my final year.
I use AI tools every day and they make this work faster, but I've learned the hard way that they don't replace the part where you sit with the data, or the person, and actually look.
Outside of work I write feature screenplays and I trade. I traded options for a stretch and learned a lot from people who do it for a living, and these days I mostly run small bots in Python to test whether an idea holds up against real market data before I put money behind it. The screenplays taught me how to finish something long when nobody is asking for it, and the trading taught me how often a confident feeling turns out to be wrong.

Every write-up below answers the same five questions in the same order: what the situation was, what I did, how I did it, what came of it, and what I would do differently next time. That includes the result that contradicted my own hypothesis, because that is usually the most useful part.
Students use AI study tools constantly, and the common worry is that a fluent AI explanation makes you feel you understand something you don't. Most studies compare AI to no AI. I wanted a narrower question: does it matter whether the explanation comes before or after you try to answer?
Designed and ran a within-subjects, counterbalanced experiment with 17 participants in PsyToolkit. Everyone read short immunology passages, answered ten multiple-choice questions per condition, and rated confidence after each. In the AI-first condition a labelled AI explanation appeared before each question. In the retrieval-first condition they answered first and saw the same explanation as feedback.
Trial-level accuracy, reaction time, and confidence. Analysis in R: linear mixed-effects models for accuracy and response time, paired t-tests for calibration (confidence minus accuracy) and confidence. An order check confirmed counterbalancing worked.
AI-first produced much higher accuracy (66% vs 46%, d = 1.51) and higher confidence, but confidence rose less than accuracy, so people were more underconfident, not overconfident as I predicted. The calibration difference trended but wasn't significant with 17 people (p = .075). In other words, a single brief explanation placed before a question behaved more like teaching than like a crutch, which is not what I expected going in.
Larger sample, a delayed retention test a week or more later, and content participants already partly know, since unfamiliar immunology probably suppressed confidence in both conditions.
An early-stage AI startup selling to small businesses had no validated picture of who the customer was, what they already did about the problem, or what they would pay. I owned customer discovery from the first draft of the script to the interviews themselves.
Defined the target segments and buyer profile. Wrote the interview script and revised it through seven versions, including a branch for owners who use no AI at all. Built the interview tracker and a companion survey. Completed 34 interviews with owners across those segments.
Semi-structured interviews with recording consent, no product mention, one fixed script run identically for everyone. Captured pain in the owner's words, severity, frequency, current workaround, alternatives, willingness-to-pay signal, and whether they named the problem unprompted.
Most owners in these niches had no working picture of what AI could do for a business like theirs. The ones who were resistant gave specific reasons, usually cost, trust, and the time it would take to learn, rather than a blanket objection. Once I walked an owner through where AI would save them money and hours, most of that resistance softened within the same conversation. The structural lesson: the first script was built around the wrong audience and had to be rebuilt from a transcript rather than patched.
Book interviews before writing the script, not after, and run the readout as a second conversation with each owner.
The founder I worked for was a nominee at a business awards event and wanted to reach fellow nominees beforehand. He needed verified facts on each person and a database that kept what was known separate from what was an angle.
Built the research database with a fixed set of fields per person: verified title and tenure, what the organisation does, a recent trigger, a personal hook, risk flags, sources, last-verified date. Researched 50 nominees and drafted personalised openers.
Every fact verified against LinkedIn and the company site with a source link on the row. Contradictions between sources were recorded as contradictions, not resolved by guesswork. Judgment fields kept separate from fact fields.
The outreach itself did not run before the project ended, so the measurable output was the database. It became the one place anyone on the project could check a claim about a person before making it.
Start with three practice profiles and get them checked before scaling, which is what I did after the first pass showed the template needed tightening.
A senior AI advisor decided to run a one-day online conference for heads of AI enablement at large companies: about 100 attendees, five 45-minute sessions, a confirmed speaker from a major entertainment company. I own production: event page, registration, and the technical side on the day.
Started with a readiness brief that separated verified facts from 24 open decisions (platform, ticketing, recording, refund policy, run of show, lineup) so the founder could decide in blocks rather than in a pile. Chose the stack (Luma for the event page and ticketing, Zoom Webinars for delivery) and am building the event page and confirming speakers now, with the run of show next.
I work in bounded blocks with a written handover after each one, covering what got done, what I found, what's blocked and what I'd do next. There's one source of truth for event facts, and nothing gets published or sent without sign-off. The adjustment I've had to make is deciding the operational calls myself, platform, tooling, order of work, and telling the principal what I decided rather than asking him, because asking is a way of handing the load back.
The conference runs on 9 December 2026, so the result will be written up here afterwards.
Too early for a result, not too early for lessons. I'd have made the platform decision in the first week instead of carrying it around as an open question, and I'd have asked the speakers for bios, headshots and session titles the day they said yes instead of batching it for later. Same mistake both times, treating a decision I could make as one that needed someone else.
Most people know exercise is good for them and still don't do enough of it. The Theory of Planned Behavior says two things sit between intention and action: how you feel about the behavior (attitude) and whether you believe you can actually do it (perceived behavioral control). I wanted to know how tightly those two travel together, because an intervention that only fixes one of them may not move behavior.
Worked with a pooled survey dataset of CU Boulder undergraduates collected across several years with identical procedures: 2,295 responses, 162 dropped for missing data, 2,133 analysed (mean age 20.7, mostly women). Measured attitude and perceived behavioral control with the Kwan and Bryan (2010) scales, eight items on a seven-point scale each, and checked their reliability before using them.
Self-report correlational design, Pearson's correlation in R (Posit Cloud). Both scales held up: Cronbach's alpha .89 for attitude and .91 for control. Checked the scatterplot for outliers and linearity before trusting the number.
A moderate to strong positive relationship, r(2131) = .53, p < .001. People who felt more positive about exercise also believed more strongly that they could keep it up. That is noticeably higher than the roughly .33 that meta-analyses report for this pair across behaviors, which suggests the two are unusually entangled for exercise specifically, and that programmes built only on health facts are missing the enjoyment and confidence pieces.
It's correlational, so it can't tell me which way the relationship runs. The next study would change one of the two and watch what happens to the other. It's also self-report from a student sample, so people may have told me what sounded good, and I'd be careful generalizing past undergraduates. And with 2,133 people almost anything comes out significant, so the number worth looking at is the effect size, not the p-value.
The first is a review of what the research says happens to retention when students lean on language models to study. It ends with a recommendation: use the tool to check your understanding after you've tried, not as a first stop. The second is the experiment I ran six weeks later to test exactly that, and the result pushed back on part of the argument. Both are here in full, because a summary of a study tells you what I concluded and the paper tells you whether I earned it.
In my experiment the tool and the content were identical in both conditions, and the only thing that changed was whether the explanation arrived before or after the person had tried to answer for themselves. That one change moved accuracy by twenty points. Most organisations are busy answering the access question, who has the tool and how much they use it, and very few are measuring the second one, which is whether people's confidence still tracks what they actually know once the tool is doing some of the thinking. That gap is a psychology problem more than a software problem, and it's the one I want to keep working on.
I'm looking for operations, project coordination, consulting and research roles. Email is the fastest way to reach me. If you'd rather talk about the conference, the experiment, or the argument above, I'm up for that too.
conorliamgibbons@gmail.com