Towards the end of my time at Accenture, I was the project manager on a launch for a large computer maker. They were starting a services offering for small and medium businesses, built on top of the CRM application they already ran. The go-live was a few months out. Requirements were still being written, and several vendors were involved. If you’ve been in this business a while, you know that combination costs a project manager some sleep.

I built a bottom-up estimate and a 13-week plan, then brought on an application lead, two developers, a test lead, and an integration developer. At the peak we ramped up to nine people. We set up a deliverable matrix and a workbook for risks, assumptions, issues, and dependencies, and I sent a weekly status tracking our progress. That was all fairly standard project management.

The part I’d repeat on any project was this: instead of whiteboarding designs, the team built working screens. We ran four conference room pilots where the business sat in front of something they could actually click.

Afterward, the client’s project manager wrote, “the team seemed to be impressed with seeing actual screens rather than whiteboards!” I’ve held on to that line for almost twenty years because it explains something I’ve never forgotten.

Home builders figured this out a long time ago. They don’t sell houses with blueprints. They build a model home. You can stare at a floor plan for an hour and nod along, but you don’t really know the kitchen is too small until you’re standing in it and walking around. Nobody lives in a floor plan.

Whiteboards and software designs are floor plans. People nod at boxes and arrows and clicks because there’s nothing to push against. Put screens created in code in front of them and suddenly they have opinions. That field is in the wrong place. This screen is taking too long to load. We never use that status. Where’s the button for the thing we do fifty times a day? When people react like that, they’re finally telling you the real requirements.

Showing something real also made the less fun conversation easier. As the pilots came together, I could see the go-live was going to overshoot the target date. So, I said so, early, while there was still time to plan around it. As a project manager, you can either announce the realistic date or wait for the deadline to announce it for you. The former is being responsible while the latter is a very unpleasant surprise. Nobody enjoys surprises in a steering meeting.

The same thinking applied when the client’s architect sent us tough feedback based on the pilots. Some of it stung. I passed it to the team that day, because the software and the feedback were doing the same job: showing us the truth while it was still cheap to act on.

We exited the planning and analysis phase on its baseline date with all four pilots delivered. I handed the project to a co-PM in December, and I like to think the habits went with it.

If you’re leading a project, here’s what I’d try. Find the scariest unknown and build the smallest working thing that would expose it. A real clickable screen beats a mockup, and a mockup beats another diagram. Put it in front of the people who’ll use it, then stay quiet while they react. If what you learn moves the date, escalate immediately.