I learned this after spending almost three weeks improving a product that barely had any active users. At the time, I thought I was making progress. I added a better dashboard, redesigned the settings page, introduced a few customization options, and started working on a feature I was convinced would make the product feel more complete. Every time I finished something, I felt productive. Then I checked the analytics. Almost nobody was using the new features. The people who were already using the product were still doing the same three things they had been doing before. One of them had even sent me a message asking why I hadn't fixed a small issue in the existing workflow. I had spent weeks making the product bigger while ignoring the parts people were actually touching. That was a difficult realization. When you're building an MVP, adding features feels safer than talking to users. You can sit alone, write code, redesign screens, and convince yourself that the next improvement will finally make the product click. But sometimes you're just avoiding the uncomfortable work of finding out whether anyone really needs what you're building. I eventually stopped adding new features for a while. I went back through user feedback, watched how people used the product, and focused on fixing the problems that were already showing up. The product didn't suddenly become successful. I just stopped confusing activity with progress. An MVP doesn't need to impress you with how many things it can do. It needs to solve something useful for a small number of people, well enough that they have a reason to come back. Everything else can wait.
Ihsane Abdou@ihsaneabdou
0Products
Head of Growth @Pipecorn
Building doesn't have to be hard
Ihsane's Posts (1)
The fastest way to kill an MVP is to keep adding things nobody requested.