In the early days of my career the projects we took on typically had a feasibility test. We were often testing whether an idea was even possible. We were trying to eliminate technical risk.
For example we built the first PC to hibernate. This was before laptops and before operating system and device support for hibernation. We had to save all the memory, the state of the processors and each device in the system. Then we had to write a bootstrap that would restore it all and jump back through to where it left off as though it had been there the whole time.
Everything kept blowing up. Literally the processors would catch on fire. I had to get the team an in-circuit emulator so we didn't need a new machine every time and we didn't have the debugger changing machine state on us at breakpoints. Finally we confirmed we could do it after lots of little tests. Then we still had the program to write and battery to integrate!
The same thing is true in our projects today, but the challenge is distribution and business model. We can almost certainly build it. But how will you get it into the hands of customers? What kind of viral factor will it have? What will the cost of customer acquisition be and how will that cost scale? What do we need to build in to provide quick feedback and let us adjust and adapt to what people really want? What is the least we can build to let you test all of the above?
These are the questions we need to answer as a team. But there remains an instinct on the part of founders to spend too much time on prototypes for internal consumption and to build the full vision before asking it to stand up to the criticism or indifference of real users.
These are mistakes we can help you avoid. Today, you want to get the smallest testable product-let out there as soon as you can. And you want to run real tests of the assumptions in your business model. And you want all those tests to be as small as possible, so you can change when inevitably things aren't exactly like you thought they would be!