Feature lifecycle
In this chapter we’ll put the earlier concepts into practice by looking at how to approach a new feature from a frontend engineer’s perspective. There’s no magic formula; it depends on product maturity, team composition, roles, culture, etc. Still, it’s useful to consider these stages to understand which to incorporate into a user story’s lifecycle and how.
The phases below are broad and can fit many product teams. Some teams will run them in parallel; others will run them in sequence.
Generally—aside from design—these responsibilities can fall on any developer, backend or frontend.
1. Analysis
This phase is usually led by the Product Owner/Manager, often together with the Product Designer/UX Designer.
It’s often the phase engineering knows least about, yet developers can add value in several ways:
- Provide usage data to back product decisions.
- Propose new ideas for how users might use the app or how to scale what exists.
- Flag potential bottlenecks and technical debt that could delay planned work.
Knowing the code can be a double‑edged sword when proposing ideas—it’s easy to bias toward the easiest implementation instead of the right one. Call it out regardless.
2. Design
As covered earlier, design is a cornerstone for frontend developers. Not only should we have baseline design knowledge—we should collaborate during prototyping as external agents helping designers reach better solutions. For example:
- Identify common components reusable across the product (or across products) and build them into a component library.
- Define solid foundations that let us take pragmatic liberties when implementing designs.
- Understand what the designer intended and their mid/long‑term vision, and translate that language into code.
In general, Product Designer and Frontend Engineer roles are more connected than they seem. Many companies hire hybrid profiles who can cover both to increase development speed—at the cost, of course, of somewhat lower performance in each discipline.
3. Development
This is the core phase for engineers. Rather than restate best practices, I’ll point you to Extreme Programming. Though not purely about coding—it covers planning and team communication—it contains many of the practices we should follow here.
4. Validation
Contrary to popular belief, QA’s role is not to verify new work or ensure nothing broke (nor is that the PM’s job).
Validation belongs to engineering. By deeply understanding the feature, engineers can spot edge cases left uncovered during implementation.
A team that depends on others to validate new features either doesn’t fully understand the problem, or doesn’t truly know how it will be used.