From PRD Translator to Business Driver: The Three Growth Stages for Engineers

Three Stages of a Technical Engineer

Based on a developer's depth of business understanding, the author divides growth into three stages.

Stage 1 – PRD Translator

Engineers at this level simply implement what the PRD says, focusing only on passing acceptance. They ignore background, value, and underlying business logic. While completing tasks is commendable for newcomers, this stage makes them easy to replace.

Stage 2 – Business‑Aware Solution Designer

Engineers begin to grasp business architecture, discuss PRDs with product managers, and choose suitable technical architectures. They balance feasibility, time constraints, and MVP delivery, often cutting non‑essential features. Most engineers are in this stage and play a crucial role.

Stage 3 – Proactive Business Contributor

All team members can think proactively about business, but engineers have an advantage because they understand both data and operations. Proactive thinking means generating new business ideas, drafting rough product proposals (background, value, feasibility, roadmap), and collaborating closely with product managers to deliver complete solutions.

Driving Business Exploration

In H1 2020, the team experimented with ways to align technology with business, asking how engineers could contribute more strategically.

1. Exploring Demand

Engage directly with merchant‑facing roles (sales, operations, support) through activities like “customer experience days” to feel merchants' pain points.

Proactively communicate with product and merchant operations teams to uncover pain points and hidden needs.

Interview willing merchants for first‑hand insights, or shadow product managers during interviews.

2. Data‑Driven Demand Mining

Analyze metrics such as PC vs. App registration conversion, GMV contribution of marketing apps, user share, and implementation cost to decide which features merit mobile support.

3. Direct Merchant Interviews

First‑hand conversations reveal deeper needs; engineers can start by observing product‑manager interviews and gradually prepare their own questions.

Project Initiation and Promotion

Cross‑department collaboration often hits “department walls.” Success requires humility, result‑orientation, and clear value articulation.

1. Leverage OKRs

Understand company‑wide OKRs, align proposed initiatives with relevant OKRs, and use shared objectives to gain resources.

2. Thorough Preparation

Before pitching a mobile marketing plugin, the team cataloged existing PC plugins, evaluated data, implementation cost, and resource needs, producing dozens of feasibility reports.

Key questions addressed: Why bring the plugin to mobile? Which plugins to implement? Why select these specific plugins? How to quantify project goals?

After analysis, the team prioritized 22 plugins, split them into three phases, and selected the highest‑priority set for mobile rollout.

Project Management

Technical staff can act as project managers, leading cross‑functional teams, handling scope changes, and navigating interruptions from higher‑priority work.

Data Analysis and Iteration

Each project defines value targets and associated metrics. Early on, teams decide which business or telemetry data to collect, embed data collection in the solution, and build dashboards for ongoing monitoring.

Post‑launch analysis follows four types:

Descriptive – what happened?

Diagnostic – why did it happen?

Predictive – what will happen next?

Prescriptive – what should we do?

Effective metrics are comparable, understandable, and ratio‑based, enabling actionable insights.

Takeaways

Over six months, the authors, while primarily mobile developers, took on roles such as product manager, project manager, tester, and customer‑experience liaison. This broadened their perspective, deepened business understanding, and encouraged continuous thinking about requirement rationality, scalability, and maintainability beyond mere implementation.

When engineers truly own a business domain, they consider long‑term development, iterate continuously, and avoid the tunnel‑vision of isolated task completion.