ConceptIntermediateModel Fluency & the AI PM Role / Working with ML engineers and researchers / #16

What does it look like when a PM is adding noise rather than value to an ML team?

TRACE · sorting a PM's real asks from noise, tested on Ironwick's workout-recommendation model

Ironwick builds AI workout plans that adjust week to week, and Thiago Bezerra runs the three-person team that owns the model deciding which exercises get suggested. This is the eight-week stretch where the team's shipping pace got cut in half right after their PM started showing up more, not less.

The direct answer
Noise looks like a request with no decision behind it: a status check that arrives faster than the model can produce new numbers, a one-off analysis nobody will act on, or a demand to reopen a tradeoff that nothing new has actually changed. The test is simple. If there is no real decision sitting on the other side of the answer, it is noise, not engagement, no matter how present the PM is.
Do this, in order
  1. Run every ask through one test: is there a decision on the other side of the answer?Why: this is the one line that actually tells noise from value, everything else here is detail underneath it.
  2. Cap status-check frequency to the model's real update cycle.Why: asking faster than a retrain and eval can produce new numbers just gets the same answer, at a fresh cost, every time.
  3. Require a decision or a name before a one-off analysis gets picked up.Why: an unattached "just curious" pull costs real hours and teaches the team that nothing was ever going to change based on it.
  4. Don't reopen a settled, eval-backed tradeoff without new evidence.Why: relitigating the explore-exploit split with the same old complaints treats a tested decision like it was never made.
  5. Keep the PM close to the work itself, not just close to the team's calendar.Why: sitting in the room costs the team nothing; sitting in the room and turning it into requests costs the team its shipping rhythm.
  6. Log every ask against the test for a real stretch before calling it a pattern.Why: one bad week can look like noise; a logged pile of forty-six requests with almost none attached to a decision is proof.

How to answer this, stage by stage

Nobody is grading whether you can name a bandit algorithm. They're grading whether you'll treat a busy PM as automatically good, or ask what their asks actually unblocked.

1
Anchor it in one team's calendar
Say it like this
"Let's ground this in one real team. Ironwick builds AI workout plans, and Thiago Bezerra runs the three-person ML team that owns the recommendation model deciding which exercises get suggested. I'm going to test one PM's actual asks against a real eight-week stretch, not talk about 'PM engagement' in the abstract."
Why this works
One real team and one real stretch of weeks keeps the answer from turning into generic advice about communication.
2
Name the trap in the question first
Say it like this
"Before I answer, I want to name the trap here. It's tempting to think more PM involvement is automatically good, and less is automatically bad. That's not the actual measure. The measure is how many real decisions those asks unblocked, not how present the PM was."
Why this works
Naming the wrong intuitive answer up front shows the interviewer you won't default to "communication is always good."
3
Say your structure out loud
Say it like this
"I'll run this as TRACE. Timeline: when the team's shipping pace actually slowed, and what looked like a good change right before it. Recut: slice 'PM engagement' into what it can actually mean. Assume nothing: don't assume presence equals value. Cause candidates: the real, specific asks that ate the team's time. Evidence test: one question that sorts noise from value on every single ask."
Why this works
Stating the five letters up front tells the interviewer you have a repeatable method, not a one-off opinion about this PM.
4
Give the decision, committed
Say it like this
"So here's what I'd actually say noise looks like. It's a request with no decision on the other side: a status check faster than the model could produce new numbers, a one-off pull nobody will act on, or a demand to reopen a tradeoff that nothing new has changed."
Why this works
This is the direct answer to the question, said plainly, before a single number from the story shows up.
5
Recut the pile into the three real types
Say it like this
"In Thiago's team's case, forty-six requests came in over eight weeks. Nineteen were status pings, arriving faster than the model's four-day retrain-and-eval cycle could produce anything new to say. Fifteen were one-off pulls, 'just curious' cuts with no roadmap decision waiting. Twelve were asks to reopen the explore-exploit split on the recommendation model, a split the team had already settled with a real test."
Why this works
Naming three specific kinds, with real counts, separates a diagnosis from a vague complaint about "too many meetings."
6
Prove it with the calendar and the real numbers
Say it like this
"Before this, the team shipped a real model improvement every nine working days. After Bodhi started joining the daily standup and opened an unfiltered Slack channel, that slowed to every twenty-one days. Ad hoc request time per engineer went from about two hours a week to about eleven."
Why this works
A real cadence number, not an adjective like "slower," is what makes the argument checkable.
7
Run the evidence test on the pile
Say it like this
"Here's the one question I'd run every ask through: is there a real decision sitting on the other side of the answer? Fifteen of the nineteen status pings, no, they landed on days nothing had finished retraining. Fourteen of the fifteen one-off pulls, no. All twelve of the relitigation asks, no, because nothing about the users, the model, or the data had changed since the original test. That's forty-one requests out of forty-six with nothing waiting on the other end."
Why this works
This is the strongest move in TRACE, and it's checkable against a real log, not a feeling that the PM is "too involved."
8
Say what to leave alone, then close
Say it like this
"One thing I'd leave alone: Bodhi sitting in the daily standup itself costs the team nothing, and a director asking for closer PM-engineering partnership isn't a bad instinct. The fix isn't less Bodhi in the room. It's every ask carrying the decision it's for. So, to close it: noise is a request with no decision behind it, and the fix is asking that question before agreeing to answer."
Why this works
Naming a boundary shows judgment instead of blanket suspicion of PM involvement, and the close restates the decision in one breath.

