Being a heavy user of software products, I’ll sometimes have an idea of a product I want. After a brief incubation period, I’ll get the urge to build the damn thing. Being a software developer, I always succumb to this urge and invest a lot of time and effort into building at least an MVP of the product. Most of the time, unfortunately, I lose interest in the product just after playing with it for a while. Then, thinking that I didn’t actually want it, I’ll go about burying it in my Side Projects Graveyard. This pattern persisted more than I’m willing to admit.

The problem is that users (including us, developers) won’t know what they want until they see it and feel it. Common sense tells us that the solution is to build and iterate on an MVP to find out what users want, right? But building an MVP is not as cheap as it appears to be. Neither is iterating on an MVP. Think about all the technical decisions you must make and the technical debt you must carry. Software is always less flexible than we hoped.

Notice also that after investing in building an MVP it’s extremely hard to let it go once you find out users don’t actually want it. So, you tend to spend on it much more than you should. (Perhaps that’s the reason that many bad movies are produced.) If you are spending someone else’s money, you may accept it as a grim fact of life. Otherwise, you may want to consider other options.

For several years now, I’m convinced that a better option is to prototype the UI first. Of course, it does not apply to all products. Luckily, it applies to most user-facing products. A UI prototype is as effective as an MVP in finding out what users want. Unlike design mockups, users can both see it and feel it. Most important, developing a UI prototype takes a fraction of the time and cost of developing an equivalent MVP.

Large companies and some startups have been doing it for ages. I know it’s nothing new. But, it has been underemployed by most companies I’ve been involved in. In one company I overheard an all too familiar conversation. The lead developer just finished working on a long-awaited feature and showed it to the VP of Product (and a user himself). His response was quick: “This is exactly what I asked you to develop. It’s perfect. But, there’s no way our customers will ever want it in the product.” (The reason being some overlooked organizational considerations.) The developer worked on it for over a week. A UI prototype would have been enough to discover the issue in a few hours.

So, to find out what users want, ask them what they want. Next, build a UI prototype of what they said they wanted. Then, iterate on showing them the prototype, asking if it’s indeed what they wanted, and incorporating their feedback in the prototype. Proceed to develop an MVP only when they are excited about the prototype.

I still get the urge to build things, by the way. What changed is I no longer rush to build an MVP of any idea that comes to my mind. Instead, I can satisfy my urge by prototyping what I think I want. Consequently, my Side Projects Graveyard stopped growing as much as it used to do.