Build first or sell first?
As long as the quality of feedback is greater than the time you put into building!
When it comes to product development: should you build first or sell first?
I've always been a big proponent of "sell before you build" when it comes to business or product development. It's something taught in YC and ingrained in me by Kyle/Bill when I was down at MIT with my first startup.
Always sell before you build. With anything I do, I always ask myself "what's the fastest way to test this?". Because I'm a mediocre developer, as a result, I've gotten rather good at wizard of oz and devising minimal tests.
However, more recently, I've been working with a fantastic engineer who's made me re-think and refine my mode of operating here.
At its core, the essence of the concept has not changed: do not overbuild. However, I believe there are cases where building more is not necessarily a taboo.
The spirit of this statement has its merits because there have been a ton of startups and products that have failed because it went into build mode and never got enough feedback from its customers on what they really care about.
At the end of the day, building products is a series of de-risking loops. Feedback is core to de-risking each stage as you refine your product.
Quality of feedback
Quality of feedback depends on the quality of question.
Depending on how you set up your test, the quality of the feedback you will receive varies. For example:
On one end of the spectrum, if it takes you 12 months to ship a beautifully end product. The feedback you'll get is exactly how users would treat your end product, because after all, it is the end product.
On the other end, if you were to just ask a casual question of: "wanna use this?". It takes practically no effort, but the answer you get might be a white lie or very hypothetical. This is because "this" means very differently in the customer's mind vs. your mind.
So, how much should you build before you seek out feedback?
It's a question of marginal return: how higher quality of feedback will you get from an extra hour spent on crafting your test or product? It likely follows an S-curve.
Prototype Fidelity vs. Feedback Quality
Similar to the Mendoza line, you want to make sure you're always want to make sure that you don't spend more time building than the quality fo feedback you're going to get from the prototype.
As you can see, "time spend on building" is a variable that is dependent on your skillset. If you're very good at coding and whipping something together, you can afford to build more than your average product engineer.
In fact, you'll have an unfair advantage where you can solicit good quality feedback where normally others would need to settle for lower quality feedback because they can't prototype as quickly as you can.
This is where speed and your ability to execute becomes a strategic advantage from a product development perspective.
In conclusion, because my friend is good and has the ability to build quickly, he has the luxury to build higher fidelity products than me. That's OK and actually net positive because it fetches back better customer feedback.
If I were in his shoes, I can't because the time it takes me to build the equivalent product would no longer be worth that same quality of customer feedback.