Day 524: Prioritizing feedback

product

Two weeks after I started working on Browserflow, I put together this demo that showed off the core functionality. Crazy that it only took me 2 weeks to make that much progress.

Since then, Browserflow has come a long way and gained a ton of new functionality, but the rate of improvement has definitely slowed.

Back then, I decided not to open Browserflow and make it available because I knew that I’d be making breaking changes and it’d be harder to coordinate if I had more users.

In retrospect, I should’ve published Browserflow when I made that demo two weeks in even if it meant having a harder time making breaking changes for one reason: user feedback.

While people in the closed beta have provided useful feedback, most of Browserflow has been designed specifically for me. That’s fine, but it definitely would’ve been useful to continually get feedback throughout the development process.

Note for next time: Get product in front of users early and iterate rather than building something for a long, long time mostly privately. Prioritize feedback, preferably from paying customers.

Reasons to get users as early as possible:

  1. Get feedback from people actually using your product

    • Makes sure you’re solving real problems rather than imagined ones

  2. Build trust from people seeing you improve the product over time

  3. Much easier marketing from people talking about your product and willing to provide testimonials/case studies