What rang particularly true to me wasn't harder work feeling more rewarding, but that people are willing to work longer and for less direct pay when they see that their work is valued or at least not immediately discarded.
Yes exactly. In the startup world, we build products for users - they are the ultimate arbiters of a product's value. It doesn't matter whether the value is delivered by working two weeks or two years - all that matters to the user is the value delivered.
So smart founders should find ways of getting to that value delivery point via the shortest, cheapest most efficient path. Because that way you win over your competitors who might not.
BTW, this is also why companies led by technical founders often beat those that are not. If you're a non-technical founder, you are beholden to the techno-priesthood, which may care about building things in the most perfect way, which often ends up being an inefficient path.
Note that this is not meant as a knock on writing good maintainable and elegant code. It is more an affirmation of minimizing work that does not move you closer to the point of value delivery for your user.
> "Embrace simplicity in your product and in your code. The value is in what gets used, not what gets built."
There are all sorts of values. Usage value is only one of. If all that gets built is judged by what gets used, then a lot of great things won't get built.
There is a huge difference between building a product/startup and building something for the sake of building it. The first almost exclusively lives or dies by the value perceived by its users.
there is also marketing value. features that may rarely get used but many potential customers won't give your product a second glance if you don't have them.
Questions applicable to every hard working startup:
+ Do we solve a real problem?
+ Do we have customers who find our solution useful?
+ Can we make enough money to make our solution a sustainable business?
Questions for the execution team:
+ Will we know when and how people hear about our solution?
+ Will we be able to understand if and how they use our solution?
+ Can we change things quickly enough to improve our solution (based on learning)?
+ Can we measure the quality (usage) of our changes?
+ Can we reduce amount of work and test for need earlier (think MVP)?
What rang particularly true to me wasn't harder work feeling more rewarding, but that people are willing to work longer and for less direct pay when they see that their work is valued or at least not immediately discarded.
0: http://www.ted.com/talks/dan_ariely_what_makes_us_feel_good_...