Product engineer
In Laurie Voss’s usage on Chain of Thought, a product engineer turns stakeholder needs into software requirements and directs implementation, including work by artificial intelligence (AI) agents. The emphasis is on deciding what to build and whether it serves the user.
In episode 74, Laurie Voss describes a bakery owner who knows the business but does not want to build software. Someone must ask what the owner needs and translate that into requirements. Voss compares this work to a systems analyst and argues that it becomes more important as agents produce more code.
For example, an engineer building a bakery’s ordering tool might discover that pickup scheduling is the problem, rather than the lack of a generic online storefront. That specific feature is this page’s illustration of the role, not a detail Voss claims to have implemented. Success would mean the owner can manage pickups, not merely that an agent produced a working page.
The distinction matters because requirements, acceptance checks and domain knowledge do not emerge automatically from code generation. Voss’s forecast is his view of changing engineering work, not a standardized definition of every job with this title. People in the role can still write and review code; product judgment and implementation skill can work together.
Hear it from the guest
“The ability to talk to a stakeholder and figure out what it is that they actually need.”
Quotes lightly edited to remove filler words.
Sources
- Chain of Thought, episode 74: Laurie Voss on product engineers — Voss explains stakeholder translation, compares the role with systems analysis and gives the bakery example.
