If you've ever sat down to write your self-review, opened a blank document and realized you could list every study you ran this year but couldn't say what a single one of them changed, welcome to the first five years of my career! For what feels like forever, my performance reviews were a list of activities, interviews here, a usability test there, a few readouts that got lovely feedback. Whenever my manager asked what happened because of the work, I'd scramble through old Slack threads hoping someone had mentioned my research in a roadmap meeting.

If you missed the last few emails, you can catch up on decision research here, evidence strategy here and outcome strategy here. Evidence strategy aims a study at a real decision, outcome strategy is the promise you make up front about what that decision should move, and impact strategy is the proof you collect after. It has three parts:

The line between outcome and impact strategy is timing. Outcome strategy happens before the study and impact strategy happens after. So if you set up an outcome block from last week, most of the hard work here is already done.

I used to treat the readout as the end of the study, a time to throw it over the fence and hope someone would make some moves on my work. I'd present, answer questions, drop the deck in a shared folder and move straight on to the next request. I then had no idea whether anything I found was used and neither could anyone else.

Now I keep a decision log with one row per study:

When the window closes, I fill in one line using this formula:

On [date], [owner] [changed / confirmed / stopped] [decision], based on [the finding they used]

If we go back to the example we were using in the other newsletters, Priya's plan before the research was to push split payments to next year. Nine of the 12 organizers said they'd switch, so the line in my log reads like this:

On May 12th, Priya changed the plan for split payments, moving it from next year's backlog onto the Q2 roadmap, based on nine of 12 organizers saying they'd switch from paying upfront

In the evidence column, a link to the roadmap ticket or the Slack message where Priya made the call means I never have to rely on my memory, or ask someone else to remember, six months later at review time.

I don't do the follow-up by hand anymore either. A Claude scheduled task checks my log every Monday, flags any study whose window closed that week and drafts a short check-in message to the owner, so all I do is read it over and send it.

The question I ask myself here is whether I could say what happened to the decisions behind my last five studies.

Once a few windows have closed, the log gives you one number, your decision rate, which is the share of studies that led to a decision.

Decision rate = (changed + confirmed + stopped) ÷ studies whose decision window has closed

Here's what each outcome means and whether it counts:

Studies still inside their window stay out of the count until they close, so a slow decision doesn't pull your number down too early. I count stopped as a win since stopping a project before a team spends a quarter building it saves the company a lot of time and money.

Say you ran ten studies this year and two are still inside their window, so you count eight. Three changed a decision, one confirmed the plan with a threshold agreed upfront, one stopped a project, two were ignored and one ended with no decision. That's five out of eight, or a decision rate of 63%.

I find the ignored and no decision rows more useful than the number itself. Whenever a study ends up as ignored, I go back to the nine checks from the decision research piece and look for what went wrong, which is usually a missing commitment or a decision that was never framed, and that tells me what to fix on the next study.

The decision log tells you whether the research changed a decision, and results measurement tells you whether that decision moved the number you agreed on in outcome strategy. I skipped this part for years, mostly since by the time a change shipped I was three studies further along and had forgotten which number we'd agreed to watch.

So I go back to the success formula from last week and fill in what happened:

[Metric] moved from [baseline] to [actual] within [time window] after [change] shipped, against a target of [target]

For the example from TeamTicket, it reads like this:

Group checkout completion moved from 58% to 62% within 90 days after split payments shipped, against a target of 65%

That's below target, and it still goes in the log. A miss is useful for Priya, since it tells her split payments helped without solving the whole problem, which is a good reason for a follow-up study on what else stops organizers at checkout. My research still did its job, since success belongs to the decision rather than the research.

Results are almost always messy, since a change rarely ships on its own. When I report a result, I list anything else that shipped in the same window, like a pricing change or a marketing campaign, and I talk about contribution rather than claiming the whole number. A line like "split payments contributed to a four-point rise in group checkout completion, alongside the new checkout design that launched in June" is far more believable to leadership than taking credit for all of it, and it means you aren't caught out when someone asks a hard question.

When I don't have analytics access, I ask the product manager or analyst with a short message:

"Hiya [name]! Split payments has been live for 90 days, and I'd love to close the loop on the study. Could you share where group checkout completion ended up, compared to the 58% we started with?"

