ibuildinpublic
Log inStart free
ibuildinpublic
Log inStart free
BuilderProductExperiences1Requests1

How I Built a Better Product by Listening to My Users

How to/GuideOct 10, 2026
Ehsan

by Ehsan

@acadictiveLvl 7·Active Builder

Five months ago, iBuildinPublic was an idea I could explain in one sentence and a product I could barely defend in a conversation.

After more than 60 builders gave me feedback, here is what I learned about improving a product with early users.

1. Show your product to real users early

I started sharing iBuildinPublic with early users and beta testers. Around 9 out of 10 had neutral or negative feedback.

The design felt unfinished. Some features were confusing. Performance was slow.

It was uncomfortable to hear, but it gave me a clear starting point. I could finally see the problems through the eyes of people who might actually use the product.

How to do it: Share your product before you feel ready. Ask people to try it and tell you where they struggle.

2. Ask questions and listen carefully

My first instinct was to defend my decisions. Sometimes I wanted to change random things and ship again, hoping the next person would like them.

I learned to ask follow-up questions instead.

When someone struggled with a feature, I wanted to understand exactly where they got lost and why. More than 60 builders have shared feedback through calls, DMs, and group chats. Every conversation helped me understand something new.

How to do it: When someone points out a problem, ask them to explain what they expected to happen and what actually happened. Write down their answers.

3. Fix one problem at a time

I shipped a lot of changes during these five months. Looking back, some were unnecessary.

The biggest improvements came from smaller feedback loops: show someone a change, watch them use it, identify the next problem, and repeat.

Sometimes, the right improvement was a confusing button label. Sometimes, it was making a page load faster or improving mobile navigation.

How to do it: Pick one important problem, fix it, and test the solution with someone who represents your target user.

4. Look for patterns across feedback

Different builders wanted different things. Some struggled with navigation. Others wanted clearer help posts or more confidence about who would see their content.

I could not implement every suggestion. I had to understand which problems appeared repeatedly and which ones mattered most to the people I wanted to serve.

How to do it: Keep a list of feedback, group similar problems together, and prioritize based on how often they occur and how much they affect the user experience.

5. Treat performance and design as part of trust

People need to feel comfortable sharing their work on a new platform.

A cluttered interface, confusing navigation, or slow page can make someone hesitate before creating an account or sharing a link.

I spent a lot of time improving these areas because they directly affected how people experienced iBuildinPublic.

How to do it: Test your product on mobile, watch new users navigate it, and pay attention to every moment that makes them hesitate.

6. Thank people and keep them involved

More than 60 builders have helped me improve this product. Some became friends. Some disagreed with each other. Many gave me their time without expecting anything in return.

I started treating every call and detailed message as an opportunity to learn. Over time, people began sending more feedback and following the product's progress.

How to do it: Thank people for their time, show them what changed because of their feedback, and invite them to test improvements.

7. Measure progress through real feedback

Three days before launch, the feedback had changed. Around 9 out of 10 people were telling me the platform felt clear, useful, and worth sharing with other builders.

That feedback gave me confidence that the work was moving in the right direction.

Five months of building, testing, listening, and improving brought iBuildinPublic to this point.

Final thoughts

If you are building a product, start talking to users as early as possible. Listen carefully, fix real problems, and repeat the process.

You do not need 60 people to begin. Start with five. Watch them use your product. Learn what confuses them. Make things better.

That is how I built iBuildinPublic, and it is a lesson I will carry into every product I build.

Thank you to everyone who helped me get this far.

LikeImpressions
Bookmark
Sign in to reply

No replies yet. Be the first to reply.