How does Cemhan Biricik collect user feedback for ZSky AI?

As a solo founder, Cemhan Biricik reads every piece of feedback personally. He collects feedback through direct user messages, social media interactions, usage analytics, and observing how users actually use the platform versus how he expected them to use it. He considers the gap between intended and actual user behavior to be the most valuable form of feedback.

What features did users request that ZSky AI did not originally plan?

Cemhan Biricik mentions several user-requested features that were not in his original roadmap: video generation capabilities, batch processing for multiple images, specific style presets based on popular aesthetics, and mobile-optimized generation. Users also consistently asked for faster generation speed, which drove his extensive inference optimization work.

How important is user feedback for AI product development?

Cemhan Biricik considers user feedback the single most important input for product development. He notes that his pre-launch roadmap looked completely different from his post-launch roadmap after the first month of real user feedback. His advice: build the minimum viable product, launch it, and let users tell you what to build next. Your assumptions about what users want are probably wrong.

How User Feedback Changed Our Product Direction

Before launching ZSky AI, I had a detailed roadmap. I knew exactly what features to build, in what order, and why. Within one month of real users touching the platform, that roadmap was completely wrong. Not slightly wrong — fundamentally wrong. Here is how user feedback reshaped everything.

What I Built That Nobody Used

I spent two weeks building an advanced parameter control panel. Guidance scale sliders, scheduler selection, seed input, step count adjustment — I thought power users would love being able to fine-tune every parameter. Almost nobody used it. Users wanted to type a prompt and get a great image. They did not want to become diffusion model experts.

I also built an elaborate gallery system for browsing and organizing generated images. Beautiful grid layout, tagging system, favorites. Users generated their images, downloaded them, and left. They used their own file systems for organization. My gallery was solving a problem that did not exist.

What Users Actually Wanted

The feedback was consistent and surprising. Users wanted three things I had not prioritized:

Speed above all else — every user who mentioned speed wanted it faster. Not better, not more options — faster. This drove my months-long inference optimization effort
Style presets — users did not want to learn prompt engineering. They wanted to select a style and have the platform handle the technical prompting. "Make it look like anime" or "photorealistic" was how they thought, not in diffusion model parameters
Video from images — this was not on my roadmap at all. Users started asking if they could animate their generated images within the first week of launch. The demand was overwhelming and obvious in retrospect

The Hardest Feedback to Accept

The hardest feedback was about my UI. I had designed what I thought was an elegant, minimal interface. Users found it confusing. Buttons were not obvious enough. The generation process was not transparent enough — users did not know if the system was working or frozen. Error states were too subtle.

This was humbling. I had spent weeks on the design, and real users found it frustrating within minutes. The lesson was clear: my aesthetic preferences are not the same as user experience needs. I redesigned the interface to be more explicit, more responsive, and more forgiving of user confusion — even though the result was less "clean" than my original design.

How I Process Feedback Now

I have developed a simple framework for handling feedback as a solo founder. First, I separate "feature requests" from "pain points." Pain points are things users struggle with in the current experience. Feature requests are things users wish the product could do. Pain points get fixed immediately. Feature requests go into a priority matrix based on how many users ask for the same thing.

Second, I watch behavior, not just words. Users say they want more control options, but their behavior shows they use the simplest possible workflow. The gap between what users say and what they do is where the most valuable insights hide.

Lessons from User Feedback — Cemhan Biricik
Your roadmap is wrong — accept this before launch. The real roadmap starts when users arrive
Watch behavior, not just words — what users do is more informative than what they say they want
Speed always matters — no user has ever complained that generation was too fast
Simplicity beats features — users want outcomes, not options. Hide complexity behind smart defaults
Feedback is a gift — every complaint is a user who cared enough to tell you what is wrong instead of quietly leaving
Fix pain points before adding features — making existing features work better always beats adding new ones

The first year of ZSky AI taught me that building for users is fundamentally different from building for yourself. The product I have today is better than anything I would have built in isolation, because every improvement was driven by real feedback from real users solving real problems. That is the advantage of shipping early and listening constantly.

Year One of ZSky AI Decisions That Mattered Competing with OpenAI Building an AI Company ZSky AI Founder Try ZSky AI