Always remind yourself to check the metrics, whether that be after a month, 90 days, or whatever cadence makes sense for your project. Ideally the cadence of the follow-up is decided up front during planning.

The last part is making sure people outside your team hear about what changed. I wrote about surface-level and boss-level impact for resumes, and the same idea applies here, since a list of studies tells people what you did, while a decision and a number tell them what your work led to.

I use one formula everywhere:

My research on [study] led [owner] to [change / confirm / stop] [decision], which contributed to [metric] moving from [baseline] to [actual]

For TeamTicket, that becomes:

My research on group payments led Priya to move split payments onto the Q2 roadmap, which contributed to group checkout completion moving from 58% to 62% in 90 days

Then I put that sentence in three places:

If sending your wins feels like bragging, I recommend framing the update around the decisions rather than yourself, with an opener like "Here's what research helped the product team decide this quarter." It reads as useful information for them, and it gets your name attached to the decisions all the same.

The question I ask myself here is whether anyone above my manager knows what my research changed this quarter.

"None of my past studies have any of this written down"

I backfill, and I keep it to my last five studies so it stays a one-afternoon job. For each one, I:

If the owner has left the company, I ask whoever took over their area, or I check the roadmap and release notes myself. Anything I can't find stays out of the count, so my starting decision rate only includes decisions I can point to.

"I don't want to nag people for answers"

I've found the check-in gets a much faster reply when I make it easy to answer. Instead of an open question, I send a draft they only have to confirm, like "I'm logging that you moved split payments onto the Q2 roadmap based on the organizer sessions, does that sound right?" Most people reply with a yes or a quick correction.

If I don't hear back after a week, I bring it up at the end of our next 1:1 or sprint review. If it still doesn't come up, I check the roadmap or ticket myself and log what I can see, with the link as evidence.

"The team changed direction, and I can't tell whether my research was the reason"

I ask the owner directly whether the research played a part, and I log whatever they tell me. If it was one input among several, it still counts as changed, and my impact sentence uses "contributed to." If the decision was made before my readout, I log it as ignored and look at my decision framing for that study, since it usually means I didn't have the real deadline.

"My decision rate is low, and I don't want anyone to see it"

A low first number is completely normal, since you've never measured it before. I recommend keeping it to yourself for the first quarter and sorting your ignored and no decision rows by which of the nine areas was red. One area usually comes up again and again (ex: nobody committed in writing to what they'd do with the results). Pick that one and work on it for your next three studies.

When you do share your rate, share what you're doing about it at the same time, like "This is the first quarter I've tracked decisions, and next quarter I'm agreeing next steps with each owner before the study starts." That reads as someone improving how research gets used.

"Changes take months to ship, and I don't have access to the metrics"

The decision rate doesn't need any metrics, since it only counts what happened to the decision. So I start tracking decisions straight away and treat results as a later step. Until the number comes in, my impact sentence stops after the decision, like "My research on group payments led Priya to move split payments onto the Q2 roadmap," which is plenty for a quarterly update.

When the time window passes, I send the analyst message from earlier. If nobody tracks the metric, I use what I can get on my own, like support tickets tagged to the problem or how often it comes up in sales calls.

"I run too many studies to keep up with this"

I only log studies with a real decision behind them. A quick usability check before a release counts as one row, and a big generative study counts as one row too. Adding a row takes me about two minutes when I write the decision sentence, and checking the next steps takes about ten minutes on a Monday. If even that feels like too much, a Claude scheduled task can check the log each week and draft the check-in messages for you.

If you only try one thing from this piece, I recommend opening a blank spreadsheet today and adding a row for every study you're running right now, with the decision owner and the date the window closes. The outcome column can wait until those windows close, just make sure you follow up!

This week's download is the Impact Strategy Guide, a markdown file you can read on its own or upload to Claude and have it walk you through the process with your own studies. Inside you'll find:

To use it with Claude, upload the file to a new chat or a Claude Project along with your decision log, and tell Claude you want to work through impact strategy for your recent studies.

Please tweak the decision window and outcome definitions to fit how your team works!

Exclusively for paid subscribers: