[hgl]

> Going from 50% chance of making something useless to 25% - by seeing how users react to your product - is worth increasing the chances of a copycat from, say, 1% to 2%

This is a very good argument for not worrying about copycats during MVP. I'll keep that in mind.

But what about users? You talk with users, and tweak the product accordingly, they like it, and then they want a new feature, and it's also on the feature list, but very difficult to implement. What do you do? Just make them wait as long as it needs or should I make sure that before releasing a MVP, I at least have the technical capacity to implement all the features that are challenging (at the cost of delaying shipping, probably significantly)?

I forgot to mention my averse to making users wait is also part of what worries me. I wonder if such concern is warranted?

[troydavis]

> Just make them wait as long as it needs

Yup[1], or explain to/convince them they don't actually need the feature, or use the money paid by happy customers to pay someone to implement it, or conclude that demand is so strong that it's worth raising capital to serve them sooner.

Operating a business is doing that over and over, hundreds of times, for years.

Especially for a bootstrapped business, the need to do that will actually _increase_ during the business's lifetime - and that's if you're fortunate. When you no longer need to tell even more prospective customers "No," that's an early sign that you're serving almost the whole market and that growth (and the chance to solve neat problems) will slow down.

If you're succeeding, lots of prospective customers will always want something you don't have. There will always be larger companies that could - and you believe should - easily invest more in your field than your whole business spends.

Here's a personal example. I ran a log management service that had no graphing/visualization service - for 5 years. It launched way back in 2012 (https://www.businesswire.com/news/home/20110609005940/en/Clo...). If you'd asked me then whether it wouldn't get native graphing until 2017 (https://blog.papertrailapp.com/lightning-search/), I'd have said you were crazy - maybe even that it wasn't possible to exist that long without it. In those 5 years, I probably addressed that topic 500 times. Sometimes I explained why it wasn't necessary to solve the prospective customer's problem, sometimes I stated that my product wasn't a good fit, sometimes I tried to reduce the need for that feature (like by supporting external graphing services, which was a small enough amount of work that our tiny team could implement a great version: https://blog.papertrailapp.com/new-search-alerts-dashboard/).

But… our choices were sound and they worked out (though I assume there were >1 viable paths, not just the route we took). We had tons of demand for the problem we solved well, a very tiny team, and kept doing what I wrote in the first paragraph. You don't need to be able to solve all the problems for all the people, or even most of the problems for most of the people. You definitely don't need to be able to see the future. As long as you know precisely what customers want, why they want it, and how they value it ("We're paying someone to do this by hand and it's expensive and buggy" vs. "It would be cool if…"), and are constantly talking about and adapting to that information, the rest tends to work out.

37signals is the extreme version (100:1 no:yes?), but every other bootstrapped product business and many funded ones all do the same thing.

The way to get better at resource allocation is to do it over and over. Even if your first few products fail, there's always a next time - and it's easier when a failure takes 6 months and not 3 years :-)

[1]: https://signalvnoise.com/posts/1050-ask-37signals-how-do-you..., https://rework.fm/say-no/