AI turns software engineers into product engineers
For decades, the software development lifecycle followed a predictable rhythm. Product Managers translated customer needs into specs. Engineers translated specs into code. We measured progress in quarterly plans, monthly sprints, and weekly releases.
This was the “factory model” of software: a sequential assembly line where each function had a clear role. Product Managers were the “thinkers” – they talked to customers and wrote requirements. Engineers were the “builders” – they received those documents and implemented what was specified. The value was in the translation layer.
That rhythm is collapsing.
With the rise of AI coding agents, the time between “I know what we should build” and “here is working prototype” has compressed from weeks to hours. Implementation – once the most expensive and time-consuming part of software development – is becoming a commodity. “The spec is becoming the product,” and the barrier to building has never been lower.
But as the implementation barrier drops, the bottleneck shifts upstream. The scarce resource in software development isn’t engineering capacity anymore. It’s knowing what is actually worth building.
This shift represents a profound opportunity for software engineers. It is the dawn of the Product Engineer.
The work didn’t get easier. It got more important.
In the old model, value was often found in the “translation layer” – taking a requirement and technically executing it. But as one industry observer noted, “The work of knowing what to build didn’t get easier. It got more important.”
When an AI agent can generate a working prototype in an afternoon, the risk of a project is no longer “can we build this?” The risk is “should we build this?”
The illusion of progress
Speed creates an illusion. When you can ship code faster, it feels like you’re making progress. But shipping the wrong feature quickly is worse than shipping the right feature slowly. In a world where implementation is cheap, building the wrong thing becomes the most expensive mistake you can make.
This is where taste becomes critical. When agents can confidently produce output that looks correct, runs without errors, and meets the literal specification, someone needs to ask: “Does this actually solve the problem? Does it handle the edge cases that matter? Is this the version we should ship, or just the version that compiles?”
Taste isn’t innate – it’s developed through repetition. You need to build things, evaluate them with real users, and learn what “good enough to ship” feels like. But taste requires context. You can’t develop taste for a product you don’t understand or problems you haven’t internalized.
If your role is defined solely by writing code to specification, you are competing with agents that get faster and cheaper every day. But if your role is defined by understanding problems so deeply that the right solution becomes obvious, you are more valuable than ever. Agents amplify that understanding into shipped product faster than any team ever could before.
So what is a Product Engineer?
A Product Engineer doesn’t just write code; they solve customer problems. They refuse to be boxed into a “ticket-taking” role where context is stripped away.
Engineers, in many ways, are like magicians – they have the power to turn customer problems into features people love. But too often, engineers are boxed into creating whatever they’re told to create, with no customer context or room for strategic thinking. Product engineering is about breaking out of this limiting mindset.
We can define this mindset with a simple equation:
Product Engineering = Technical Excellence + Customer Context + Strategic Problem-Solving
The key differentiator is Customer Context. Product Engineers don’t just know what to build – they know why. They participate in user interviews, review support tickets, and access customer feedback that usually gets filtered through Product Management.
At companies like Atlassian, engineers maintain dedicated Slack channels with “lighthouse users” – customers who are most affected by the problems being solved and willing to provide direct feedback. These aren’t abstract personas; they’re real people with specific pain points.
In this model, engineers are not just the “hands” of the operation; they are active participants in the “brain.” They amplify the strategy, bringing technical feasibility into the conversation early and often. They don’t wait for a perfect spec; they help shape the problem itself.
Traditional Software Engineer: Receives a detailed spec, asks clarifying questions about implementation, writes code to specification. Success measured by story points completed and sprint velocity.
Product Engineer: Participates in defining the problem, asks clarifying questions about the user and the problem, proposes and validates potential solutions. Success measured by customer outcomes and feature adoption.
Continuous deployment cycle
The cycle times that used to define product development are compressing into something closer to the continuous deployment of ideas. To thrive in this environment, engineers need to adopt a new set of behaviors:
- Bring customer insights into every stage: You cannot shape a solution without understanding the pain. Product Engineers participate in user interviews, review support tickets, and ground their work in real customer data, not abstract requirements. A persona might say “busy product manager who values efficiency.” A real lighthouse user says, “I waste 30 minutes every morning copying data from Salesforce into our roadmap tool, and by then, the data is stale.” The specificity matters.
- Validate constantly with Lighthouse users: Instead of building in the dark for months, use the speed of AI to prototype and test rapidly. The concept of lighthouse users – a small group of highly engaged customers who help guide product direction – is essential here.
At Atlassian, lighthouse users are carefully selected based on several criteria:
- They are very clear communicators, able to articulate their pain points and provide actionable feedback.
- They are happy to use early-stage products or features, sharing feedback and discussing solutions even when the experience is rough around the edges.
- They fall squarely in your target customer segment, even if that segment is still evolving.
- They are strongly affected by the problems you’re trying to solve, and experience genuine pain from the gaps your product addresses.
- They are actively looking for new ways to solve this pain point, often experimenting with new solutions rather than being content with the status quo.
- They are not using a competing product, so they engage with your solution without pre-existing expectations or constraints.
- They are open to new and different features, solutions, and ways of working, able to provide unfiltered and innovative feedback.
The goal is to solve real problems for real people. If your solution works for a small set of these lighthouse users, it’s more likely to work for others facing similar challenges – and their early feedback will keep you on the right track.
- Collaborate radically across the triad: The walls between Product, Design, and Engineering must come down. In a world where “Wonder, Explore, Make, and Impact” can happen in a week, these roles must operate as one unit. Instead of sequential handoffs – Product defines, Design mocks, Engineering builds – the work becomes parallel: engineers attend design sessions, designers join customer interviews, and PMs review working prototypes instead of slide decks. Teams at Atlassian that have adopted this approach see 70% higher feature adoption rates because features are grounded in deep customer understanding and validated iteratively.
Solving the context gap
To behave like a Product Engineer, you need access to the “why.” You need to see the customer feedback, the strategic prioritization, and the validation data that usually lives in scattered documents or PMs’ heads.
In traditional organizations, this information is siloed. Customer feedback lives in Salesforce. Strategic priorities live in PowerPoint. Roadmaps live in spreadsheets. Engineers receive sanitized versions of all this context by the time it reaches them as a Jira ticket.
Engineers are building in the dark. They don’t know why this feature was prioritized. They don’t know which customers are most affected. They can’t contribute to strategic discussions without context.
This is where Jira Product Discovery comes in.
Jira Product Discovery gives teams a single place to capture feedback, prioritize ideas, and build roadmaps that people can rally around. Because it sits on top of Jira, it gives engineers visibility into the “why” behind every epic and story.
By using Jira Product Discovery, you can:
- Centralize Feedback: See exactly what customers are saying and link it to the features you are building. As an engineer, you don’t just see “Build SSO integration” in a ticket. You see the customer quotes explaining why it matters and the workaround they’re currently using.
- Prioritize with Data: JPD allows teams to define custom fields – Impact, Effort, Strategic Value – and build custom formulas to prioritize objectively. As an engineer, you see the Impact Score next to the Effort Score. You understand why this feature is being built now instead of later, and you can participate in prioritization discussions with the same data as the Product Manager.
- Bridge the Gap: Eliminate the silo between the “idea” and the “execution,” empowering you to contribute to the strategy, not just the code. JPD links ideas to Jira issues, creating traceability from customer pain to shipped solution.
The translation layer is disappearing. What’s left is everything that matters: understanding the problem, user empathy, judgment, and taste. The Product Engineer isn’t a new role – it’s a mindset you can adopt today. Start by asking for context, attend customer interviews, read support tickets and more than ever, ask “why” more than “what.”