Most companies have an internal product roadmap deck that they share with their strategic existing customers.

The problem is: you can’t visualize bullet points.

So one or more of these things happens:

• Your customer sees a feature mentioned, assumes the worst possible incarnation of it (security breaches! performance slowdowns! losing existing data!) and freaks out. You have to spend the next couple of months digging yourself out of the hole and trying to regain their trust.

• Your customer sees a feature mentioned, assumes the best possible incarnation of it (magically reads their mind and does everything they ever wanted!), and doesn’t bother asking any questions or providing any feedback. Later, when the feature launches and it doesn’t meet their sky-high expectations, you have to restore the relationship.

• Your customer sees a feature mentioned and doesn’t think at all about how it will impact their current usage. Later, when the feature launches and it creates changes for them, they get frustrated.

No matter how thorough you are as a product manager or designer, there will be interactions and oddities that you don’t realize until you launch. Some of these are unavoidable: they happen because of specific, unique data that you can’t predict. But many of them can be uncovered.

Enter the prototype demo.

This is so low-tech that it’s practically embarrassing to write about, but it’s by far one of the most useful techniques I’ve used in product design.

Here’s what you do:

List your features. (In a waterfall dev environment, this might be everything in a single release; for continuous deployment environments, this might be whichever features logically group together even if they’re ‘released’ at different times.)

Write a script that demonstrates how a single person, with a consistent back-story, would realistically use these features and get the intended benefits.

Get mockups that support this script. Each screen will need realistic-looking and consistent data (no ‘lorem ipsum’ fake text; if your demo user is named Sally in screens 1 and 2, she can’t suddenly be named Sample User in screen 3; the same button can’t be red on one screen and blue on the next) Work with your design team to update their mockups to use this realistic and consistent text.

Do a practice run. Grab a coworker or a customer who owes you a favor, and narrate the demo to them. (“Here’s how Sally, a typical customer like you, would use the features in our new release”) This will catch most of the inconsistencies in your mockups, as well as all the places where you “um” and don’t know the answers to questions.

Present your demo to a real customer. Encourage them to interrupt with questions, but otherwise stick to your script. Putting the features into context allows them to think more deeply about ‘how would we really use this?’ They’ll ask questions. Probably some that you aren’t sure of the answer.

Repeat and look for patterns. Are multiple customers raising the same issue with how you named that feature? Maybe you should tackle that now instead of releasing it as-is.

Incorporate feedback into product development process. The bad news is, you uncovered a bunch of flaws in your planned features. The good news is, you have time to fix them before a wide-scale release.