On faster real-world launching, iteration, sunk-cost, bandwidth to pivot

Continuing the discussion from Feedback wanted re pledge suspension, auto-drop, etc:

Just wanting to express this tension:

The more investment that we put into perfecting a particular design, the more we might feel invested in that and unable to afford the cost of pivoting.

In this case, I mentioned the difference between monthly-budget-cap versus one-time-fund-authorization as the two ways to give a hard budget limit to patrons.

Even if we’re pretty sure that one approach is superior, it will take some real-world, working-system evidence to be conclusive. So, what if we pick wrong?

Maybe it’s still worth all the investment because all our work helped us refine the design process and learn etc. so that we’re that much more able to do a great job with a different design when we pivot… or maybe it’s more tragically costly to optimize our design so much prior to launching and validating (or invalidating) core principles that the design used?

So, I just urge us to keep in mind that what we want isn’t a perfect design but instead, we want a design that works well enough that if we launch with it, we can be confident that various successes and failures are insightful. (Obviously, a design that’s just too confusing or badly structured won’t be an adequate test of the principles. E.g. a monthly-budget-cap approach that users don’t understand won’t validate or invalidate that approach.)

In conclusion: As an example, consider the possibility that real-world experience will prove that one-time-authorization is a truly better path to success over monthly-budget-cap. All work on monthly-budget-cap should be considered in terms of helping us make that effective enough to have the real-world experience that will prove it or not. We should avoid investment beyond that to avoid excessive lock-in to that assumption in case we need to pivot.