Design a New Feature for a Game You Love and Validate It With Pre-Build Metrics

Pick your favorite game and use it for a three-part product exercise: describe the game, propose one new feature for it, and explain which metrics would tell you the feature is worth building before any engineering money is spent on it. ### Clarifying Questions - Can the game be any game, including a console or board game, or should it be a mobile or social game of the kind Zynga makes? - What counts as "worthwhile": more engagement and retention, more revenue, or a return on the team's time above some bar? - What data can I assume the game already logs, and may I run surveys or show players mock-ups before anything is built? ### Part 1 — Your Favorite Game Name the game and explain why it is your favorite: who plays it and what a typical session looks like. ```hint Choose a game you can dissect Pick one you play often enough to describe its core loop and to name a moment where it frustrates you or loses you. That moment feeds Part 2. ``` #### What This Part Should Cover - A clear description of the game's core loop and its main players. - Reasons for the choice that show product judgment rather than only enthusiasm. ### Part 2 — A Feature You Would Add Propose one new feature for the game. Explain the player problem it solves, which players it is for and how it would work at a high level. ```hint Start from a player problem Find a point where players stall, wait, quit or get less out of the game than they want, and say which players feel it most. Design for that moment rather than for an idea that merely sounds fun. ``` #### What This Part Should Cover - A specific player problem and target segment, grounded in the game's loop. - A concrete feature concept, with at least one alternative considered. - How the feature serves both the players and the game's goals. ### Part 3 — Deciding Before You Build Before any engineering money is spent, which metrics would you look at to decide whether the feature is worthwhile? Say where each number would come from and what result would make you build the feature or drop it. ```hint Use what already exists Think about what the game already records, and what you could learn from players through designs, surveys or interviews without shipping code. Then turn those numbers into an estimate of value you can set against cost. ``` #### What This Part Should Cover - Metrics that measure the size of the problem and its link to retention or revenue, using data that already exists. - Evidence of demand gathered without engineering work. - An estimate of the opportunity and explicit thresholds for a go or no-go decision. ### What a Strong Answer Covers - A clear thread from the game's players and core loop to the problem, the feature and the metrics. - Metrics that can actually be computed before building, each with its source named. - Judgment about the limits of pre-build evidence: correlation versus cause, what players say versus what they do, and the risk of pulling players away from the core game. - A decision rule that weighs estimated value against cost and opportunity cost, and names the next cheap test. ### Follow-up Questions - Players who hit the problem churn more, but they were also less engaged to begin with. How do you tell whether the problem causes the churn? - Your numbers support the feature, but another roadmap item has a similar estimated value. How do you choose between them? - After launch, which signal would tell you the feature is drawing players away from the game's core mode?