For me the biggest challenge I face as a technical founder is programming. To be more specific: stopping programming. For years I have measured my progress by ticking off features delivered, bugs fixed or user stories completed. It’s a well understood system and it’s easy to track, but that’s not what I should be doing. My job as a founder is to find a repeatable business model that will make money, and the only route to achieving this is via validated learning.
This has, by far, been the hardest lesson for me to learn. I know the phrases and sayings. “Don’t build what you can leverage(wryly: steal)” “What’s the simplest thing possible?” “Do less” I’ve read all the stories of others that have been burned by this. And all the others that interpret it wrongly by rallying against the mantra “Fail fast”.
But it’s really another thing altogether to internalize it and to be it.
Sadly, it’s one that many, many founders fall into the trap of. As PG has says in this essays, this is the one area where our intuition fails us. You almost have to be brazenly indifferent to bad craftmanship, unleashing an incomplete experience to users, and looking the fool, BUT with the caveat that you can always iterate.
The only thing that’s a sure cure is, well, making the mistake and seeing the specific instance of why you thought that you couldn’t launch without feature X or design Y. Regardless of whether you’re launching to users or preparing for an investor meeting, many many times, you really don’t need that feature
My cofounder’s weakness is to want to put in new features that the most recent feedback talked about. My weakness is to want to engineer it the correct way the first time, or built it at all, for that matter. Both habits we guard each other against.