Esports Platform

The initial concept brought together many things an esports fan might want: event information, team data, game insights, and historical statistics.

Each part had potential value, but together they could easily become a large platform without a clear starting point. Before defining screens and features, we needed to make the assumptions behind the idea visible.

We used the Lean Canvas to describe the audience, the problem, the proposed solution, and the possible business model. This gave the team a shared starting point and exposed questions that still needed evidence.

The next step was to connect the broad platform idea to something people would actually find useful.

We used a Value Proposition Canvas to examine what esports fans were trying to follow, which parts of the existing experience caused frustration, and what kind of information could make watching and exploring matches more engaging.

This helped move the discussion away from a general promise of “all esports data in one place” and towards a more concrete product value.

We combined qualitative and quantitative research to examine whether the proposed experience matched how people followed esports.

The research focused on user behaviour, motivation, preferred types of information, and the relative value of the proposed features. It helped us compare the initial assumptions with what potential users actually considered useful.

The evidence was encouraging enough to continue, but it also showed the need to narrow the concept. We used the findings to prioritize the functional core of the MVP.

The discovery work gave us a clearer MVP scope. It needed to be small enough for an early-stage team to deliver, while still containing enough of the core experience to test whether the platform was worth developing further.

The aim was to learn whether esports fans saw value in a combined viewing and data experience before committing to a larger product.

The MVP gave us enough confidence to launch the product and continue developing the wider platform. At that point, the main uncertainty shifted from whether the experience had value to whether its technical foundation could support further growth.

The team was designed to grow in stages rather than being staffed immediately for the complete product vision.

At the MVP stage, one UX/UI designer covered the initial product needs. For the beta release, we added a graphic designer to create the visual content required by the platform. As the project moved towards a more complete product, the team expanded to two UX/UI designers and two graphic designers.

The hiring plan focused on junior and junior-middle designers who showed strong visual skills, product thinking, and a genuine interest in gaming. Because the team was still developing professionally, mentoring and onboarding were part of the staffing strategy from the beginning.

I created role-specific job descriptions, reviewed portfolios and applications, prepared practical test assignments, and conducted interviews. New designers received individual development plans and regular mentoring after joining the team.

The product launched and reached real users. The core experience worked well enough to continue development, and the design team grew with it.

The main constraint appeared as we tried to scale. Much of the product depended on real-time data from third-party APIs. As the number of sources, updates, and features grew, keeping that data reliable became increasingly difficult.

Data was the foundation of the experience, so this became a product-level problem. The platform worked at its initial scale, but the technical model could not support the larger product we had planned. Development eventually stopped.

We had tested the value proposition and defined a workable MVP. What we had underestimated was scalability. Today, I would treat the data architecture as a core product hypothesis much earlier and test how it behaves under growth before expanding the platform around it.

The project changed how I look at technical dependencies during discovery.

A product can work, launch, and reach users while still carrying a constraint that only becomes visible at a larger scale. In data-heavy products, infrastructure is part of the product itself.

Since then, I try to identify early which dependency could become a limit on the product later.