Spent last year working on a side project and assumed I would need this and that in order to launch. But after it was ready to launch, I found out there was no product market fit. I have known about the importance of quickly finding out pmf but still made the mistakes. knowing != doing. We just love building stuff and mistakenly convince ourselves that if I add one more feature, this thing would be ready for launch and take off. But in reality...
It’s a good lesson. We found PMF with a shared google sheet and a bit of data processing behind the scenes. The level of polish I’d come to expect as an engineer at an enterprise company was astronomically higher than what was actually needed for our customers to give us their dollars.
>In my experience reducing features is better to begin with.
This is right approach. Lean. If you don’t have PMF, reduce your features until you find it. Pivot. Maybe pivot again. Eventually you’ll find a market to serve. Just don’t fall into the sunken cost fallacy. Time box your market exploration.
As a freelance back-end developer with various co-founding experience this question speaks to me. I think it's all a matter of perspective.
Looking at it from a development perspective the two can mean the same thing: we pivot and so we need to add new features.
However, in my experience the key is to look at pivoting from a non-development perspective. As mentioned in parent comments you pivot to find a product market fit. That entails finding your audience and the problem you're solving for them. Those questions do not require a product, but a human understanding. Questions like 'is it actually a problem they need solving, or a slight convenience?' and 'how are they solving their problem without my product?'.
By pivoting quickly in that space you don't get bogged down by technical issues or challenges that don't even matter, and the real solution might be a week's worth of time.
Pivoting involves picking a different problem to solve. Or who to solve it for. Or rarely, a radically different way to solve it (usually involving starting anew).
Features and other product work is tweaking on the solution side, assuming there is nothing wrong with the chosen problem.
Thanks for posting this insight, because a typical engineer, if they are worth their money, does not like the idea to launch something "unfinished" or "half-baked" or even "not yet perfect", but the business logic behind the MVP (minimal viable product) is clearly correct.
Have to disagree (although this may be a "no true Scotsman" disagreement).
I think a typical engineer is more likely to want to evolve towards mature software in small steps. In my experience the "complete it, then release it with a big splash" approach is more likely to come from marketing. "We moved the CTA up the page a bit" isn't the stuff of press releases.
It is definitely hard to break the "but... I'm a professional" mindset. It is good to remember that your code isn't you. If you get PMF, just re-write everything from scratch.
As an argument on the other side - so long as you're making enough to live comfortably enough, then there's no real need to abide the business logic though, even if you think it absolutely does maximize income in the longrun. If you spend years working on something and it turns out somehow nobody else likes it, well at least you have something that you're presumably satisfied with, and you often learn an immense amount in process.
Careers that aren't quite so commercialized regularly carry out this process. The obvious example being writers where you may spend months/years writing a book only to find out that nobody wants to publish it. Or perhaps you ultimately just don't like it. I know Andy Weir (of "The Martian" fame) wrote about 75,000 words on his next novel before deciding he just didn't like it, and scrapped the entire thing.
Yes, agree. Definitely, follow your heart. My comment is aimed more at the situation where your curiosity does lead you to a desire to create a successful product.
