What I Need From You: Four Functions, Two Asks Each, One-Word Answers

Course Guru’s live cohort feature — scheduled sessions, a roster, attendance, a replay — was six weeks from launch and had the specific smell of a project that will be late for reasons nobody has said out loud. Every function was confident about its own work and quietly depending on another function doing something that function didn’t know about.

Engineering assumed content ops would have the instructor onboarding guide ready before beta. Content ops assumed marketing was handling instructor recruitment. Marketing assumed the feature would have a demo environment they could record in. Support assumed someone had decided what happens when a session is cancelled ninety minutes before it starts, and nobody had. None of these were secrets. They were assumptions, which are worse than secrets because everyone believes they’ve been communicated.

We ran What I Need From You — WINFY — for fifty minutes with four groups.

What it is

WINFY makes cross-functional requests explicit and responses unambiguous. It runs in functional groups — engineering, content ops, marketing, support here — with a strict script.

First, each group meets alone and agrees its top two needs from each other group, phrased as “What I need from you is…” Concrete, specific, addressed to a group rather than a person.

Then the plenary. One group at a time states its needs to each other group in turn, in that phrasing. The receiving group writes it down and does not respond yet — every group states every need first.

Then the responses. A receiving group may reply with exactly one of four things: Yes, No, I’ll try, or Whatever it is you’re asking for, it’s unclear to me. No explanation, no conditions.

The ban on elaboration matters because elaboration is where accountability goes to die. “Yes, assuming we get the API docs by the 15th and nothing else lands” is remembered as a yes by the asker and a no by the answerer. “I’ll try” is the designed escape valve — honest, and a public flag that the dependency is at risk.

Running it before the cohort launch

Four groups, sixteen people, fifty minutes. The asks that mattered:

Engineering to content ops: “What I need from you is the instructor onboarding guide finished before beta opens, because we’re not building in-product guidance for beta.” Answer: I’ll try. The most valuable output of the session — a plan assumption converted into a visible, named risk six weeks early, in front of everyone.

Support to engineering: “What I need from you is a decision on what happens to a cancelled session’s attendees and their calendar invites.” Answer: Whatever it is you’re asking for, it’s unclear to me. The engineering lead didn’t know whether this was a product decision or a technical one. That answer, which sounds like a failure, put a question that had been rotting for a month on a whiteboard with two names beside it.

Marketing to engineering: “What I need from you is a demo environment with realistic seeded data by the 20th.” Yes. Ten seconds, and marketing stopped hedging its content plan.

Content ops to marketing: “What I need from you is instructor recruitment for the beta cohort — we don’t have the list and we assumed you did.” No. Marketing had never had it on their plan. A flat, immediate, public no meant we spent the next fifteen minutes assigning it rather than discovering in week five that nobody had.

Twenty-four requests in total, most uneventful yeses; the four above were worth the meeting several times over.

Why the four answers are the whole design

Ordinary cross-functional planning is conducted in a dialect where nothing is ever refused. Requests get “sure, let’s sync on that,” “should be fine,” “we can probably fit it in.” Every one is a yes to the asker and a maybe to the answerer, and the gap is where launches slip.

Restricting the reply set removes the dialect. There is no way to say “should be fine” in WINFY. You pick a category, in public, in front of the person affected, and every category has consequences you can plan around: a no is immediately actionable, an “I’ll try” goes on the risk list, an “it’s unclear” gets an owner.

The stating-before-responding sequence does the other half. If groups respond as they’re asked, the first few answers set a tone — one enthusiastic yes and the room calibrates toward yes for the hour. Hearing all twenty-four requests first means each group answers knowing the full picture, which is when honest nos become possible.

And “what I need from you” rather than “can you do” puts the asker’s stake in the sentence: a dependency with a reason attached, not a favor.

Where it goes wrong

It goes wrong if you let people explain. One “yes, but only if—” and the format is gone, because everyone now expects to negotiate. It goes wrong with groups that aren’t real functions — WINFY needs genuine interdependence. And it goes wrong if the “I’ll try” answers don’t go somewhere: that answer is an honest, early risk signal, and if it evaporates when the meeting ends, people learn to just say yes next time.

Skip it entirely if the real blocker is that one group is under-resourced and everyone knows it. WINFY will produce a row of honest nos, which is accurate, demoralizing, and tells you nothing new.