What to Do Before You Hand Off Something You Built

In 1990, a psychology PhD student at Stanford named Elizabeth Newton ran a simple experiment. She divided participants into two groups — tappers and listeners. Tappers were given a list of well-known songs. Their job was to pick one and tap out the rhythm on a table. The listeners’ job was to guess the song.

Before the experiment started, Newton asked the tappers to predict how often the listeners would guess correctly. Their answer: about 50% of the time.

The actual result? Listeners guessed correctly 3 times out of 120. That’s 2.5%.

Here’s what makes that worth talking about. When a tapper is tapping, they can hear the song in their head — the melody, the lyrics, the whole thing. What the listener hears is a series of disconnected knocks on a table. The tappers weren’t wrong because they were bad communicators. They were wrong because the knowledge they had made it impossible for them to imagine not having it. Chip and Dan Heath called this the Curse of Knowledge. Once you know something, you lose the ability to accurately imagine what it’s like not to know it.

This is the real reason project handoffs fail. Not missing documentation. Not skipped training sessions. Those are symptoms. The root cause is that the person handing the project off has been hearing the song so long they’ve forgotten that everyone else only hears tapping.

In football, the handoff is one of the most critical moments in any play. Get it wrong and it’s a fumble. Here’s how to make sure that doesn’t happen.

What’s actually worth writing down

When you build something — an app, an automated workflow, a system that runs part of your organization’s operations — you accumulate knowledge so gradually you stop noticing it. You know why that button does what it does. You know which field can’t be left blank without breaking something downstream. You know the assumption you made about the tax rate in month three because the requirements weren’t clear yet. None of that knowledge lives in the app. It lives in your head. And the moment you hand that app to someone else, you hand them an application full of trap doors.

Documentation exists to bridge that gap, but not in the way most people think about it. The goal is not to write a manual so complete that someone could learn the product from scratch by reading it. That’s not realistic, and nobody’s going to read it anyway. The goal is to give people who already have some context a gentle reminder about why things work the way they do. Short, functional notes. Not a book.

There are two things worth documenting above everything else.

The first is assumptions. Every project involves decisions made under uncertainty. Requirements aren’t always clear. Stakeholders don’t always know what they want until they see what they don’t want. When you filled in those blanks — when you decided the tax rate was 10%, or that only managers should have edit access, or that the workflow should run nightly instead of in real time — you made a call. Document it. Not just what you decided, but why. Even if you never hand the project off, future you will thank you.

The second is hidden logic. In a Power Platform environment, this means anything that happens outside the visible interface. Cloud flows that trigger when a record is saved. Trigger conditions that quietly control whether an automation runs at all. A good example of the latter: when you turn a cloud flow off, it doesn’t stop cold — it keeps queuing triggers and runs them when you turn it back on. In most cases that’s not what you want. So instead of toggling the flow on and off, you use an environmental variable as a kill switch: a simple Boolean in the trigger condition that says run if true, do nothing if false. It’s a cleaner solution, but it’s completely invisible from the UI. If you don’t document it, the next person spends an hour wondering why the flow won’t run. The note doesn’t need to be long. “There’s a Boolean environment variable named X that controls whether this flow runs” is enough. You’re not writing an explanation — you’re leaving a trail.

Keep it in one place

Keep that documentation somewhere central. One place, maybe two. A shared folder for documents, a Planner board for tasks. If you use Planner, a References bucket works well — just add cards for key project docs and attach the files directly to the cards. The goal is that anyone who needs to find something doesn’t have to dig through three SharePoint sites and a chain of emails to locate it. Scattered knowledge is almost as bad as no knowledge. If Planner is new to you, I wrote about how to set it up for a small team here.

Don’t wait until the end

Before you ever reach the moment of handoff, the most important thing you can do is keep the customer in the loop — not at the end, but continuously. If you’re moving fast, check in every few days. At minimum, once a week. It doesn’t have to be a meeting. A short screen recording, thirty seconds to two minutes, showing where things stand and asking whether you’re still heading in the right direction, is enough. The goal is that by the time you hand the product off, there are no surprises. They’ve been watching it take shape. They’ve already started forming a picture of what it does and how it works.

This is also your best opportunity to bring a secondary developer into the process. Have them run the customer meetings. Have them make the update videos. It sounds backwards if they didn’t build the product, but that’s exactly why it works. To explain something clearly to a non-technical audience, you have to actually understand it — you can’t fake it in front of the customer. A secondary developer who has been presenting and explaining a product for a month is not the same as one who got handed an access link the day the primary went on vacation. The former can cover about 80% of what comes up. The latter is a single point of failure with a different name on it.

Let someone try to break it

When you’re ready to release, get it in front of a representative group before you open it to everyone. Walk them through the happy path first — if the user does exactly what they’re supposed to do, does everything work? Get a thumbs up on that. Then give them a week to try to break it. Check in every couple of days to see what’s surfacing. Fix what needs fixing.

This isn’t just bug discovery. It forces the people who will eventually train others to start thinking about how to explain the product. The developer doesn’t always have to do the training — often the better outcome is equipping the stakeholder to own that part. But they can’t do it if they haven’t spent time actually using the product and running into its edges.

By the time the handoff happens, most of the work should already be done. Documentation exists, even if it’s still rough — and rough is fine, because the first few weeks in production will surface changes, and the docs should update as the product does. The secondary developer has context because they’ve been in the meetings and made the videos. The customer isn’t walking into something foreign because they’ve watched it get built.

What you’re really building, across all of this, is a situation where nobody has to hear random tapping. The customer knows the song because they watched you write it. The secondary developer knows the song because they’ve been explaining it to other people for the last month. The documentation exists not as a substitute for that knowledge, but as a prompt — something to jog memory when someone needs a reminder of why a decision was made.

What to do next

If you're building something for your team, try documenting just one assumption and one piece of hidden logic before your next working session. That's the whole habit — start there.

A fumble isn’t the result of a single bad exchange—it’s the visible symptom of everything that went wrong in the days leading up to it. Missed reps. Unclear communication. Inconsistent technique.

Get the week of practice right, and the handoff becomes routine—almost forgettable.

That’s the goal.

If you're trying to figure out where any of this fits into how your team works and want a second set of eyes, I'm occasionally available for small consulting engagements. You can reach me at brandon@brandonwoz.com.