I agree with the point Fabricio Teixeira is trying to make here. You seem to have taken a very radical view on how best to bring a product to market for the sole purpose of production value. It sounds like you and your team are more focused on selling a service rather than solving real problems — and you’re going to find any way to get there. 👏🏼 Bravo for ruling research completely out of the equation. 👏🏼
It’s really interesting to see your confusion between usability tests and user research. It sounds like you weren’t exactly sure how to synthesize your research findings into a strategic direction for the products you’re building. In case you weren’t aware of why user research is conducted, that’s exactly what it’s intended to do.
You could set a north star of X from a completely spontaneous assumption you came up with one day, (which is littered with your subjective bias) only to have gone through a 5 day sprint, prototype, test, get great results on if the product is functional, and put it to market only to realize that… oh no! Your product is failing because it wasn’t what your users *actually* needed! Instead of X, the product should have been Y!
How much of a lift is it going to be to radically change 65% of the product’s architecture off of live code? A lot. Now you’ve just put yourself in technical debt that will require more money and more research to recover from rather than doing your due diligence and understanding what your true north star was from the beginning.
Don’t get me wrong, GV’s 5 day sprint is a great method. But of course, what you seemed to miss is that you shouldn’t go into one completely blind. Yes, a lot of assumptions will need to be made, but user research should be guiding those assumptions. Not usability testing.
User research guides the product’s strategic direction.
Usability testing is great for iteration and optimization.
Moral of the story? You can’t iterate on a broken product.