Let's learn

Ironwick looks at a person's goals, their equipment, and their workout history, then builds them a plan and adjusts it week to week, the way a coach would.

Knowledge spark: what "explore" and "exploit" mean here Exploit means the model keeps handing someone exercises it already knows work for them. Explore means it slips in something new now and then, to learn whether an even better fit exists. Too much exploit and the model gets stale. Too much explore and the plans feel random. Ironwick tests real splits between the two and picks the one that keeps people showing up.

For the first stretch of this year, about eight weeks, Bodhi Callanan, who owns Ironwick's personalization roadmap, checked in with the ML team once a week, at Friday's planning meeting. Thiago Bezerra's three-person team, who own the recommendation model behind the plans, shipped a real improvement to that model every nine working days on average. Four real ships landed in those eight weeks. Ad hoc requests from Bodhi cost each engineer about two hours a week.

Then a director told the product org, in an all-hands, that PMs needed to sit closer to the model teams. Bodhi took it seriously. He joined the daily 9am standup, which had always been optional for product. He opened a Slack channel called quick-pings, for anything on his mind, any time.

Hand sketched comparison diagram titled Bodhi's engagement, before and after the push. Left panel, a document icon labeled Weekly sync, caption one check in, Friday, one real question. Right panel, a question mark box icon labeled Quick pings, daily, caption any thought, any time, no filter.
Same person, same job, a very different shape of attention. Only one of the two costs the team its rhythm.

Over the next eight weeks, the team's cadence slowed to a real ship every twenty-one working days. Two landed instead of four. Ad hoc request time per engineer rose to about eleven hours a week, more than a full working day.

Days between shipped model improvements, weeks 1 to 16
24d 18d 12d 6d 0 Wk 9, push Wk 1 Wk 5 Wk 9 Wk 13 Wk 16
Baseline, near 9 daysAfter the push, climbing to 21
The line doesn't jump on a bad model. It climbs, slowly, starting the exact week the team got a more "engaged" PM.

Here is the turn. The slower cadence wasn't really about the retrain taking longer, or the model getting harder to improve. It was about what those extra eleven hours a week actually were. Of forty-six requests logged that quarter, forty-one had no real decision sitting on the other side of the answer.

We didn't lose two weeks of Thiago's team to a harder model. We lost it to Bodhi asking the same settled question three different ways.

What it costs at its worst: a team that used to ship every nine days, quietly down to every twenty-one, while the person driving the slowdown honestly believes he's doing his job better than before.

The choice I would take back When Bodhi opened the quick-pings channel, nobody set one rule: every ask needs the decision it's for, attached. That single rule would have sorted the pile as it arrived, instead of eight weeks and a self audit later.

What I would leave alone: Bodhi sitting in the daily standup itself. Watching the work, hearing the tradeoffs said out loud, that costs the team nothing. The problem was never his presence. It was what his presence generated on top of itself.

The lesson: presence and value aren't the same currency. A PM can sit in every meeting and add nothing, or send one message a month and unblock the whole quarter. Count what got decided, not who showed up.

Now here is the same thing as a story

The short version is above. Read this one when you want to feel exactly how a well-meaning change quietly cost a team a month.

