Field Notes · Act 2 — Prove · 03 of 13
What 77 Product Engineer Job Postings Ask For
Observe
The definition, and the 77 postings it is applied toThis article applies one definition to one sample. The definition is the working one from the previous article, built from 15 public sources. The sample is 77 job postings titled Product Engineer, collected on LinkedIn from 2026-09-24 to 2026-10-07 and read from their full public text. Every number here comes from the Product Engineer Opportunity Map, edition Sep–Oct 2026, where each posting, each mark and the excerpt behind it are public. It is an exploratory edition: the same postings were used to develop the reading rules, and the next edition will fix the rules and readers before collecting. This describes these postings, not the market. Searching the title selects companies that already use it, so the same work advertised as "Software Engineer" isn't here. A posting says what a company asks for in writing, not what the job turns out to be. And the definition is a working one: this article reads only the four steps of The Product Engineer Path; the practices around it and what each posting offers are on the map, with the full method and limits.
About half of the 77 postings titled Product Engineer ask for all of The Product Engineer Path: 41, or between 29 and 44 depending on how weak evidence is counted. When a posting stops short, it almost always stops at shipping: 33 of the 36 that don't ask for all four steps leave out Learn, and it stays the step most often missing when the four short summary ads are set aside. Nine ask for Build and nothing else. The title alone says little; read a posting for the four steps, and above all for the last one.
Last time, I read what people who do this work have written about it in public and arrived at a working definition: a Product Engineer is a software engineer who takes part in understanding real users' problems, deciding what is worth building, building it, and learning from what happens after it ships. This article takes on the next two questions in the series: what companies ask for when they hire under that title, and how much of that matches the definition.
THE QUESTIONS IN THIS ARTICLE
What does the market ask for under the title?
Job postings that carry the title "Product Engineer", read as a signal rather than a census.Chapters 1–2 ↓How much of those postings match that picture?
Each posting read against the working definition, with the uncertainty shown rather than hidden.Chapters 3–8 ↓The definition I'm applying
The definition rests on a sequence that kept coming back in the sources behind it: the same engineer carries a piece of work from the user's problem to the decision, the build, and what they learn after shipping. I call it The Product Engineer Path, and I read each posting for its four steps.
- ProblemGet close to who the user is, the problem they want solved and the journey to solve it.
- DecideDecide what is worth building, including what to cut.
- BuildBuild it end to end, often in small slices.
- LearnFind out what happened after shipping: usage, metrics, feedback, and what to change.
Each step has between one and three practices, 8 in all, with written rules for what counts. A step counts when the posting asks at least one of its practices of the engineer, in the "you will" sense. A company's values, its pitch or a benefit it offers don't count. Every mark rests on a verbatim excerpt, rated strong when the posting asks for the practice explicitly and weak when it only implies it.
77 postings with the title
The postings were found by searching the title on LinkedIn and collected from 2026-09-24 to 2026-10-07, with the full public text retrieved on 2026-10-07. Postings from Portugal were collected first and the others later through a different search, so this is a convenience sample, not a random one, and I treat all 77 as one set. Four are short summary ads: where they say nothing about a step, I read "can't tell", not "not asked for".
An AI reader (Claude) marked every posting against a written codebook. A second, blind reading by Claude Opus then reread all 77 for the steps of The Product Engineer Path, without seeing the first marks. Where the two disagreed, I decided against the codebook: 18 of the 68 disagreements, the ones that could change the results. The other 50, all weak marks added by the blind reader, stay open and out of the counts; counting them gives the top of the range below. Both readers come from the same model family, so they may share errors. The full method, agreement figures and decisions are on the Opportunity Map.
Reflect
How much of The Product Engineer Path each posting asks forAbout half ask for all four steps
Of the 77 postings, 41 ask for all four steps of The Product Engineer Path. 9 ask for three, 18 for two, and 9 for one. It is a gradient, not a pass or fail: a posting that asks for three steps is not the same as one that asks for one, and neither is a fake Product Engineer job.
How firm is "about half"? It depends on the weak marks. Counting only strong evidence, 29 postings ask for all four steps. Counting strong and weak evidence as decided, 41. Adding the open weak marks from the blind reader, 44. So the honest statement is a range, from a bit over a third to a bit over half, with 41 as the reading I stand behind.
When the four steps are written down, they're hard to miss. Purelend's posting has a sentence for each one:
- 1 · Problem
You'll be in front of brokers, underwriters, and lender executives every week. Not surveys. Calls, screen shares, ride-alongs, sometimes office visits.
- 2 · Decide
You spend more of your time talking to customers, defining what's worth building, scoping it tightly
- 3 · Build
You ship production code regularly, not as a side hobby but as part of the role.
- 4 · Learn
You define what success looks like before we build. You watch the metrics after we ship. You kill what isn't working
ActiveProspect sums up the arc in one line: Frame the problem, design it, ship it, own the metric.
Learn is the step that goes missing
Build is in almost every posting (76), followed by Problem (60) and Decide (56). Learn comes last: 44 of the 77 ask the engineer to find out what happened after shipping.
Learn is also what separates a full reading from a partial one. Of the 36 postings that don't ask for all four steps, 33 leave out Learn. Decide is missing from 21 of them and Problem from 17. Build is missing from one. Four of the 36 are short summary ads, where a blank means "can't tell" rather than "not asked for"; set them aside and Learn is still missing from 29 of the 32.
Kota is a clear case. It asks for the first three steps in plain words, and then the request stops:
- 1 · Problem
Join client calls where it helps you understand or explain a problem
- 2 · Decide
This is an autonomous role, you'll be trusted to make product calls, not just technical ones.
- 3 · Build
Design and build the systems that power Kota's Investments products
- 4 · Learn
Not asked for
Offered, not asked:
you'll see the impact of what you build, and hear directly from the people using it
The closest it comes to learning is a benefit. That's a good promise, but it's something the company offers, not something it asks you to do.
The gap matters because Learn is what closes The Product Engineer Path. A posting without it describes the work up to delivery and says nothing about finding out whether it worked. That doesn't mean nobody does it in the job; it means the posting doesn't ask for it.
Learn is also the step where the two readers disagreed most often: they agreed on 64 of 77 postings (Cohen's κ 0.66), against 73 for Problem (0.84) and 68 for Decide (0.7). Build's κ is 0 only because almost every posting has it, a known quirk of the measure. The blind reader marked Learn more often than the first one did, but in its reading too Learn is the step asked for least. The gap is clear in direction; its exact size is not.
Where the other postings stop
The postings that ask for two steps split in two ways. 11 ask for Problem and Build: the engineer is asked to understand the problem, though only a few of these postings say it means talking to users, and isn't asked to decide what to build. Salsify is one, and one of the few:
- 1 · Problem
Lead or support requirements discovery (via calls, async docs, team meetings) to capture needs, edge cases, success metrics, and constraints.
- 2 · Decide
Not asked for
- 3 · Build
orchestrating AI-assisted changes through structured workflows
- 4 · Learn
Not asked for
7 ask for Decide and Build: the engineer decides, but nothing in the text asks them to get to the user's problem first. Jiga is one:
- 1 · Problem
Not asked for
- 2 · Decide
Real ownership where you decide what to build, how to build it, and when to ship it.
- 3 · Build
You're genuinely full-stack - you're equally happy building a slick UI component or optimizing a database query.
- 4 · Learn
Not asked for
Of the postings that ask for three steps, 6 stop exactly at shipping: Problem, Decide and Build, without Learn. The other three leave out an earlier step instead: Liftoff asks for Problem, Build and Learn but not Decide; Insparya for Decide, Build and Learn but not Problem; and Doit, below, for everything but Build.
Build only, and the mirror case
Nine postings ask for Build and nothing else on The Product Engineer Path; one of them is a summary ad. The rest describe engineering work, often good engineering work, without the other three steps. Lightning AI wants you to Write readable/testable/efficient code in React and either Python or Go (Golang).
Pluxee España's wording sounds like more:
- 1 · Problem
Not asked for
- 2 · Decide
Not asked for
- 3 · Build
You'll own features end-to-end — backend, frontend, and the AI-assisted workflows
- 4 · Learn
Not asked for
Owning features end to end sounds like The Product Engineer Path, but here it describes the stack: end to end across layers, not from a user's problem to what happened after release.
The mirror case exists too. One posting asks for Problem, Decide and Learn but not Build. Doit wants someone to define the problem, decide and follow up after launch:
- 1 · Problem
Define user problems, product scope, success metrics, roadmap and launch plans.
- 2 · Decide
Use data, feedback, research and production issues to improve product decisions.
- 3 · Build
Not asked for
- 4 · Learn
Launch features, monitor performance and drive iterations.
It calls for builders
and asks you to launch features, but none of its excerpts asks you to write the software; it asks you to Work with engineering, design, data, operations, compliance and business teams.
It reads like a product manager's job. The definition starts with a software engineer, so this posting covers the product side of The Product Engineer Path without the engineering step.
Make
Four questions to read a posting before applying, and what the postings say about the signalSo, how much of a Product Engineer are they asking for?
About half of these postings ask for all of The Product Engineer Path, between 29 and 44 of 77 depending on how you count weak evidence. The rest mostly stop at shipping, and a few use the title for engineering work and nothing more. That is a reading of 77 postings against a definition that is still being tested, not a verdict on any company or any job.
What I take from it is a way to read a posting before applying. Ask four questions of the text:
- Does it ask me to get to the user's problem myself?
- Does it let me decide what is worth building?
- Does it ask me to build it?
- Does it ask me to find out what happened after we shipped?
Each column is one posting; each row is one question. Build is asked in 76 postings, Problem in 60, Decide in 56 and Learn in 44.
The more of those a posting answers in writing, the more of The Product Engineer Path the company is asking for. A posting is not the job, so treat the gaps as questions for the interview. Pay the most attention to the last one: it is the question postings leave unanswered most often.
Every posting, with the excerpts behind each mark, is on the Product Engineer Opportunity Map. Open one you're considering and see where it stops.
What the postings say about the signal
This series started with one signal: a Product Engineer posting at DOJO AI that put technology, business and design in the same job. One posting is an anecdote. Of 77 with the same title, about half ask for the same combination in writing: getting to the user's problem, deciding what is worth building, building it, and finding out what happened after shipping. DOJO's posting is one of them.
So the signal holds beyond one company: the full profile is something employers write down, not only something practitioners describe.
Confirmed: 41 of 77 postings ask for all four steps, DOJO AI's among them. Qualified: nine ask for Build only; Learn is the step asked for least by employers (44 of 77) and described by the fewest practitioner sources (9 of 15). Open: why now, and whether the share is growing.
The qualification matters as much as the confirmation. The title on its own is a weak signal: to know which job you're looking at, you have to read past it. And the step that closes The Product Engineer Path is the one written down least, by employers and, in the previous article, by practitioners too, if only by one source. If Product Engineering is about owning the outcome and not just the delivery, that last step is where the title and the work most often part ways.
Why employers are asking for this now, whether AI changing what one engineer can do or something else, is the series' next question. The next edition of the Opportunity Map will show whether the share moves.
Engineers who apply by the title alone are reading half the job ad.
Each Field Note reads real job postings against The Product Engineer Path and publishes the data. Subscribe to the newsletter and the next note arrives in your inbox.
Enable JavaScript to subscribe, or get in touch by email.