Broadly agree. One thing I’ll add is that you should structure a “piece” around your points of highest uncertainty, and a common mistake I see is for companies to iterate on the wrong thing. Real examples from my career:
If you’re trying to make a large, offline data pipeline faster, then focusing on deploying to users is much less useful and typically slower than testing different performance improvements internally (and eventually pushing the best design).
Conversely, if you’re uncertain whether people will want a product in the first place, try selling preorders first
If your major uncertainty is whether certain libraries will do what you want, start by building out those components
If you’re trying to quickly get better at public speaking, practice a lot on your own! There are a lot of obvious errors and habits you can iron out. External feedback is more valuable, but also a lot more expensive – you can practice 10 5-minute talks in an hour by yourself, while you’ll probably only be able to do one in a Toastmasters group
If you’re a hedge fund, it’s worth quickly backtesting a lot of algorithms written in a non-production way (e.g. they run slowly and use a lot of memory) rather than insisting that everything be written to production standards before ever testing it
Oh, yeah, I should write a future principles memo on falsifying the most load bearing assumptions early. Agree that that is a really important aspect of doing small batches well!
Broadly agree. One thing I’ll add is that you should structure a “piece” around your points of highest uncertainty, and a common mistake I see is for companies to iterate on the wrong thing. Real examples from my career:
If you’re trying to make a large, offline data pipeline faster, then focusing on deploying to users is much less useful and typically slower than testing different performance improvements internally (and eventually pushing the best design).
Conversely, if you’re uncertain whether people will want a product in the first place, try selling preorders first
If your major uncertainty is whether certain libraries will do what you want, start by building out those components
If you’re trying to quickly get better at public speaking, practice a lot on your own! There are a lot of obvious errors and habits you can iron out. External feedback is more valuable, but also a lot more expensive – you can practice 10 5-minute talks in an hour by yourself, while you’ll probably only be able to do one in a Toastmasters group
If you’re a hedge fund, it’s worth quickly backtesting a lot of algorithms written in a non-production way (e.g. they run slowly and use a lot of memory) rather than insisting that everything be written to production standards before ever testing it
Oh, yeah, I should write a future principles memo on falsifying the most load bearing assumptions early. Agree that that is a really important aspect of doing small batches well!