Thiago Bezerra runs a tight, quiet ship. Three people, one recommendation model, a Friday deploy most weeks. He's the kind of lead who can tell you, inside a sentence, whether a slow sprint is a bad model or a bad ask. In two years at Ironwick, he's never missed a Friday ship without a real reason attached to it.

For the first eight weeks of the year, Bodhi Callanan checked in once a week, at that same Friday sync, and he always asked one thing: what shipped, and what's next. Thiago liked working with him. Bodhi read the changelog before he showed up. He asked good, specific questions. The cadence held at nine days a ship, easy, almost boring in the best way.

Then came the all-hands. A director, three tiers up, said something about product needing to sit closer to the model teams, closer to the actual work, not just the roadmap doc. Bodhi took it seriously, the way he takes everything seriously. He asked to join the daily 9am standup. He opened a Slack channel, quick-pings, and told the team, "anything on your mind, don't worry about formality, just drop it in."

Nobody in that room pushed back. Why would they. It sounded like exactly what good partnership looks like.

The first two weeks, Thiago still asked, every time a ping landed, "what's this for?" It felt a little combative, so he stopped. By week twelve he was just answering fast, to keep things moving, to not seem difficult. By week fourteen he wasn't registering the asks as asks anymore. A Slack notification would land, he'd pull a number, send it, move on, the way you'd swat a fly without looking up.

Hand sketched labeled parts diagram titled The recommendation engine's settled split. Center icon a gauge labeled Workout model, with four labeled parts radiating around it: 15 percent explore slice, 85 percent exploit slice, adherence eval each quarter, retrain cycle 4 days.
The model's own settled tradeoff, drawn as a system with named parts. This is what kept getting reopened with nothing new to reopen it with.

Three separate times over those weeks, Bodhi asked the team to reconsider the model's explore-exploit split. Months earlier, before any of this, the team had actually tested it properly. A ten percent explore slice held adherence at fifty-five percent over eight weeks. Fifteen percent held it at sixty-one, the best of the three. Twenty-five percent dropped it back to fifty-seven. Fifteen percent shipped, on real numbers.

Bodhi's worry wasn't invented. A handful of app-store reviews, maybe six over a month, used the word "boring" or "repetitive." But it was the same six reviews each time. No new test. No new number. Just the same worry, asked a different way, three separate occasions, twelve individual messages between them, each one costing Thiago's team half a day of re-explaining a decision that had already been made with real data.

The trigger, when it came, wasn't dramatic. In week fifteen, a new engineer on the team, watching Thiago pull a segment cut at six in the evening, asked him a simple question: "Wait, are we actually going to use this for anything?"

Thiago didn't have an answer. That was the whole problem, in one sentence.

He spent that weekend doing something nobody had asked him to do. He went back through eight weeks of Slack and his own calendar and tallied every single request that had landed on the team from Bodhi. Forty-six of them. Then, next to each one, he wrote down one thing: was there a real decision waiting on the other side of the answer, yes or no.

Forty-one out of forty-six said no. The team hadn't gotten a more engaged PM. It had gotten forty-one questions with nowhere to land.

Monday morning, Thiago didn't open with the tally. He opened by naming what he'd actually be giving up if he just shut the whole channel down: one of those fifteen one-off pulls, a segment cut by shoe width nobody had expected to matter, had genuinely fed a real fix to the app's onboarding flow. Closing quick-pings would have killed that too, along with the noise. He'd considered it over the weekend and rejected it for exactly that reason.

What he proposed instead was smaller. Every message in quick-pings would carry one line: what decision is this for. Not a form, not a process, just a habit, the same size as the message itself.

Bodhi didn't push back. He read the tally, saw the shape of it, and agreed on the spot.

Over the next eight weeks, requests to the team dropped to eleven. Every one of them carried a real decision on the other end. Cadence came back to ten days a ship, close enough to the old nine that nobody argued about the difference. Four real ships landed, same as the baseline quarter.

One channel let anything in, with no rule at all. The other let the exact same information through, minus a filter that cost about ten seconds to fill in.

What I'd tell myself, sitting in that Friday sync the day Bodhi opened the channel: openness and value were never the same setting. We could have had both from week one. Eight weeks of the team's calendar, and half of Thiago's shipped roadmap, is what it cost to only build one of them.

TRACE, for telling a busy PM from a useful one

Not a way to prove Bodhi was a bad PM. TRACE is what forces every ask to carry its own decision, so presence and value stop looking like the same thing on a calendar.

