A few years ago one of our designers heard this from a colleague: a leadership team wanted to release their newest software product as a surprise. Big splash on launch day, competitors caught flat-footed, buzz in the market. Nothing wrong with any of that. But to keep the surprise, they had decided that no end users and no business stakeholders could be involved until launch.
That’s the part that goes wrong. A surprise launch only works if the product ends up being something people actually want. Keep users out and you’re betting the whole reveal on being right without ever checking. When it misses, you’ve gathered a crowd to watch it miss.
We see the internal version of this far more often than the market version. An owner or COO decides the new operations platform will be rolled out to the field on a Monday, all at once, with nobody outside the project team having seen it. The reasons are usually reasonable: don’t distract the team, don’t start a rumor that jobs are changing, don’t let the people attached to the old system slow it down. The result is the same either way. The people who have to live in the software every day see it for the first time when it’s too late to change anything.
Secrecy and user involvement are not mutually exclusive. You just have to structure it.
1. Treat users as collaborators, not outsiders
User involvement feels risky because users are treated as outsiders. Outsiders leak. Outsiders aren’t invested. Outsiders give polite feedback because they have no stake in the answer.
Flip it. Pick a small group and bring them inside the project. You don’t need many. For an internal system, five to eight people who actually do the work will find most of what a hundred would. For a product going to market, a few dozen, split into sensible groups, is enough to read a real reaction.
Give them real roles: interview subjects in discovery, reviewers of the mockups, testers of the early working builds, the first people onto the system before the rest of the company. Tell them why it’s confidential and ask them to keep it that way. An NDA is reasonable for external testers. For employees, a direct conversation with the owner usually does more than paper.
When people are collaborators, they protect the surprise because it’s theirs too. And they tell you the truth, because they’re the ones who are going to have to use the thing.
2. Test early, and keep testing
Feedback at the end of a project is almost worthless. By then the budget is spent, the architecture is set, and every change is expensive. Feedback in week two is nearly free.
This is why we validate before building. Every new build we take on starts with a VDP Sprint, and the design sessions inside it put click-through mockups of the key screens in front of real users before a line of production code exists. If the dispatcher can’t find the button, we find that out on a mockup, not in month four.
It continues after the sprint. We ship working software early and often, and each release goes to the same small group first. They see it first. They break it first. Their reaction shapes what comes next.
None of that requires telling the whole company or the whole market. It requires telling six people and treating them well.
3. Make your collaborators part of the reveal
The involvement doesn’t stop when development does. The people who helped shape the system are your best advocates on launch day, and they are usually eager to be.
For an internal rollout, that’s the difference between “management is forcing a new system on us” and “the dispatch lead helped build this and says it cuts her end-of-day by an hour.” Put the early group in front of their peers. Let them run the demos and take the questions. They’ll be believed where a project manager won’t.
For a market launch, the same group becomes your testimonials, your first case study, your first referrals, your Q&A panel. They were there. They’ll say so, and they’ll enjoy saying it.
What skipping this actually costs
We’ve been asked to rescue more than one system that was built in secret and revealed to its users at go-live. The pattern is consistent: the software matches the spec, and the spec was written by people who don’t do the job. Screens are laid out for how a manager imagines the work, not how it happens. Required fields nobody in the field can fill in. A workflow that assumes the office is open when the crew is working.
Fixing that after launch costs more than involving users would have, and something harder to recover is gone too: the team’s trust in the next rollout. Once people have been surprised by a system that made their day worse, every future change gets met with the spreadsheet coming back out.
The surprise is worth protecting. The product is worth protecting more.
A note on what the surprise is actually for
Ask what the secrecy is buying. For a market launch, it’s a window before competitors respond, and that window is real. For an internal rollout, the honest answer is often that leadership wants to avoid an argument. That argument is the cheapest feedback you’ll ever get. Have it in week two, with six people, over a mockup, instead of in month six with the whole company over a live system.
Where to start
If you’re planning a build, external or internal, decide now who your five to eight collaborators are. Then start with a VDP Sprint that puts them in the room from the first workshop. If you’re already mid-build and nobody outside the project team has seen it, that’s a fixable problem this week, and a 30-minute conversation with us is a good place to start.