Drama Relationship Map
Acted as PM in a course-based developer marketplace to ship a spoiler-safe, AI-assisted character relationship board for cast-heavy dramas, from blank spec to live product.
TIMELINE
Jan 2025 – Apr 2025
TEAM
UW MSTI
ROLE
Product Manager (Client)
TOOLS
Next.js, React Flow, TypeScript, OpenAI API, TMDB API, Supabase
LONG STORY SHORT
Wrote the full product spec and graph architecture before a line of code was shipped, locking the visual language (node size, edge color, spoiler filter) that made it into the final demo unchanged.
Managed 3 milestone check-ins with developer Finnick Chen, reviewing PRs within 48 hours and making the key scope call that kept the demo tight and shippable.
One RedNote post one week after launch drove 21,000 users to the app: 4,448 likes, 3,351 saves, 464 comments, validating that the right channel was as important as the right product.
THE CHALLENGE
How might we help drama viewers stay oriented in complex casts without breaking immersion or accidentally spoiling themselves?
LIVE PRODUCT
See it in action
The app shipped at the end of Spring 2025 and has stayed live since. Load the Singles Inferno S5 demo board, drag character cards, click any node to see who they're connected to, or type any drama title to generate a fresh cast graph via AI.
VIEW LIVE DEMO →PROBLEM
The spoiler trap
Viewers of cast-heavy dramas (prestige TV, multi-generational epics, reality competition shows) run into the same problem constantly: they lose track of a character mid-episode, pause to search for context, and accidentally see a spoiler in the first result. The search engine doesn't know where you are in the story. Every wiki, fan site, and recap assumes you've seen everything.
The gap was clear: there was no spoiler-safe, visual, interactive tool that showed you only the relationships you were supposed to know at your current point in the story. The product opportunity was to build exactly that and make it work for any show, not just one.
TARGET USERS
The complex-drama viewer
Not every drama watcher has this problem equally. I defined three distinct personas based on the specific nature of their confusion, each with a different trigger and a different version of the spoiler risk.
The Prestige TV Super-Fan
Succession · The White Lotus · Industry · Shōgun
These shows have massive ensembles where characters are related by blood, marriage, and corporate politics simultaneously. A single throwaway line can imply a major loyalty shift, and this user feels they're missing the subtext.
Mid-episode confusion
The Time-Jump Watcher
House of the Dragon · Dark · The Crown
Multi-generational structures, flash-forwards, and the same character played by three different actors across time periods. They can't keep track of which child belongs to which parent, or who the older version of a character is.
Timeline disorientation
The Hiatus Binger
Any show with 1–2 year gaps between seasons
They wait for a full season to drop, or return after a long break. They've forgotten the specific grudges, affairs, and betrayals from the previous season and need a 5-minute visual refresher before they can re-engage.
Season re-entry
All three personas share a single underlying need: a way to check in on relationships without leaving the story further behind than they already are. The spoiler filter is what makes the product usable for all three. Without it, the app is just another wiki.
DISCOVERY
Research before requirements
A PM should never build features based on a guess. I used a four-step research framework combining digital ethnography, qualitative interviews, prototype testing, and demand validation, in that order. Each step either confirmed or sharpened the previous one.
Digital Ethnography: where fans already complain
Before talking to anyone, I went to where drama viewers already express confusion publicly. On subreddits for Succession, House of the Dragon, and Dark, I found over 30 threads titled variations of “can someone explain the family tree?” or “who is working for who at this point?”, each with hundreds of upvotes and dozens of replies. The top-voted responses were almost always fan-made graphics: color-coded flowcharts, family trees drawn in Google Slides, org-chart screenshots. Users were manually building the tool they needed every season.
I also scanned App Store reviews for TV tracking apps (TV Time, Letterboxd). A recurring complaint: “gives me cast info but always includes spoilers” and “no way to filter by how far I am in the show.” Existing tools weren't solving for spoiler-safe access. They were built for completionists, not people mid-rewatch.
30+
Reddit threads asking cast / relationship questions across drama subreddits
Top answer
Was always a fan-made visual: color-coded flowcharts, not text summaries
3 apps
Reviewed on App Store; all flagged for spoilers by users in lower-rated reviews
User Interviews: qualitative behavior, not opinions
I recruited 5 heavy drama watchers for 30-minute video interviews. The key rule: never ask someone if they'd like your idea. People lie to be polite. Instead, I asked only about past behavior. “Tell me about a time you got confused while watching a show. What did you do in that exact moment?” and “Have you ever been spoiled while trying to look up a character? Walk me through how that happened.” I also asked them to screenshare and show me how they currently look something up mid-episode, watching them navigate in real time surfaced friction points no interview question would have.
“I just want to know if they're related. Not if they die.”
Interview 2 · K-drama viewer
“I paused House of the Dragon and Googled a character. The autocomplete showed me they get killed two episodes later.”
Interview 4 · Prestige TV viewer
“Wikis are useless for me mid-season. The first paragraph always assumes you've seen the finale.”
Interview 5 · Hiatus binger
Key finding: all 5 interviewees had paused a show to search in the past month. 4 out of 5 had been spoiled at least once in the past year doing it. None were satisfied with any existing tool, but all 5 had developed workarounds: screenshot bookmarks, notes apps, fan-made PDFs. Workarounds at scale are one of the clearest signals a real product gap exists.
Low-Fi Prototype Testing: validate behavior, not preference
Before writing the SPEC, I built a clickable Miro board of the Succession Season 3 cast, character cards connected by labeled relationship lines, no interactivity, just a static visual map. I handed it to 5 testers with a specific task: “Imagine you're about to start Episode 4. Use this to remind yourself who currently controls the board seats.”
What I watched for wasn't whether they liked it. It was what they tried to do. All 5 immediately tried to click the nodes. 3 out of 5 looked for a search bar. 2 found the unlabeled lines confusing and asked what the different line styles meant. These observations directly shaped three decisions in the SPEC: click-to-focus was a must-have (not a nice-to-have), a search or filter bar was required, and the edge color vocabulary had to be defined and consistent from day one.
5/5 tried to click character nodes
Interactive nodes are not a nice-to-have. They're the expected default behavior
3/5 looked for a search or filter bar
Added search to must-have features; became the episode-progress filter in the final product
2/5 confused by unlabeled lines
Locked the 6-type edge color vocabulary into the architecture before any code was written
Smoke Test: validate demand before building
The final check before committing to a build: I put up a one-page Carrd landing page describing the product: “The spoiler-free character map for complex dramas. Never get confused by family trees or corporate betrayals again.” I added screenshots of the Figma mockups and a single CTA: “Join the Beta Launch.” I shared it in two drama-adjacent Discord communities and one Reddit thread.
The benchmark for strong demand signal: a 15–20% email sign-up conversion rate from unique visitors. Over two weeks, the page received 212 unique visitors and collected 38 email sign-ups: an 18% conversion rate. That number, alongside the interview data and the Reddit pattern, gave me enough confidence to write a full SPEC rather than a scoped experiment.
212
Unique visitors over 2 weeks
38
Email sign-ups from the beta CTA
18%
Conversion rate: above the 15–20% strong-demand threshold
PROCESS
Spec before sprint
This project ran inside a course-based developer marketplace. I was the PM and client, Finnick Chen was the developer. Unlike a typical class project where you figure it out together, I had to come in with a real brief. Finnick's time was the resource. Wasted check-ins meant a worse product.
Armed with four rounds of research, I delivered two documents before any code was written: a product SPEC and an ARCHITECTURE doc. The SPEC covered the problem statement, five prioritized user stories derived directly from the interview findings, a must-have vs. nice-to-have feature split, and acceptance criteria specific enough to evaluate at a live demo. The ARCHITECTURE doc went a level deeper: specifying the exact visual language for the graph (the same color vocabulary validated in prototype testing), the data schema with column-level notes, and three milestone check-ins with clear deliverables. Writing that architecture document was one of the most PM-specific things I did on this project, it translated user needs into engineering constraints so there was no ambiguity about what “done” looked like.
01
Discovery
Digital ethnography, 5 user interviews, low-fi prototype testing, smoke test landing page, all before writing a single requirement
02
Spec + Arch
Product SPEC with 5 user stories, must-haves, acceptance criteria; ARCHITECTURE doc with full graph design language and data schema
03
Check-ins
3 milestone reviews with PRs reviewed within 48 hours; scope calls made at each check-in to protect the demo
04
Demo
Live demo to class of 18: Singles Inferno S5 curated board plus live AI generation for any show
KEY SCOPE DECISIONS
Cut manual text paste from v1.
Original spec included a flow where users paste raw story text and AI extracts characters. I scoped this to v2. The LLM already knows popular dramas from training data, so typing a title was enough for a demo. This saved significant backend work and kept the milestone on track.
No user accounts or saved boards in v1.
Authentication and personalization were listed as nice-to-have. With an 8-week timeline, the risk of auth scope creep was too high. I explicitly scoped these out in the PRD and held that line through check-in 2 when the feature came up again.
Ship with one curated demo story, not a library.
A library of stories would have required editorial work neither of us had time for. Committing to Singles Inferno S5 as the flagship demo let Finnick tune the layout, headshots, and relationship labels for one high-quality showcase instead of many mediocre ones.
SOLUTION
A string board for any show
The product ships in two modes. First, a curated board: Singles Inferno Season 5, 12 Season 5, 12 characters, 23 relationship edges, episode-aware spoiler filtering. Second, an AI mode: type any drama title, wait ~4 seconds, and a fresh cast graph renders using the same visual language. Both modes share the same interaction layer: draggable nodes, click-to-focus, a relationship detail panel, and PNG export.
GRAPH VISUAL LANGUAGE
Nodes (Characters)
Edges (Relationships)
TECH STACK
CURATED DEMO
Singles Inferno S5: pre-loaded and episode-aware
12 cast members, 23 relationship edges, and full episode-progress filtering built in. The demo was chosen specifically because Singles Inferno was trending on RedNote at launch, the audience already knew the cast, which made the board immediately legible and shareable without any explanation.
AI Cast Generation
Type any show title. The app sends a structured prompt to the LLM, validates the response with Zod, and renders the full cast graph. Average time: ~4 seconds.
Spoiler-Safe Filter
Slide to your current episode. Characters introduced later disappear from the board entirely. Absent nodes don't hint that someone exists.
Click-to-Focus
Click any character and all unrelated nodes dim to 20% opacity. A detail panel slides in showing their role, faction, and full list of relationships.
PNG Export
Export the full board as a high-resolution image. Useful for sharing, notes, or just screenshotting the chaos before a season finale.
IMPACT
From course project to 21K users
The course demo went well: highest functionality score (5/5), two classmates called out the visual interaction design by name. But the real story happened after the class ended. One RedNote post a week after launch drove 21,000 users to the app and made it clear we had built something with genuine market demand, not just a good class project.
21K
Users within the first week of launch
4,448
Likes on the RedNote launch post
3,351
Saves: the highest-signal engagement metric on RedNote
464
Comments, mostly tagging friends to try it
GO-TO-MARKET
Why RedNote worked
The RedNote launch post · one week after shipping
Choosing RedNote (小红书) as the launch channel wasn't arbitrary. It came from the same research process that shaped the product: go to where the audience already is and observe what they're doing. What I found was that Chinese drama audiences don't just watch shows. They document them. Fan-made 人物关系图 (character relationship charts) are a native cultural artifact on Chinese platforms. Chinese TV productions often officially release their own relationship charts before a season premieres. The audience already understood exactly what the product was the moment they saw it.
RedNote's format did the rest. With 300M+ monthly active users skewing female aged 18–35, the exact demographic that drives K-drama and C-drama fandom, and a visual-first feed where saves carry more algorithmic weight than likes, a single high-quality post showing the board in action had real distribution potential. Singles Inferno (단신지옥 / 单身地狱) was already trending on the platform when we launched, which meant the demo content matched what the audience was actively searching for.
WHY CHINESE AUDIENCES WERE THE RIGHT FIRST MARKET
人物关系图 is already cultural
Character relationship charts are a native concept in Chinese drama culture. Official production companies release them. Fans redraw them every episode. The product didn't need to explain itself. It just needed to be better than a PNG in a group chat.
RedNote's save mechanic rewards visual tools
On RedNote, saves (收藏) signal intent to return, more valuable than a like. A tool users want to reference again and again is exactly the type of content that gets saved, and saved content gets distributed. 3,351 saves in one week validated the repeat-use model.
K-drama fandoms are massive and organized
Chinese K-drama fans are among the most engaged in the world. Singles Inferno S5 had millions of views across Chinese platforms the week it dropped. Launching with a pre-built S5 demo meant the app was immediately useful to an audience that was actively watching.
RedNote drives referral behavior naturally
The comment section on the post was almost entirely users tagging friends: '你看这个' ('look at this'). The visual nature of the board (character photos, colored relationship lines) made it highly shareable in screenshots without even clicking through.
POST PERFORMANCE · WEEK 1
4,448
❤️ Likes
Top signal of reach
3,351
⭐ Saves
Highest-intent action on the platform
464
💬 Comments
Mostly friend tags and show requests
21K
👤 Users
Total app users driven within one week
LEARNINGS
What this changed about how I think about PM
The main thing I'd do differently on the product side: I scoped out user text paste too early. During the demo and in the RedNote comments, the most common request was support for shows the AI didn't know: niche dramas, current-season reality TV, novels. The LLM generation works brilliantly for popular titles but fails for anything outside its training data. Text paste would have closed that gap and made the product meaningfully more useful for the long tail of the audience that showed up.
WHAT I'D CARRY FORWARD
Architecture docs are a PM deliverable.
Writing the ARCHITECTURE doc forced me to translate user needs into engineering constraints before a line of code was written. It made every check-in faster because there was always a shared reference to compare against.
Scope calls age. Revisit them.
Cutting text paste felt right at week 2. By launch week it was clearly the most-requested feature. Good scope management means defending the right cuts, but also recognizing when real user signal contradicts an early assumption.
Channel is a product decision.
Choosing RedNote wasn't a marketing afterthought. It came from the same user research that shaped the product. The audience, the format, and the content all aligned. Distribution deserves the same rigor as the feature set.