What a ten-person studio taught me about product management

From September 2024 to May 2025 I co-founded and ran Keypix, a digital product and web development studio in Tashkent. There were ten of us across design, development and the business side, and we shipped more than 40 websites, web applications and Telegram bots for businesses. I sold the work, hired the people, held the budget and set the technical direction.

A studio is not a product company. But running one is a fast course in product management, because every week you make the decisions a product manager makes, and the cost of a wrong one comes out of your own budget.

Discovery is a sales skill

Most clients arrived with a solution: “we need a website”, “we need a bot”. The useful first call was the one where we found out what had to happen for the business: more orders through Telegram, fewer calls to the office, a price list customers could find on their phone. Often the right answer was smaller than what they had asked for. Selling the smaller thing honestly is how you get the second project.

Scope is a budget, not a list

After forty-odd projects you learn that every extra feature is paid for with someone's week. We promised short delivery, often three to seven days for a site or a bot, and the only way to keep that promise was to agree on what the first version would not do, in writing, before work started. That “not now” list is the most useful document in any project, and the one most teams never write.

The real roadmap is who works on what this week

With ten people and several projects in flight, the plan that matters is how the people are allocated. A designer waiting for a client's texts costs more than any feature. I learned to plan the week around bottlenecks: the content we did not have yet, the answer we were waiting for, the review only I could do.

Technical direction is choosing what not to build

Two years of writing front-end code helped: I could tell when a request was an afternoon and when it was a month. The bigger lesson was reuse. A studio that rebuilds the same login, the same catalogue and the same payment step for every client turns into a queue. Reusing what already worked is what made short delivery possible.

Stay close after launch

Launch is the moment a client starts using what you built, and the first week shows what the brief missed. In my experience, staying in touch after launch is what turns one project into the next.

Why I closed it

I hired ten people before revenue could carry them, and I did not plan the cash flow: salaries are due every month, while clients pay by project. After eight months I had to close the studio.

The lesson was not about design or code. I am better at building products than at running the finances of a small business, and I add more value in a strong team than as an owner. What stayed is a habit: every idea now starts with its economics — what it costs, when it pays back, and what happens if the money arrives a month late.

What I carried into product work

• Ask what has to happen for the business before discussing what to build.
• Write down what the first version will not do.
• Plan around bottlenecks, not around the backlog.
• Reuse what works. Novelty has a cost, and someone pays it later.
• Stay close to the people using what you shipped. Most of the value is in the second release.
• Start with the economics: what it costs, when it pays back, and what happens if the money is late.

In May 2025 I joined a US logistics software company as a full-stack developer. Three months later I was its product manager, and these lessons are a large part of why.