---
id: "lib-2026-10-29-trying-out-product-engineer-widening-the-scope-of"
type: "library"
title: "Trying out Product Engineer: widening the scope of work"
title_original: "Product Engineer 도전: 업무 영역의 확장"
lang: "KO"
org: "Yogiyo (Tech Blog, Medium)"
source_type: "Practitioner post"
date: "2026-10-29"
week: "2026-W44"
url: "https://nosov.ai/library/lib-2026-10-29-trying-out-product-engineer-widening-the-scope-of/"
original_url: "https://techblog.yogiyo.co.kr/product-engineer-%EB%8F%84%EC%A0%84-%EC%97%85%EB%AC%B4-%EC%98%81%EC%97%AD%EC%9D%98-%ED%99%95%EC%9E%A5-0f3185b021b6"
tier: "B"
tier_name: "Useful, limited"
tier_reason: "First-person account by a Yogiyo Android developer of a one-person, AI-coded feature pilot across backend, Android and iOS; clear on where time went, but one feature, no time or outcome figures."
summary_basis: "full-text"
original_minutes: "12"
tags: ["future of work", "role scope", "product engineer", "release process"]
---

# Trying out Product Engineer: widening the scope of work

Original title: Product Engineer 도전: 업무 영역의 확장

Tier B (Useful, limited): First-person account by a Yogiyo Android developer of a one-person, AI-coded feature pilot across backend, Android and iOS; clear on where time went, but one feature, no time or outcome figures.

Summary based on the full text.

## In short

A Yogiyo tech blog post (late October 2026) by an Android developer who joined a Q2 2026 "product engineer" pilot: one engineer owns a feature from problem definition to release in a company organised by function. He chose a discount-ranking bottom sheet on the home screen, did the analysis and PRD himself, and had AI write all the code for backend, Android and iOS from a single spec. Code came fast; delivery did not. Time went to logger agreement and on-device verification, review waits on three PRs, QE capacity and the biweekly release slot. AI also failed where business history lived only in people's heads.

## Key numbers

- 3: platforms (backend, Android, iOS) built in parallel by AI from one shared spec document
- 2 weeks: release cycle; missing a release slot meant waiting two more weeks
- Q2 2026: quarter of the product-engineer pilot; the mobile team took over the BFF server from Q3
- about half a year: the author's tenure at the company when he worked across unfamiliar backend microservices

## What it reports

- Three rules for the pilot: drop platform expertise and approach the problem fresh; write no code, focus on problem definition and verification; ask AI first, from docs and code, before asking colleagues.
- He found in BigQuery that exposure of the discount ranking, a surface with proven click-through and conversion, had dropped sharply versus the prior quarter, and built a GMV hypothesis from past CTR, traffic and order value.
- The PRD covered display format, target users, re-display interval, requirements and primary, secondary and guardrail metrics. Page view, impression and click loggers were defined with the data team to fit the existing taxonomy.
- The single spec had background and goals (including a monthly GMV target, value withheld), design principles and user flows, UI states, DTOs, priority, cooldown, A/B and RemoteConfig rules, per-platform scope, rollout and QA items, and open decisions. Platform differences were caught by comparing documents before code review.
- AI misread the microservices: one service still used both v1 and v2 APIs for business reasons, and the AI saw only v2. He dropped the ask-AI-first rule and went to the owning teams.
- A colleague's time-deal feature was about to ship a second home-screen bottom sheet in the same app version; he found it by chance in a PR review. The backend was redesigned into a generic bottom-sheet service by priority and condition, later reused for order-status nudges.
- Defining and verifying loggers cost more than writing them; three PRs waited for separate reviewers; QE time and the release calendar set the pace.
- Since Q3 the mobile team also owns the BFF server. It is moving scattered knowledge into a single source of truth, automating E2E tests and logger checks, and has already automated code review and responses.

## How they got it

The author's own account of the pilot, with the spec structure and incidents described. No figures on duration, effort or the feature's results.

## Limits

- One feature, one engineer; no comparison with how long the functional teams would have taken.
- The GMV goal and test results are not disclosed.
- The author was relatively new, which made undocumented history a bigger obstacle.

## Why it matters for companies

The pilot repeats a pattern seen across many firms this year: AI removes code writing as the bottleneck and exposes verification, review queues, test capacity, release cadence and undocumented context. The useful details are the fixes: one spec all platforms build from, generic shared surfaces instead of feature-specific ones, and documenting business history so agents and new staff stop hitting the same walls. Firms trying full-stack or product-engineer roles should fund those foundations first, or the role mostly moves waiting time around.

## Key passages in translation

> 코드 생성은 더 이상 병목이 아닙니다. 병목은 맥락, 검증, 프로세스입니다.

Code generation is no longer the bottleneck. The bottlenecks are context, verification and process.

> AI 가 길을 잃은 곳은 문서가 아니라 누군가의 머릿속에만 있던 맥락이었습니다.

Where the AI got lost was not in the documents but in context that existed only in someone's head.

> 코드를 작성하는 비용보다 로거를 정의하고 검증하는 비용이 더 컸습니다

Defining and verifying the loggers cost more than writing the code.

Original: https://techblog.yogiyo.co.kr/product-engineer-%EB%8F%84%EC%A0%84-%EC%97%85%EB%AC%B4-%EC%98%81%EC%97%AD%EC%9D%98-%ED%99%95%EC%9E%A5-0f3185b021b6