Better Product Design (by Intentionally Growing Slow)

I'm still pre-launch, and I love the fact that I can completely re-arrange the UI/UX if I feel like it's not working right. It's going to be harder post-launch, and even harder when there are (hopefully) lots of users.

That's probably the harder decision to make when building a product. Should I rush and build an MVP real quick to be out - even if it's half-finished and buggy.
Or should I slow down, take my time and launch only when the product is polished?

I think the truth is in the middle! At logology we choose to clearly slow-down, take our time to build a product users will love!
It's tough, we all want to go faster, but I think that's a good strategy if you want to build something in the long-term.
Also, we often read "nobody cares about your design, validate your idea first". I'm kindly disagree, the UI/UX is a big part of your message!

So yep, slow down, make something beautiful that users will love. But don't get lost, you need to launch one day or another (and the sooner, the better!)

I appreciate that you're being thoughtful when implementing solutions, it'll help avoid bloat and save resources. On the other hand, I think what you don't mention here is that you can iterate very quickly in the design phase and generate many solutions and test them without building. Being too clinical about your design decisions will lead to a narrow range of possible solutions and hurt the product. Quick to generate ideas to test, slow to pick the best solution.

Totally agree with this, we've taken the same approach and it's worked really well so far.

We kept our first beta really small and intentionally launched as a paid app to pre-filter users and keep numbers lower. It ended up being 12 months before we made the move to freemium and the larger user numbers that come with it.

Exactly as you say I'm convinced if we'd launched freemium straight away it would have been much more difficult to filter through the noise and much more discouraging with larger volumes of people constantly picking out the negatives.

It's also a lot harder to make major changes to the UI/UX when you have a large user base to account for and I'm so glad we were able to make those changes with smaller numbers of users.

Great post 👍

Seems somewhat related to my experiences - I built kind of a "social platform" as an unexperienced dev. I tried to follow best practices, but obviously when you're new to something you just iterate until things work.

I finished building it, and the UI/UX seems good. Made it free because it will take time to build up the content until i provide enough value to start charging. I began marketing it in a single channel I defined earlier (the only free channel i know for this..) and started getting free users.

After launching and starting the marketing efforts I stopped developing for it, I put 100% focus on marketing and building the value.

I never maintained a project like this before, so I'm just doing what seems right to me..

That's what I also think is the best way to go as you work into getting those 100 users that LOVE you while doing things that don't scale.

I really like this - and it is counter to all of the big VC ways of thinking, but that is because there is a different narrative, with a different goal.

We end up believing the hype - rapid growth, rapid scale - and get caught up in that loop to our own product, and personal, detriment.

We launched and have had a small subset of our initial user list dance through the app and they found bugs and workflows and concepts that didn't communicate well. But we also don't have 1000 customers breathing down our necks (yet) to solve those and we can take the time to get it right-ish.

At first, this slow, small approach made me nervous but feeling more and more that there is a sweet spot between "move fast and break things" and "sous vide slow cooking".

Thanks for sharing.