From zero to 300,000 users.
Launching an AI product from scratch is fun. Then people actually start using it.
I owned product as Nuur went from an idea to a live consumer AI product and scaled to 300,000 users, making the calls on what to build, what to ignore and how the product needed to change as real market demand replaced our assumptions.
At a glance
The problem
Early-stage products have no shortage of ideas. The problem is working out which ones are actually a product.
We were building in a fast-moving AI market where user expectations were changing almost as quickly as the technology. There was pressure to move fast, but shipping everything people asked for would have created a very busy roadmap and a very confused product.
My job was to keep the team focused on the user problem, turn demand into decisions and make sure speed didn't become an excuse for chaos.
Finding the signal
At the beginning, assumptions are cheap. Real behaviour is better.
I used a mix of direct user feedback, market signals, product usage and the questions and friction showing up around the product to understand what people actually valued.
The important part wasn't collecting feedback. It was separating three very different things:
- what users said they wanted;
- what their behaviour suggested they needed; and
- what was worth building as a scalable product.
Those aren't always the same thing.
Turning demand into a roadmap
A growing user base creates a dangerous illusion that everything is urgent.
I prioritised around the product's core value, evidence of demand, expected impact, delivery effort and what we needed to learn next. Features weren't promoted because somebody asked loudly enough. They needed a reason to exist.
That meant saying no, cutting scope and sometimes shipping a smaller version first so we could learn before committing more engineering time.
Making it buildable
Once we knew what deserved to exist, I turned the fuzzy version into something the team could actually build.
That meant defining the user need, expected behaviour, edge cases and acceptance criteria clearly enough that engineering could challenge the solution rather than guess the problem.
I stayed close to delivery, clarified requirements quickly and adjusted when technical reality gave us better information. The point wasn't to hand developers a perfect document. It was to maintain a shared understanding all the way to release.
Ship. Watch. Change it.
Launch wasn't a finish line. It was new information.
As usage grew, we used what users did after release to decide what needed improving, simplifying or deprioritising. The roadmap moved with evidence rather than being protected because somebody had once put it on a slide.
The result
The product grew from concept to a consumer platform used at scale. More importantly, the product process grew with it: from early assumptions and fast experimentation to increasingly evidence-led prioritisation as the user base expanded.
What this project taught me
Speed and product discipline aren't opposites. In an early-stage company, the discipline is what lets you move quickly without spending six months building yourself into a corner.
The biggest shift is knowing when to stop treating an idea as precious. Once users arrive, their behaviour gets a vote.