Ship the blank page

Years ago I was a junior product manager shipping an internal metrics dashboard. Every calculation was done. Every chart was built and reviewed. We were a day from launch when engineering told me we'd slip two weeks. The reason was a web certificate. Nobody had checked whether we could put anything on that domain in production.

I was annoyed, mostly at myself. How was I supposed to see that coming? Engineering had said there were no blockers. I didn't know what a certificate was.

At my next job I told the story to an engineering manager and he gave me the answer: on week one of any project, launch a blank page to production. Not a prototype. A blank page. It proves the whole path works, from your machine to the thing users see, before you've built anything on it. If the certificate is going to bite you, it bites you on day three with nothing at stake. This is sometimes called a tracer bullet.

I've thought of this lesson on every project since. The response is often the same. That's trivial. That problem won't happen here. And then, on the projects where we skipped it, it happened.

AI workflows have the same shape. The instinct is to build the intake form, connect to OneDrive to retrieve a spreadsheet, fully build the logic out, and end with a polished report. The blank-page version is different: one thin path. A form that reads a spreadsheet and tells you the number of rows.

This gives you a starting point to see what works, with time to fix it. It also makes it easy to add more - switch from a direct spreadsheet upload to OneDrive, make sure permissions work, and have something you can show a stakeholder.

The first version might take longer than doing the task by hand. That's fine. It wasn't built to save time. It was built to prove the pipes.

It feels flashier to have something working on your laptop than to have a blank page in production. The blank page is worth more.