My First Product Demo Gave Me Two New Insights

I recently had the first truly important demo of my MVP.

I’m building CoTel, an AI service for analyzing Telegram chats and communities. The product is still at the MVP stage, without a public launch or a large audience.

A few weeks ago, an independent European media outlet became interested in the service. It started quite simply: a friend of mine works there, I told him about CoTel, and gave him access to test it a little. After that, they came back with a very specific request.

They needed a way to quickly find media files in local Telegram chats: videos, video circles, photos, and other visual materials, especially in situations where these materials can be deleted quickly by admins or by the users themselves.

My first thought was: subscriptions are a perfect fit.

The logic seemed obvious to me: the service regularly monitors selected chats, finds relevant media, and sends notifications. So I started building around that. I added media search, group requests across multiple chats, media-related filter.

Yesterday, I had the demo.

I showed the service to the journalist from that media outlet: how messages are pulled in, how media search works, and how they can request videos from specific chats for a selected time period. We ran a few live tests. Technically, everything worked well.

But the main insight was not technical. During the conversation, I realized that the subscription flow I had focused on was not actually the main thing they needed right now. I thought they needed constant monitoring.

In reality, their main workflow is different. During a specific event, they need to quickly run a manual request across many local chats at once, for example: “Show me all videos and video circles from the last hour across these 20 groups.”

Why this flow?

Because when an event happens, relevant materials start appearing in several regional chats almost at the same time. At that moment, the journalist needs to quickly collect all videos, see what appeared, pick the most important ones, and avoid wasting time on unrelated message streams. So they don’t need constant noise from subscriptions. They need a fast manual request at exactly the right moment.

That was a useful reality check.

I built a feature that I thought was the most logical solution to their problem. It is still useful, and I’m glad it exists in the product now. But only a real conversation with a potential user showed me which workflow is actually central for them.

Another interesting moment came up during the demo.

The journalist asked whether the service could also be used not only for local chats, but for large Telegram channels run by major international media outlets, for example to quickly find messages about a specific country or topic. For me, that felt obvious: if the source is in Telegram, CoTel can work with a local chat, a community, or a large media channel. But for a user seeing the product for the first time, this is not necessarily obvious at all.

I said yes, this use case is possible too. His reaction was: “Wow, that’s great.”

That became another lesson for me: you need to explain not only the main feature, but also adjacent use cases, even when they seem obvious to you.

A user usually comes with one specific pain. They are not supposed to mentally reconstruct every possible way your product could be useful. As a founder, it is your job to show concrete scenarios, explain the possibilities, and help the user connect the product to their real work.

In the end, the demo went well. I was told that the product does what they need, and now I’m being connected with the editor-in-chief.

My main takeaway from this demo: you cannot fully invent a user workflow in your head.

Even if you understand the problem, the market, and the pain point, you still see the process from the outside. The user lives inside that process every day. And often, the difference between a “useful feature” and a “real working tool” only becomes visible during a conversation and a live demo.

After this demo, I’m even more convinced that at the MVP stage, building the product is only half of the work. The other half is talking to different types of potential users again and again.