A recipe is useless if you've never seen anyone cook from it. Frameworks are the same. Most get explained on a slide, nodded at, and never used again, because nobody watched one get applied to a decision with real stakes.
So instead of explaining G.I.V.E. in the abstract, here's one concept run all the way through it.
Why I built it
G.I.V.E. stands for Goal, Insight, Value, Expectations. I built it because I wanted teams across an organization to have a better way to quickly understand, capture, discuss and iterate on what was happening.
The part I care about most is that each section stands on its own. A team can go deeper on the insight, or the value, without pulling every other team into a room to get direction, clarify, do more research and write down what's going on in that area. It's asynchronous in its approach to specificity. I wanted something that gave more of that than Agile, Waterfall or jobs to be done: more transparency, and more people empowered to move without waiting on a meeting.
I made a version of the template while I was at Guidehouse, as a set of canvases a team could fill in one at a time.
The four parts, briefly
Goal: what we're trying to make true. One sentence. If it takes two, it's two decisions.
Insight: the thing we know that makes this decision different from the obvious one.
Value: who gets what, in their terms.
Expectations: what happens next, how we'll know it worked, and how we'll know it failed.
None of the four is clever. They're the questions a good listener would ask anyway. Writing them down first means they get asked before the meeting instead of during it.
The concept: ClearIntake
ClearIntake is a concept of mine, laid out on the G.I.V.E. template. The company isn't real. The problem is.
The idea: an AI intake kiosk for independent eye practices. A patient checks in and talks to it. It collects their history conversationally, verifies their insurance while they're standing there, captures consent and the payment commitment, and writes a structured brief for the provider before the patient reaches the exam room. It also flags possible eye emergencies so they don't wait in the lobby.
Here's how it ran through the four parts.
Goal. Make intake something the practice can trust, so billing stops leaking and the provider walks in already knowing why the patient came. Notice what that rules out. A goal of "add AI to the front desk" would have let almost anything count as success.
Insight. The obvious worry with a concept like this is the AI. Will it understand patients? Will it get the history right? Working through the technical canvas changed the picture. The canvas put it plainly: "the highest-risk assumption is not AI quality, it is integration." The kiosk only matters if it talks cleanly to the insurance checks and the practice's records system. A brilliant conversation that can't land in the chart is a nice demo.
That insight moved the whole plan. The first thing to test became the plumbing, and the model came second.
Value. Who gets what, in their terms. G.I.V.E. pushes you to write this per person, so the concept had a canvas for each one. The practice owner gets fewer denied claims. The front desk and billing staff get fewer insurance surprises to chase after the visit. The patient gets a check-in that doesn't involve a clipboard and repeating themselves. The provider gets a brief that's actually useful. None of those is written as "operational efficiency," because nobody on the other side of the counter talks that way.
Expectations. This is where G.I.V.E. earns its keep, and it's the part I want to dwell on.
Every canvas had a way to fail
Every canvas in the ClearIntake run carried success criteria and failure criteria. Both. Written before anything was built.
Two of the failure criteria, as written: "Claim denial rate unchanged 90 days post-deployment." And: "Provider still needs to ask the patient what brought them in."
Read those again. They're specific enough that a stranger could check them. If either one is true at the end of a pilot, the concept didn't work, no matter how good the demo looked or how much the front desk liked the screen.
Most teams write the success criteria and stop. Then six weeks in, the person who made the call reads every piece of news as proof they were right, and the person who argued against it reads the same news the other way. Nobody agreed ahead of time what bad news looked like, so nobody can call it. Writing the failure condition early is cheap. All you're doing is deciding, while everyone's still calm, what would count as failure. ("Use fuzzy metrics until you get good ones" goes further into declaring both up front.)
The concept also had a future press release among its canvases, written as if the pilot had worked. That's an exercise. It's useful precisely because nobody confuses it with a result.
The decision
The template opens with the Guidehouse Lab's criteria for what goes into incubation, five lenses: client impact, differentiation, productization or expense reduction, skills fit, and investment and risk. ClearIntake cleared all five.
The decision: proceed to a 90-day pilot with one practice, with a billing comparison as the primary success metric.
Look at how much G.I.V.E. shaped that one sentence. One practice, because the insight said integration was the risk, and you learn integration one practice at a time. Billing as the primary metric, because the goal and the value both pointed at money leaking out of intake. Ninety days, because that's when the failure criterion says to look. ("An innovation lab is not an incubator" is about why a decision like this needs an incubator's habits more than an inventor's.)
Two sizes
The ClearIntake run was the big version, a stack of canvases. The same four parts work at the size of a chat message. Something like: "We're moving the release to Thursday (goal). Support says Tuesday is their heaviest ticket day (insight). Customers get the fix without a slower queue, and support doesn't drown (value). I'll confirm with the release lead by end of day; if Thursday slips, we go back to Tuesday next week (expectations)." Nobody has to reply asking why.
Where the metaphor breaks
A recipe gives you the same dish every time. G.I.V.E. won't. Two people can run the same concept through it and come out with different answers, because the insight depends on what you went and found out. The framework makes the reasoning visible. It doesn't do the reasoning for you.
And unlike a recipe, you shouldn't follow it strictly in order. On ClearIntake, the insight about integration changed what the first test should be, which changed the expectations. You'll often find the insight and discover the goal was wrong. Go back and rewrite it. That's the framework working.
Try this
- Pick a decision you're about to make or announce this week.
- Write the goal in one sentence. If it takes two, split it into two decisions.
- Write the insight: the one thing you know that makes this different from the obvious call. If you can't name one, go find it before you decide.
- Write the value for each group affected, in their words.
- Write the expectations with two lines: what will be true if it worked, and what will be true if it didn't. Make both checkable by a stranger, and put a date on them.
- Send it before the meeting.
Where do you land?