TTimeline. Lay out exactly when the pace changed, and what looked like an improvement right before it.
Eight quiet weeks, then a company all-hands where a director said PMs needed to sit closer to the model teams. Bodhi joined Thiago's daily 9am standup, always optional before, and opened an unfiltered channel called quick-pings. It read as a real improvement. Over the following eight weeks, cadence slowed from a real ship every nine days to one every twenty-one.
The moment that mattered wasn't a worse model. It was a change that looked, on paper, like better communication.
Hand sketched horizontal timeline titled Nine days to ship, then twenty one. Four marks along the line. Baseline cadence, caption a real ship every 9 days. PM push, this mark emphasized in coral, caption daily standup, open channel. Cadence slows, caption a real ship every 21 days. New hire asks, caption are we using this for anything.
The gap between the marked moment and the slowdown is the whole point. Nobody noticed a flip. It took eight weeks to add up.
RRecut. Slice "PM engagement" apart before trusting it as one thing.
Status pings that arrive faster than the model's four-day retrain-and-eval cycle can produce anything new. One-off analysis pulls with no roadmap decision waiting on the other end. And asks to reopen the recommendation model's explore-exploit split, a real, tested tradeoff, with no new evidence attached.
This is the slice that matters here, not by segment or cohort, but by what kind of ask each ping actually was.
Hand sketched icon list titled Three things PM engagement can actually mean. Three numbered rows with icons. One, a gauge icon, status pings faster than the real update cycle. Two, a question mark box icon, one off analysis with no decision waiting. Three, a scale icon, reopening a settled tradeoff with no new evidence.
All three were happening at once inside the same forty-six requests. None of them look like a problem taken one at a time.
The 46 requests, by type, before the fix versus after
46 34.5 23 11.5 0 9 total Before the push 46 total After the push
Status pingsOne off pullsRelitigation asks
Every slice grew, but the relitigation slice grew fastest, from one ask in eight weeks to twelve, on a tradeoff nothing new had touched.
AAssume nothing. Don't assume more of the PM in the room meant more value.
The org's instinct, get PMs closer to the model teams, wasn't wrong on its face. What went unchecked was whether that closeness was actually unblocking anything. The real measure of PM involvement is decisions unblocked, not hours logged in a standup or messages sent in a channel.
Presence is easy to see and easy to reward. Decisions unblocked take an actual count, and nobody was counting.
CCause candidates. The real, named patterns, not a vague sense that things got busier.
Forty-six requests landed over those eight weeks. Nineteen were status pings, fifteen of them on days when nothing had actually finished retraining. Fifteen were one-off pulls, fourteen with no decision waiting. Twelve were asks to reopen the fifteen percent explore split, all twelve with no new evidence attached, built on the same six app-store reviews Bodhi had already seen when the split was first tested.
Three named patterns, each with a real count behind it, not a feeling that the Slack channel had gotten loud.
EEvidence test. The one question that sorts noise from value on every ask.
For any single ask: is there a real decision sitting on the other side of the answer? If the retrain isn't done, a status ping has nothing new to report either way, noise. If nobody's holding a roadmap call open, a one-off pull changes nothing either way, noise. If no new eval evidence exists, reopening a settled split changes nothing either way, noise. Run all forty-six through that one line: forty-one fail it.
This is the strongest move in the whole framework. It's checkable against a real log, not a feeling that the PM asks a lot of questions.
Hand sketched decision tree titled The one question that sorts noise from value. Root node, is there a real decision on the other side of this ask. Two branches. Left, yes something changes either way, leads to answer it. Right, no nothing changes either way, leads to flag it as noise.
One question, run forty-six times. Forty-one of them landed on the right-hand branch.

There's a real AI risk sitting underneath Bodhi's worry too, worth naming plainly. If the team had actually dropped the explore slice to zero just to quiet six reviews, the model would stop collecting fresh data on anything except what it already recommends. That's a feedback loop: the training data would slowly narrow to confirm the model's own past picks, and nobody would notice until adherence quietly slid, months later, with no single day to point to. The fifteen percent explore slice is the guardrail against exactly that, re-checked against a real adherence number every quarter, never against a bag of app-store reviews. The team also accepted a real cost on purpose when they set that split: fifteen percent explore gives up a couple of points of adherence against a model that only ever repeats a user's known favorites, in exchange for the fresh signal that keeps the whole model from going stale.

