In short
- Problem
- How do you own eleven products at once — across fintech, Web3, gaming and payments — without any of them drifting from the user or the architecture?
- Constraint
- One person, eleven products, four verticals, and no prior definition of the job. Live products with millions of existing users and no appetite for a rebuild.
- Decided
- Earn the roadmap with research before writing it. Design the platform once and ship it five times. Set go/no-go criteria before the test. Standardise the portfolio's operating system, not just its roadmap.
- Rejected
- Designing each game as a self-contained experience — five wallets, five referral systems. And shipping two failed features anyway in reduced form, which was available and would have kept both sponsors happy.
- Hardest
- Killing two features against pre-agreed criteria, and spending the goodwill of the teams that lost on purpose to buy honest planning.
- Outcome
- 20% faster time-to-first-action, 12% D7 retention, 15% feature adoption, 3× retention on the activated cohort. Promoted into a role that did not exist before.
Question
How do you own eleven products at once without any of them drifting away from the user or the architecture?
I joined as a designer responsible for consumer gaming applications, internal operational tools, payment interfaces and corporate web experiences. Five months later I was promoted into a product management role that had not existed at the company before.
Eleven live products across four verticals — gaming and Telegram Mini Apps, fintech and payments, enterprise AI, and corporate and internal systems — had been shipped by engineering and design working directly with leadership. That works until the portfolio is large enough that nobody can hold all of it, and priorities start being set by whoever asked most recently.
UI/UX Designer, Sep 2024 — Jan 2025. Product Manager, Feb 2025 — Apr 2026.
Constraint
One person, eleven products, four verticals, and no prior definition of the job.
Consumer games and cross-border payments do not share a user, a release rhythm, or a regulator. Spreading one product manager evenly across eleven products produces eleven equally shallow roadmaps and a person who cannot answer a hard question about any of them.
So the constraint forced the real question early. Not how to serve every product — how to decide which ones deserved the attention, and how to say that out loud to the teams that lost.
The second constraint was growth. Across those nineteen months the product ecosystem grew from approximately one million users to more than four and a half million. Designing for that meant every decision had to carry performance, operational efficiency, monetisation, retention, technical complexity and long-term maintainability at the same time — the point at which you stop shipping features and start shipping systems.
Decision
Eight decisions. The one that mattered most was to stop designing products and start designing the thing underneath them.
Decision 01
Earn the roadmap with research before writing it
Before taking the product title, I spent the first months running behavioural research across all eleven products to build an opportunity backlog. It surfaced three critical adoption blockers, and those three set the first six months of roadmap — my opinion did not. Feature adoption rose 15% off the back of it.
The backlog did a second job that mattered more. A role nobody has held before is illegible to the people around it; a prioritised, evidence-backed backlog made the job legible on the day it started, which is worth more than any amount of explaining.
Traded away: months of visible output at the exact moment a new role is under most scrutiny.
Decision 02
Design the platform once and ship it five times
The gaming portfolio was not a set of games. It was an interconnected platform of Telegram Mini Apps built around cryptocurrency rewards, virtual economies, referrals, advertising, wallet infrastructure and player engagement — and every one of those games needed the same substrate.
So I designed the substrate as its own product and let the games sit on top of it:
Authentication and onboarding — Telegram login, first-run onboarding, account management, daily rewards. Wallet infrastructure — TON wallet integration, deposits, withdrawals, balance management, transaction history. Social — friends, referral programs, referral tracking, invite flows. Retention — daily rewards, the task engine, progression, booster mechanics, notifications. Monetisation — the booster store, advertising tasks, TON purchases, withdrawal workflows, reward multipliers. Player profile — statistics, earnings, and the referral, booster and withdrawal histories.
Designing these once cut duplication, sped up development on every subsequent title, and meant a player moving between games did not have to relearn how to withdraw their money. On a five-product ecosystem the shared layer is not an efficiency; it is the product.
Rejected: designing each game as a self-contained experience. It is faster per title and it produces five wallets, five referral systems and five different answers to "where are my earnings."
Decision 03
Share the architecture, not the identity
The corollary, and the harder half. Arc8 Retro is a nostalgic arcade platform built on 1980s and 90s console cues. Arc8 Modern is cyberpunk, aimed at a newer generation of casual mobile players. They look nothing alike — and they run on the same underlying platform architecture, so a user can move between them without relearning anything structural.
Standardising the systems while deliberately not standardising the visual language is the decision. A shared design system that also enforces a shared aesthetic would have produced five products that felt like one product with five skins, which is exactly the thing that makes a games portfolio feel cheap.
The full record — decisions 04–08, the gaming ecosystem, the portfolio, scale The complete record · about 1,900 words
Decision 04
Build a KPI framework so prioritisation had a shared denominator
I established a KPI framework across activation, engagement and monetisation funnels. The point was not measurement for its own sake — it was to make roadmap arguments resolvable. Two teams can disagree about importance indefinitely; they cannot disagree about a funnel they both agreed to instrument.
Then the cohort analysis that came out of it changed everything downstream: users who completed a key activation action within 48 hours retained roughly three times better. That single finding reshaped prioritisation across the portfolio, because it turned onboarding from a design concern into the highest-leverage surface anyone had.
Decision 05
Set go/no-go criteria before the test, not after
POCs and MVPs were validated against structured criteria agreed up front. Two features failed them and were killed, and the engineering capacity moved to higher-impact work.
Deciding the bar in advance is the only thing that makes killing a feature a decision rather than an argument. After the fact, every disappointing result has an explanation and a sponsor; before the fact, it has a number that everyone already signed.
Rejected: shipping both features anyway in reduced form, which was available and would have kept both sponsors happy.
Decision 06
Standardise the portfolio's operating system, not just its roadmap
A single product manager across eleven products only scales if the products share machinery. So a significant share of the work was infrastructure for the work itself.
On strategy: a portfolio roadmap aligned to company objectives, standardised development frameworks across all products, portfolio-level KPIs for consistent measurement, and deliberate cross-product synergies. On execution: structured feedback loops between product, engineering and design, clear handoff protocols, standardised documentation and communication frameworks, and cross-team knowledge sharing. Administrative routine was automated where it could be, documentation templates standardised, agile tooling brought in for visibility, and knowledge management centralised. On repeatability: playbooks, standardised research methodologies, performance monitoring frameworks, and QA and testing protocols that a new product could adopt.
The measured return was 30% better handoff efficiency between teams, 40% less administrative overhead, and 25% less sprint variance through tighter scope control. Sprint variance is the one to read: it means commitments started matching delivery, which is what lets a roadmap mean anything.
Alongside it, the full documentation stack the role needed to be credible — PRDs, user stories, acceptance criteria, QA test plans, release notes, roadmaps, technical architecture documents, compliance questionnaires and executive presentations — plus design standards carried across products as component libraries, typography systems, design tokens, interaction patterns, layout and responsive guidelines, and developer documentation.
Decision 07
Concentrate on the products that mattered, and say so
A minority of the eleven took the majority of the attention. The others were maintained deliberately rather than developed.
Saying that plainly to their stakeholders was a harder conversation than any technical one that year, and it is the decision I would defend most strongly. Undeclared deprioritisation is the same allocation with worse information: the team still gets less of you, and now they are also planning around a lie.
Traded away: goodwill from the teams that lost, spent on purpose to buy honest planning.
Decision 08
Follow the work down into the architecture
The role kept pulling toward technical decisions, and I let it. Backend architecture discussions, API design reviews, database planning, cloud infrastructure evaluation, AI integration strategy, vendor selection, performance and scalability planning, and cloud cost optimisation.
Vendor evaluation alone spanned seven categories — OCR providers, banking infrastructure, KYC vendors, payment processors, multi-currency IBAN providers, AI tooling and blockchain infrastructure — each with its own failure modes, none of which a single product would have taught me.
I also stayed in the delivery lifecycle rather than handing off at spec: functional and regression testing, UX validation, release-readiness reviews, cross-platform verification, bug prioritisation, production validation and post-release monitoring.
This is the part that turned into the next job. Nothing about writing specifications prepares you to be a CTO. Arguing about infrastructure cost as a product decision does.
The gaming ecosystem
Five Telegram Mini Apps, each with its own audience, all standing on the same platform.
String Games — complete redesign
The flagship multi-game platform, bringing Crash, Mines, Dice and Limbo into one Telegram Mini App. I led the complete redesign across both experience and product structure: information architecture, navigation, the full user flows, high-fidelity UI, the profile experience, wallet integration, the TON withdrawal flow, the store, the booster system, referrals, daily rewards, the task system, responsive layouts, design-system integration, developer handoff and design QA.
The work beyond the visual pass was the useful part: reducing friction across the player journey, improving discoverability, and making gameplay, monetisation and social features feel like one product rather than three bolted together.
Arc8 Retro — complete product design
A nostalgic arcade platform inspired by 1980s and 90s consoles, carrying Snake and Space Invaders alongside daily rewards, wallet management, referrals, tasks, a store, boosters and withdrawals.
The central design problem was specific and genuinely hard: integrating blockchain payment flows into a nostalgic experience without breaking the aesthetic. A crypto withdrawal screen is a modern object with modern affordances, and dropping one into a deliberately retro interface is the point where most themed products give up on the theme.
Arc8 Modern — complete product design
Cyberpunk visual language for casual mobile players, carrying Doodle Jump, Stack and Flappy Bird. Navigation, user journey, visual identity, wallet integration, the reward economy, profile, tasks, store, referrals, withdrawals and boosters.
Same platform underneath as Arc8 Retro. Completely different surface. That pairing is the clearest evidence Decision 03 worked.
String Drive — complete product design
An arcade driving experience built around betting virtual currency for cryptocurrency rewards: gameplay flow, the betting journey, profile, deposits, withdrawals, wallet, game history, referrals, tasks and player progression.
The objective was an intuitive bridge between arcade play and financial transaction — two interaction models with opposite tolerances for friction, since a game wants immediacy and a payment wants confirmation.
IdleMine 2.0 — complete redesign
The most extensive redesign in the portfolio, covering authentication, home, game selection, gameplay, store, boosters, rankings, profile, transaction history, deposit, withdrawal, settings, help and about. The product simplified play-to-earn into touch-based continuous gameplay.
The decision inside the redesign is the one worth naming: retention was pursued through progression, rankings, boosters and transaction visibility rather than through more complex gameplay. An idle game that gets harder to play stops being an idle game. Making earnings visible does more for retention than adding a mechanic.
The rest of the portfolio
Bills On Chain — enterprise document AI
The most technically ambitious product I worked on, and the one that first made me argue about infrastructure spend as a product decision. It aimed to automate invoice processing through OCR, AI, cloud infrastructure and blockchain-backed document verification, architected to handle millions of invoices and financial documents.
I owned product discovery, workflow design, business analysis, OCR strategy, AI integration planning, infrastructure planning, vendor evaluation, cloud cost analysis, technical documentation and roadmap planning. The evaluation ran wide — Amazon Textract, PaddleOCR, cloud-native OCR services, self-hosted OCR architectures, IPFS, Filecoin, Redis, PostgreSQL, NestJS, Fastify and blockchain verification strategies — because at that document volume the cost model is the product decision. A per-page extraction cost that looks trivial in a demo decides whether the business exists at a million pages.
aws ecs · postgresql · citus · redis · ipfs · filecoin · solana · amazon textract · paddleocr · nestjs · fastify · new relic
String PayX — cross-border payments
A multi-currency cross-border platform. I contributed to strategy and experience across wallet management, payment flows, cross-border transactions, the crypto-to-fiat journey, banking integrations, KYC journeys, compliance workflows, financial dashboards, transaction history and onboarding.
The defining constraint: the experience has to stay simple while the rails underneath are anything but. Every piece of regulatory machinery a cross-border payment requires is a step the user did not ask for, and the design job is deciding which steps can be moved, deferred or absorbed — none of which can be done without knowing why each one exists.
String Rabbit, AEYE Exchange, String Race
String Rabbit, a play-to-earn Telegram Mini App, managed from game economy through to release with the work centred on retention — tuning the economy, building referrals, rewards and daily tasks, and smoothing the wallet experience so new players reached their first meaningful action faster. Which is the 48-hour activation finding from Decision 04, applied where it mattered most. Also the admin panel, QA and release management.
AEYE Exchange, a crypto aggregation platform: UX strategy and product plan across exchange aggregation workflows, portfolio tracking and the core trading experience.
String Race, an arcade racing title: gameplay UX and player progression — onboarding, missions, leaderboards, profile and wallet integration, tuned to keep players moving through the progression loop.
Corporate and internal systems
Less visible and disproportionately useful. The corporate website, product landing pages, marketing microsites and investor-facing experiences on one side; on the other, the internal platforms that actually run a gaming ecosystem — administration panels, content management, campaign management, reward configuration dashboards, reporting interfaces and operational dashboards.
Designing the reward configuration dashboard teaches you more about how a game economy behaves than designing the game does. The internal tools are where the operators tell you what the product is really doing.
Scale
The ecosystem grew from roughly one million users to more than four and a half million during those nineteen months.
I want to be precise about that rather than flattering. That growth is the context I worked in, not a number I am claiming. It ran alongside marketing, distribution and product launches I did not own, and growth of that size is never one person's doing.
String Metaverse Ltd is publicly listed in India. The ecosystem figures are the company's own reported numbers, not my estimate — they sit in its public disclosures and investor relations material.
What it did give me is the specific experience of designing while the ground moves. Decisions that are fine at one million are load-bearing at four and a half: a retention mechanic that costs a little compute per user, a withdrawal flow that needs an extra support touch, an unfamiliar interaction pattern that costs a support ticket. Multiply any of those by four and a half million and it stops being a design preference and becomes an operating cost.
That is the difference between shipping features and shipping systems, and it is the reason the shared platform in Decision 02 was worth building before it was obviously necessary.
Outcome
- 11Products with product ownership
- 5Telegram Mini Apps, one platform
- 4.5M+Ecosystem users, from ~1M
- 3×Retention, 48h activation cohort
- 5Months to promotion
- 2Features killed post-testing
| Result | What moved | Source of the change |
|---|---|---|
| 20% | Time-to-first-action | Onboarding redesign from longitudinal research with high-frequency users |
| 12% | D7 retention | The same onboarding redesign |
| 15% | Feature adoption | The three adoption blockers found in the opportunity backlog |
| 3× | Retention, activated cohort | Cohort analysis on the KPI framework — the 48-hour activation window |
| 30% | Handoff efficiency between teams † | Structured feedback loops and handoff protocols |
| 40% | Administrative overhead † | Automating routine process and standardising documentation |
| 25% | Sprint variance † | Tighter scope control and cross-functional alignment |
| 2 | Features killed | Structured go/no-go criteria set before testing |
† The three process figures are the weakest-sourced numbers on this page and they are marked so you can discount them accordingly. They are derivable from String Metaverse Ltd's public disclosures — the company is listed in India — but the internal measurement behind them was the company's, not mine to publish, so no method appears here. That is a deliberate omission rather than an oversight: I would rather carry a marked figure than describe a methodology I do not own. The four product figures above them, and the 2, are measured against the changes themselves and are the ones I would defend in a room.
A core gamification feature went from concept to a launch reaching the full user base. But the number I would put on a résumé is the 2.
The two features I killed did more for that roadmap than most of the ones I shipped.
What it taught me
Portfolio thinking is a different discipline from product thinking: eleven products means understanding how they work together toward a business objective, not stacking eleven individual successes. Process efficiency compounds into product quality — the 40% cut in administrative overhead turned directly into time teams spent on the product instead of around it. And cross-functional alignment is not a soft skill but a throughput property.
The larger lesson is the one that moved me: products are interconnected systems where experience, engineering, business strategy, operations and technology have to evolve together, and nobody who only holds one of those can steer. Nineteen months of holding all of them at once is what made the next job possible.
product strategy · behavioural research · kpi frameworks · cohort analysis · design systems · telegram mini apps · ton wallet integration · go/no-go criteria · vendor evaluation · roadmapping · release management · aws ecs · postgresql · citus · redis · amazon textract · paddleocr · nestjs · fastify · ipfs · filecoin · solana