Goal
Explore one judgment: product engineering may be a new direction for traditional SDEs in the AI era.
- How AI affects the traditional SDLC
- Where SDEs can move their capability focus in the AI era
- How to build product engineering capability
Chinese version: 产品工程：传统 SDE 在 AI 时代的可能职业方向
What
A product engineer combines product judgment with end-to-end delivery capability.
- Understands user problems and product goals
- Makes technical decisions through product trade-offs
- Owns delivery from solution to launch
- Evaluates results and iterates from feedback
Why
The Traditional Product Lifecycle
Start with a common product lifecycle. Each stage pairs a key problem with the value it creates.
| Layer | Stage | Key Problem | Value Created |
|---|---|---|---|
| Business | User Demand | Which user problem is worth solving? | - Discover real user problems - Clarify needs and pain points |
| Business | Commercial Revenue | Why is this product worth company investment? | - Estimate revenue potential - Evaluate profit, growth, or strategic value |
| Product | Solution Definition and Design | What product solution should address it? | - Define the product solution - Shape the user experience - Align key trade-offs |
| Technology | Technical Planning | How can the solution land reliably? | - Clarify requirements - Design architecture - Create an implementation plan |
| Technology | Implementation | How do we build it and deliver it to users? | - Turn plans into software - Ensure quality through testing |
| Decision | Measurement and Iteration | Did the result match expectations? | - Validate actual impact - Reduce uncertainty for the next decision - Decide the next product or business move |
Then map these stages to common role categories in an organization.
| Layer | Problem It Solves | Value It Creates | Typical Roles |
|---|---|---|---|
| Strategic Direction | Which problem should we solve, and why now? | Sets direction, defines success, allocates resources, makes trade-offs | Founder, Executive, Product Leader, Business Owner |
| Tactical Planning | What should we build, and how should we organize the work? | Turns direction into plans, requirements, designs, priorities, and coordination | PM, Designer, Tech Lead, Data Analyst |
| Execution | How do we build, launch, operate, and improve it? | Delivers systems, releases safely, observes feedback, and improves | SDE, QA, SRE, Support, Sales, Marketing |
AI’s Impact on the SDLC Process
What AI Does Well and Does Not Do Well
AI’s impact depends mainly on how clear the task boundary is.
- Good at: tasks with clear input, output, rules, and evaluation criteria.
- Examples: coding, testing, documentation, and routine technical research.
- Weak at: complex work where the input, output, constraints, and success criteria are unclear.
- Examples: problem framing, user context, business trade-offs, product judgment, and final decision making.
Related exploration: AI exploration notes
Impact on Different Role Layers
Using the role layers above, AI affects each layer differently.
The percentages below come from my own experience and intuition, not from a statistical study. They represent the rough degree to which current AI capabilities can affect each layer.
| Layer | AI Impact | Reason |
|---|---|---|
| Strategic Direction | 30% | Strategy depends on context, business judgment, resource allocation, and accountability |
| Tactical Planning | 50% | Planning contains both structured work and ambiguous trade-offs across product, design, data, and technology |
| Execution | 70% | Execution usually has clearer inputs, outputs, rules, and evaluation criteria |
Impact on Company Organization and Market Demand
This is one reason execution-heavy roles and some middle-layer coordination roles face more pressure during organizational adjustment. Layoffs and role reductions are not only about AI. Hiring cycles, capital cost, over-expansion in previous years, and cost-efficiency goals also matter.
As organizations become leaner and efficiency expectations rise, a different profile becomes more valuable: people who can handle unclear problems, make cross-functional trade-offs, use AI to increase delivery leverage, and connect product decisions, technical delivery, and business outcomes.
Evidence from hiring market:
- Skill demand is moving toward AI plus human judgment. WEF’s Future of Jobs Report 2025 lists AI and big data among fast-growing skills, while also emphasizing analytical thinking, creative thinking, leadership, and collaboration.
- The SWE market is changing at the skill level. LinkedIn’s 2026 U.S. Software Engineer Talent Landscape says new SWE hires emphasize cloud platforms and fast-growing AI-related tools.
- AI demand is not limited to AI developer roles. PwC’s 2026 AI Jobs Barometer shows growing demand for AI-related roles and AI user roles.
New Value Areas and Career Directions for SDEs
Where the New Direction Comes From
From the product lifecycle, a worthwhile direction for SDEs should meet three conditions:
- AI will not do them well in the short term.
- They have a clear place in the product lifecycle.
- SDEs can participate through software engineering leverage.
| Layer | AI Short-term Difficulty | Place in Product Lifecycle | How SDEs Can Participate |
|---|---|---|---|
| Strategic Direction | High: unclear goals, business context, and accountability | Decides why to build and what outcome matters | Support research, frame problems, evaluate value |
| Tactical Planning | Medium: mixed structured tasks and ambiguous trade-offs | Turns direction into product, technical, and execution plans | Decompose problems, clarify constraints, design solution paths |
| Execution | Low: clearer inputs, outputs, and evaluation criteria | Turns plans into software and feedback | Use AI to accelerate coding, testing, and iteration |
What the New Value Chain Is
There are two paths:
- Single-layer depth: going deeper in one layer, such as strategy, planning, architecture, or execution.
- Cross-layer connection: connecting strategy, planning, and execution into an outcome loop.
I would lean toward cross-layer connection.
Single-layer depth is still valuable, but every layer is being changed by AI. The more interesting opportunity is to connect the layers and turn unclear goals into executable, testable work that AI can help accelerate.
In typical internet-product teams, Product Engineering is a concrete path to this cross-layer connection.
| Dimension | Business Team | Infra Team |
|---|---|---|
| Domain | User-facing products and business outcomes | Internal platforms, tools, and engineering systems |
| Role Direction | Product Engineer | Platform Engineer / Infrastructure Architect |
| Value Chain | User problem discovery Business value judgment Product solution decomposition AI-assisted delivery |
Internal need discovery Platform value judgment Technical solution decomposition AI-assisted delivery |
| Capability Depth | Heavier focus on business value judgment and product trade-offs | Heavier focus on architecture, systems, performance, reliability, and code quality |
In the rest of this article, I will focus on Product Engineer instead of Infrastructure Architect.
- I have spent most of my career building depth across application, framework, and system architecture.
- I am now more interested in the Product Engineer direction.
How
This section keeps only the high-level practice framework.
The sequence is: decide whether the direction is worth pursuing, validate whether the solution works, then deliver with quality.
The difference between a Product Engineer and a pure PM or Tech Lead is the ability to connect discovery to the engineering loop: product hypothesis, prototype, technical trade-off, instrumentation, delivery, and iteration.
Product Risk
Before spending significant delivery effort, check whether the main product risks are under control.
| Risk | Key Question | Method | Output |
|---|---|---|---|
| User Value | Do users really need it? | Customer interview, usage intent, willingness to pay | Evidence of user demand |
| Usability | Can users use it smoothly? | Low-fi prototype, task walkthrough | Usability risk assessment |
| Feasibility | Can the team build it? | Technical spike | Technical feasibility proof |
| Viability | Should the company invest in it? | Stakeholder review | Business viability assessment |
Discovery
Use discovery to reduce uncertainty before committing to a solution.
| Step | Key Question | Method | Output |
|---|---|---|---|
| Problem Definition | Who is the user, what is the scenario, and what pain exists? | Customer interview, feedback analysis | Problem statement |
| Hypothesis | What change do we expect? | Hypothesis modeling | Testable hypothesis |
| Validation | How do we test whether the hypothesis is true? | Prototype, user testing, A/B experiment | Validation result |
| Metrics | How do we know whether it works? | Business metrics, behavior metrics | Success criteria |
| Decision Making | Should we continue, iterate, or stop? | Go / iterate / kill review | Decision |
Delivery
Use delivery to turn a validated direction into working software and measurable outcomes.
| Step | Key Question | Method | Output |
|---|---|---|---|
| Architecture | How should the validated direction map to a technical structure? | Architecture design, trade-off review | Architecture decision |
| Build | How should the solution be implemented? | Coding, code review, testing, continuous delivery | Working software |
| Measure | Did the solution work as expected? | Metrics tracking, user behavior observation | Outcome signal |
| Iterate | What should change next? | Data review, feedback review, small iterations | Next version |