Hand sketched full page metaphor scene titled Forty six asks, five decisions. Left side, a large question mark box icon labeled Many small asks, caption 46 requests, 8 weeks. A VS mark in the middle. Right side, a small balance scale icon labeled One real decision, caption a decision waiting on the other side.
The whole method in one picture. Volume and weight are not the same thing, and only one of them should decide what gets answered.

And if you want to be sure it really works, try it somewhere else

Same five letters, a fraud-detection team at a payments company instead of a fitness app, and this time the settled tradeoff being relitigated isn't explore-exploit. It's a flagging threshold.

Cinderway builds fraud detection for online payments, and Josiane Kirrane runs the small ML team that owns the model deciding which transactions get flagged for review. After a board question about "how closely are we watching this model," product lead Dalisay Quilter started requesting a false-positive-rate update every single day, a cycle faster than the fraud model's real batch-scoring refresh, which only runs every three days. She also began pulling one-off cuts by merchant category with no roadmap call waiting on them, and pushing, three separate times, to lower the flagging threshold "just to be safe," even though Josiane's team had already tested that exact tradeoff: a lower threshold caught more real fraud but declined far more good customers by mistake, and the team had picked the middle setting on purpose, on real numbers.

Hand sketched quadrant diagram titled Sorting Cinderway's asks the same way. X axis, has a decision waiting, from no to yes. Y axis, paced to the real cycle, from too fast to paced right. Four items placed on the grid: daily false positive rate ping in the bottom left, merchant cut with no tie in the upper left, reopen threshold in the middle left, new batch go or no go in the upper right.
Three of Cinderway's four asks land in the same corner Ironwick's did. Different product, same shape of noise.

Mapped onto TRACE, the diagnosis ran the same shape, with the numbers changed. The timeline showed a real cadence drop starting the week Dalisay's daily pings began. The recut turned up the same three patterns: off-cycle status checks, unattached one-off pulls, and a settled tradeoff getting relitigated with no new evidence. Assume nothing corrected the same wrong instinct, that a board question meant Dalisay needed to watch daily instead of watch well. The cause candidates were the daily pings, the merchant-category pulls, and the three pushes to lower the threshold. The evidence test sorted them the same way: is there a real decision on the other side, and for the daily pings and the threshold pushes, the honest answer was no, nothing about the fraud patterns or the eval numbers had actually changed.

Swap the trigger and it still runs.
Speed: an interviewer caps you at ninety seconds. Skip straight to it: noise is a request with no decision behind it, and the fix is asking whether one exists before you agree to answer.
Cost: no time to trace a real incident. Ask one question instead: for this specific ask, is there a real decision waiting on the other side of the answer?
The model got better, for real: say the retrain cycle got faster, four days down to one. A status ping every day stops being noise, because now there genuinely is something new to report. The test doesn't change. What counts as "too fast" does.

Where people run it wrong.
They treat every PM question as engagement worth encouraging, without ever asking what it unblocked.
They fix it by asking the PM to be less involved overall, instead of asking every request to carry its own decision.
They let a settled, eval-backed tradeoff get reopened by the loudest recent complaint instead of by new evidence.

How to use it live. When an interviewer throws this at you cold, buy two seconds by asking one thing back: "are we talking about a PM who's absent, or one whose asks don't ever seem to go anywhere?" Those are two different problems, and naming which one you're solving is usually exactly what a question shaped like this one is listening for.

Flashcards (tap any card to flip it)

