Product

Kado+ Subscription

Building a 0→1 subscription service for Japanese light novels — from zero revenue to 10% growth.

Role

Product Manager

Timeline

Jun 2023 – Jul 2025

Company

KadoKawa Corp.

TL;DR

10%

Boosted overall product revenue after launch

0→1

Built Taiwan's first subscription service for Japanese light novels

3

Payment integrations shipped — Apple IAP, Google Play, web

Context

About KadoKawa & Kado+

KadoKawa

KadoKawa is a publicly listed Japanese media group operating under a Global Media-Mix philosophy — creating IP with authors, distributing it across platforms, and connecting fans through communities. Major shareholders include Sony, Tencent, and Kakao.

Kado+

Kado+ is a subscription service tailored for Japanese light novel enthusiasts, offering unlimited, chapter-based access to officially licensed Japanese titles. The goal: reduce cost and time barriers for Taiwanese readers while building a sustainable content ecosystem that works for readers, the platform, and creators simultaneously.

Team

Product Manager2 Product Designers5 Engineers2 App Developers2 Data Scientists2 Marketing2 Content Strategy
Kado+ service diagram — Reader, Platform, Creator ecosystem

Problem

Three barriers blocking readers — and the business

Reader

  • Licensing barrier — Officially licensed Japanese light novels require a Taiwanese company to obtain separate authorization, limiting available supply.
  • Cost barrier — High per-book pricing made casual or exploratory reading expensive.
  • Time barrier — Translation and licensing cycles meant new Japanese releases took significantly longer to reach Taiwanese readers.

Business

  • IP Synergy — Needed to leverage in-house IP to amplify the visibility of platform-exclusive content.
  • Anticipation & Insight — Wanted pre-release warm-up data to understand reader preferences before physical book publication.
  • Creator Economy — Needed to offer creators diverse revenue streams beyond one-time licensing fees.

My Approach

Defining the model before building the product

As the lead PM, I was responsible for defining the product model, business logic, and feature requirements before engineering started. This meant working across content, marketing, tech, data, and finance teams to align on development phases and expected outcomes.

Three roles, one model

Readerpays a monthly fee → gets unlimited access to subscription-exclusive chapters
Platformcurates and licenses titles → earns platform revenue, gains reader preference data
Creatorprovides content licensing → earns revenue share proportional to actual readership

I ran two parallel workstreams before launch: define the subscription business logic (pricing, revenue share formula, platform rules), and define the user-facing product (flows, copy, states, edge cases). Both had to be ready simultaneously.

Subscription architecture — User to IAP to platform auto-renewal flow

What I Shipped

From MVP to a full subscription ecosystem

01 · Subscription MVP

Defined the full user journey from discovery to purchase — subscription-gated chapter logic, error states, processing states, cancellation flow, and subscription state management across App and Web. This also included working with engineering to define the API call flow.

Signal — Building a parallel web checkout would have delayed launch by months, and platform review cycles made the timeline risk worse.

Bet — Strategically, driving app downloads mattered more than a frictionless web checkout — the app is where retention and push infrastructure live.

Decision — Web users can browse but not subscribe directly. I designed a web-to-app handoff instead: desktop users see a QR code, mobile users get a deep link straight into the App Store or the app itself.

Web and App subscription flow — desktop QR code, mobile deep link, IAP payment, and success screen

Web (QR code · deep link) and App (subscription page · IAP payment · success state)

02 · CMS Subscription Management

Content editors needed full operational control — adding chapters, setting activation dates, reordering titles — without filing an engineering ticket every time. I designed the back-end workflow from scratch, including the scheduling logic and platform ID mapping to Apple/Google, and ran internal training before launch. This removed a recurring engineering bottleneck for the content team.

CMS subscription management — plan list, drag-to-reorder title page, chapter scheduling, and platform-to-front-end workflow

CMS — plan list · drag-to-reorder · chapter scheduling · platform workflow

03 · Revenue-Sharing Formula

Co-designed with my manager, the formula distributes creator revenue proportionally by actual readership rather than an equal split — factoring in subscription fee, platform operating costs, and per-title chapter views. The hard part wasn't the math: it was getting Finance, Content, and Engineering to agree on shared definitions, like what counts as a valid read and how content removed mid-cycle is treated.

Four chapter list examples, each showing a different unlock badge — free, points (lock), reading voucher (ticket), and subscription (Kado+ logo)

Chapter unlock types — free, points, reading voucher, subscription

04 · Research → Content Discovery & Retention

Post-launch, I established a structured feedback framework across five subscriber lifecycle stages to drive iteration:

Five-stage subscriber lifecycle — Potential Audience, Active Readers, Inactive Subscribers, Unsubscribed, Returning User

Data was synthesized from four sources: Amplitude behavioral analytics, customer service feedback logs, user satisfaction surveys, and exit surveys from churned subscribers. Key findings from churned subscriber surveys:

Finished all available content — nothing left to read
Couldn't find similar titles after finishing one
Intro chapters weren't compelling enough to continue
Price too high — though push data later showed price wasn't the primary driver

I developed detailed Customer Journey Maps across all five stages and used them in cross-functional workshops to align stakeholders on iteration direction before development started.

Customer Journey Map across all five subscriber lifecycle stages

Customer Journey Map — all five stages

Churned subscriber exit survey results

Exit survey — churn reasons and feature requests

Hero Banner & Thematic Discovery

Pivoted content strategy from Blockbuster Title Attraction to User-Centric Content Discovery. The Hero Banner surfaces thematically curated titles to drive clicks to key content. A layered recommendation system — popular titles combined with thematic suggestions based on reading history — supports the content team's promotion of Taiwan-exclusive and pre-published novels. A limited-time offer near the CTA accelerates subscription decisions.

Framing this to the content team as an editorial decision — not a retention mechanism — was what got it shipped.

Kado+ App main page — Hero Banner and layered thematic recommendations

App — Hero Banner · layered recommendations · limited-time offer

Kado+ Web main page — subscription value proposition and content update schedule

Web — value proposition · content update schedule

Results & Impact

Measurable outcomes across revenue, retention, and insight

10%

Boost in overall product revenue post-launch

↑ Retention

Mitigated single-title churn through Hero Banner and thematic stratification, driving subscribers toward second and subsequent novels

↑ Insight

Validated user value propositions by correlating push notification CTRs with new reading initiation rates; Day 4 price-led push underperforming confirmed content discovery — not price — was the core retention lever

🚀 First

Launched Taiwan's first subscription service for officially licensed Japanese light novels

Learnings

What building 0→1 taught me

Communication Alignment

Establishing unified metric consensus among all stakeholders (Content, Marketing, Tech) is critical to prevent resource scattering and ensure all cross-functional partners share a common definition of product success.

Third-Party Integration

Integrating platforms like Google/Apple involves significant technical and policy pitfalls. This demands substantial time and multi-round communication with platform representatives to ensure compliance and a stable user experience.

Balancing Demands

The core challenge in building a product from scratch is balancing internal business goals (e.g., content promotion, cost-efficiency) with external user expectations (e.g., ease-of-use, perceived value).