A Different Starting Point
When people ask how to validate a product idea, the standard answer is usually the same: build a prototype and see what happens. But Adam, who works on technology and product development at WickedBeno, a US-based R&D lab, has found that this advice does not always hold up. In a written exchange with Peekwire, he explained that his perspective comes from developing the lab's own ideas rather than client work.
Just for a bit of context, WickedBeno is currently more focused on developing and experimenting with our own ideas rather than building products for external clients. That does not mean we would not explore working on other people's ideas in the future, but for now, most of my experience comes from our own projects.
— Adam, WickedBeno Technologies
That context shapes his answers. Rather than drawing on client case studies, he described what he has learned while working through the lab's internal projects.
When a Prototype Isn't the Answer
Asked about a time when the usual advice about prototyping first did not fit, Adam was direct: he has not encountered that exact situation with a client. But he has lived through something similar on his own projects.
For example, with one of the projects I am currently developing, I initially thought the most logical approach was to start building a prototype and then see how things worked out. But as I got further into the project, I realized that some of the technical challenges were not necessarily the biggest ones. There were more fundamental questions, as of, how the idea would work in practice, whether certain assumptions about it were realistic, and whether the end result would actually provide the value we had in mind and we hoped for. And those are information that a working prototype alone might not always tell you.
— Adam, WickedBeno Technologies
His takeaway is that technical feasibility and practical value are separate questions. A prototype can prove that something works without proving that it is worth using.
These experiences made me realize, that sometimes you should spend a bit more time questioning the idea itself before jumping straight into development. And just because you are capable of building something, that does not necessarily mean you know how to make it useful.
— Adam, WickedBeno Technologies
What Early Conversations Often Miss
Adam pointed to a gap between capability and purpose. Teams can get excited about what they can build before they have a clear reason to build it.
Personally, it is probably the difference between being able to build something and on the other hand actually having a good reason to build it. I think it is pretty easy to get excited about an idea, especially when you start thinking about all the features and possibilities, and I think everybody including me, who were developing something, definitely got caught themselves doing that.
— Adam, WickedBeno Technologies
He also flagged scope creep as a recurring problem. What starts as a simple idea can expand feature by feature until the timeline triples. For teams working with limited resources, that expansion can be fatal.
Based on this experience I have learned that sometimes the hardest part is not coming up with new features, but deciding which ones you need and ones you really do not. This is especially useful when you are working with limited resources, then keeping things simple can make a huge difference.
— Adam, WickedBeno Technologies
The Order People Get Wrong
When asked what people decide too quickly, Adam said the common mistake is falling in love with a solution before understanding the problem.
In my opinion many people fall in love with the solution they came up with, before they have really understood the problem. I believe and I understand that it is tempting to immediately start thinking about what the product can and will look like, also which technologies you can to use, or what features the final product should have. That part is probably the most exciting one, but I honestly think the better approach is to first ask yourself what is the problem you are actually trying to solve, also who would benefit from solving it, and whether there might be another, a simpler way, to achieve the same thing.
— Adam, WickedBeno Technologies
He added that changing direction mid-build is not a failure. It is part of the process.
And to be honest, I truly think sometimes it is very important to be willing to change your original idea, because many times, after you start building something you realize halfway through that a completely different approach would work better. But on the other hand, I do not think this should be taken as a failure, to me it is only part of figuring things out.
— Adam, WickedBeno Technologies
Practical Takeaways
Adam's answers suggest a sequence that runs counter to the usual prototype-first instinct. Before committing time and resources, he recommends asking what problem is being solved, who benefits, and whether a simpler path exists. Only then does building make sense.
So, at the end of the day I think the goal should be to learn as much as possible, before committing too much time and resources to something that might not work.
— Adam, WickedBeno Technologies
For teams working through early-stage ideas, the implication is straightforward: treat the idea itself as the first thing to test, not the last. Prototypes are useful tools, but they are not a substitute for clarity about purpose. As Adam put it, being capable of building something does not mean you know how to make it useful.
WickedBeno was included in Peekwire's list of independent R&D labs alongside organizations such as SRI and InData Labs. Adam noted that the lab remains open to exploring external projects in the future, though its current focus is on its own development work.