1 · THE FRAMEWORK
What framework fits a question asking what PM noise looks like to an ML team?
Tap to flip
ANSWER
TRACE: timeline, recut, assume nothing, cause candidates, evidence test. Built for separating a real pattern from a feeling that someone is "too involved."
2 · THE PEOPLE
Who is this answer about?
Tap to flip
ANSWER
Bodhi Callanan, who owns Ironwick's personalization roadmap, and Thiago Bezerra, who runs the three-person ML team that owns the workout-recommendation model.
3 · THE TIMELINE
What changed right before the slowdown, and did it look like an improvement?
Tap to flip
ANSWER
A director told PMs to sit closer to model teams. Bodhi joined the daily standup and opened an unfiltered "quick-pings" channel. It read as better communication.
4 · THE RECUT
Name the three things "PM engagement" can actually mean here.
Tap to flip
ANSWER
Status pings faster than the real update cycle, one-off asks with no decision waiting, and asks to reopen a settled tradeoff with no new evidence.
5 · THE OLD DECISION
What decision would Thiago's team take back?
Tap to flip
ANSWER
Opening the quick-pings channel with no rule that every ask needed to carry the decision it was for.
6 · THE NUMBER
___ of ___ requests logged over eight weeks had no real decision behind them.
Tap to flip
ANSWER
41 of 46. That's the number the whole diagnosis turns on, not a feeling that the channel had gotten busy.
7 · THE EVIDENCE TEST
What's the one question that separates noise from value?
Tap to flip
ANSWER
Is there a real decision sitting on the other side of the answer? If not, it's very likely noise.
8 · CROSS-PRODUCT TRANSFER
Section 4 runs TRACE again on a different product. Which one, and what tradeoff was being relitigated?
Tap to flip
ANSWER
Cinderway, a payments fraud-detection team run by Josiane Kirrane. The tradeoff was the flagging threshold balancing missed fraud against false declines.

Check yourself Score: 0 / 0

Short answer, name the reversal
1. What old decision would Thiago's team take back, and why did it make sense at the time?
Show hint
Look at the key point box in Let's learn.
Show answer
Model answer: Opening the quick-pings channel with no rule attached. It made sense because it was meant to feel open and low friction, exactly when the org wanted PMs sitting closer to engineering.
Multiple choice
2. Which of these is the strongest evidence that Bodhi's involvement had become noise, not value?
  • A. He joined the daily standup.
  • B. Forty-one of forty-six requests had no decision waiting on the other end of the answer.
  • C. He asked about app-store reviews mentioning boring workouts.
  • D. The team's Slack channel got busier.
Show hint
Look at what Thiago actually tallied that weekend.
Show answer
B. A and D describe presence, not value, and C describes a real but stale worry. The tally against a real decision is the only checkable evidence.
Fill in the blank
3. Before the standup change, the recommendation model shipped a real improvement every ___ working days. After, that slowed to every ___ days.
Show hint
Look at the line chart in Let's learn.
Show answer
9. 21. More than double, and nothing about the model itself got harder in that stretch.
True or false
4. True or false: the fix here is for Bodhi to stop attending the daily standup.
  • True
  • False
Show hint
Look at "what I would leave alone" in Let's learn.
Show answer
False. Attending the standup itself cost the team nothing. The fix was requiring every ask to carry the decision it was for, not less presence in the room.
Short answer, apply it yourself
5. Think of a manager or PM whose questions ate your time without ever seeming to change anything. What's one question from this answer you could have asked them before answering?
Show hint
Think about the evidence test, not about being less responsive.
Show answer
Model answer: Something close to "is there a decision on the other side of this?" Most asks that eat time without changing anything turn out to have no decision waiting on them at all.
Short answer, where it wouldn't matter
6. Name a place in Ironwick's own workflow where a PM checking in daily would NOT be noise.
Show hint
Think about when a real decision actually is sitting on the other side, every single day.
Show answer
Model answer: During the week a real fix is being tested against a hard deadline, like a rollback decision. There, a daily check-in has a real ship-or-hold decision waiting each day, so the same frequency that was noise in quick-pings is exactly right there.
Before you close the answer
Why this works
Tests whether you'll treat a PM's presence as automatically good, or check what it actually unblocked. Most candidates jump straight to "communicate more," the opposite of what this incident needed.
Follow-up traps
"Isn't this just telling PMs to talk to engineering less?" Response: no, attendance isn't the fix, requiring every ask to carry the decision it's for is. Bodhi kept the standup and lost almost nothing.

"What if the 'boring workouts' reviews really are a signal?" Response: then it earns a real retest against the fifteen percent split, on fresh data, not a fourth ask built on the same six reviews already priced into the original test.
If pressed
Once the "what decision is this for" rule went live, the genuine one-off requests that did get sent, the ones with a real decision attached, actually closed faster than before, about ninety minutes instead of half a day, because writing the decision down first meant nobody had to guess what the requester actually needed.
From U2xAI Academy

From answering questions to owning outcomes.

A live workshop where you ship a working AI agent, defend a launch decision, and walk away with a portfolio recruiters can't wave off, not just more questions to study.

  • A live AI agent you actually shipped
  • A launch decision you can defend under pressure
  • An interview-ready portfolio, not more flashcards
Know more