The clearest product decision I’ve made in the last three years was a number. Ninety-six percent. The HTSUS classification agent we shipped at The Product Highway labels nine hundred thousand line items per night, and we agreed up front that the product would only ship if it crossed ninety-six percent on a held-out evaluation set. Below that, the ops team kept doing manual review. Above that, they didn’t.
Nobody on that call called this a product decision. It was framed as an engineering threshold. But it was, in fact, the entire spec. The user-facing artifact of an AI agent is its accuracy under a known cost ceiling, and the only people in the room who could pick that number honestly were the ones who knew the model, the data distribution, and the retrieval index. A PM could write the user story. None of us could have written the spec.
That’s the seed of this essay. I’ve come to think the split between product thinking and engineering thinking is mostly an org-chart artifact. The strongest product voices in the last twenty years, Carmack, Collison, Jobs in his second act, the early Stripe team, were all people who could either build the thing or had built something close enough to know what was possible. This is the engineer-as-tech-lead view of product. It’s the view I’ve had to live in for most of my career, and it’s the only one I trust myself to argue from.
What “product thinking” actually is
Marty Cagan’s working frame is the cleanest. In Discovery vs Delivery he argues a product team has to satisfy four constraints at once: value, usability, feasibility, business viability. Most teams I’ve been on are built to optimise for two of those four at a time. Two of the four go on the wishlist. That’s why so many products feel like the engineering team, the design team, and the PM all agreed to disagree.
The other frame I keep coming back to is Bob Moesta’s reformulation of Jobs To Be Done. People don’t buy products. They hire them to make progress in a struggling moment. Half of all milkshakes were sold before 9am because people hired the milkshake to fill a boring commute, not to replace breakfast. The job is the variable. The product is the packaging. Once you internalise this, half the feature requests in your backlog stop being feature requests and start being misread jobs.
ViddyScribe, which won Gemini App of the Year in 2025, works because the job is sharp. A creator has a raw fifteen-minute clip and needs a polished short for distribution by tonight. The product’s feature surface is the smallest one that satisfies that one sentence. Upload, wait, download. Every feature we shipped was tested against that sentence. The features we killed didn’t die because they were bad ideas. They died because they were answers to a different job.
The false dichotomy
The PM-versus-engineer turf war is an artifact of a particular era of scale at companies that needed legibility for hiring and performance reviews. It isn’t a fact of nature. The strongest evidence is Stripe, where the founders write a lot, engineers are expected to have product opinions, and Patrick Collison’s long-form interviews spend more time on craft and writing culture than on org charts. Stripe is, more than anything else, a product company in which the people who design the API are mostly the people who write the API.
Charity Majors’ engineer/manager pendulum applies cleanly to product. The best product voices are two to three years from shipping. The moment you stop building, you start estimating what builders can do, and that’s a worse job, badly done. Every PM I’ve seen earn the team’s trust did it by pairing on code reviews, not by writing better tickets.
How to spot a great product
Des Traynor’s talk Product Strategy Means Saying No is the most useful single piece of strategic content I’ve ever watched, and it’s ten years old. His argument is that without strategy, products get pigeon-holed by their backlog and end up the biggest version of themselves rather than the best one. Building a feature because the competition has it never works. The artifact of strategy is the list of nos. If you can’t produce that list, you’re not running a product; you’re running a feature factory.
Great products are legible. You can describe what they refuse to do. Linear refuses to be Jira. Stripe refuses to be a checkout widget vendor. The conversion-lift chatbot we built refused to be a support bot. We framed it as a sales associate. That’s why it lifted sales sixteen percent and cut cart abandonment by thirty-one. If we’d framed it as a support agent, we would have spent the next quarter answering refund questions, and the conversion lift would have stayed on the slide deck.
Steve Jobs’ 1997 WWDC line is the canonical version. “Focusing is about saying no. I’m as proud of the things we haven’t done as the things we have done.” Substitute “refused” for “haven’t done” and you have a usable test for taste.
The engineer’s leverage on product
Engineers know what the system can almost do. PMs estimate it. That gap is where most of the leverage hides. The compounding effect comes when the same person can write the spec and the prototype. You stop having to make the case for what’s possible because you can just demonstrate it.
Steve Yegge’s accidental 2011 rant captured the canonical example. The Bezos API mandate, where every team had to expose its data through a service interface with no exceptions, was written as an org memo. It was a product strategy in disguise. Only an engineer-leader could have written it, because it was an architectural mandate underneath, and only architects know which mandates are buildable. The product, in retrospect, was “every internal capability is externalisable by default,” which turned out to be AWS.
John Carmack put it in two lines worth taping to the wall: focus is a matter of deciding what things you’re not going to do, and programming is not about typing, it’s about thinking. His output for forty years has been disproportionate to his employer count for one reason. He ships products by writing code, and he writes code by holding the system in his head long enough to know what to leave out.
The discipline of saying no
Shreyas Doshi’s LNO framework cuts every task into Leverage, Neutral, or Overhead. Leverage deserves perfectionism. Overhead deserves speed, not quality. The mistake most product roadmaps make is treating everything as Leverage, which means everything also gets the Overhead treatment in practice. Your quality time gets consumed by tickets that should’ve been three lines and a JIRA close, and the actual leverage work goes out half-baked.
The roadmaps I’ve watched work are not lists of yeses. They’re lists of nos with a thin veneer of yeses on top. Marty Cagan’s outcome-driven roadmaps push the same way. Assign teams to problems with desired outcomes, not to features. The features are downstream.
Lenny Rachitsky’s retention writing is the corrective for any team confusing output with outcomes. Retention is the scalable way to grow a product; it’s the cleanest single signal of product-market fit anyone’s found. If your retention curve is flat, you have a packaging problem at best and a product problem at worst, and either way, more features won’t fix it.
What to ignore
Most product frameworks are scaffolding for taste you haven’t built yet. RICE is what you use until you can look at a backlog and feel which row is lying to you. Personas are useful for the first three customer interviews and a liability after the thirtieth, when you should be quoting actual users by name. The North Star Metric ritual produces a number everyone repeats and that nobody’s daily decisions actually move.
Ignore the PM-versus-engineering turf war. Pay attention to the retention curve, where Lenny’s test still applies and flat is fatal. Pay attention to customer language. Teresa Torres’ opportunity solution trees are useful precisely because they force you to ground the tree in actual customer quotes. The keystone habit in her framing is talking to customers weekly. Mine has been more like every two weeks, and I can tell from my own work when I’ve let it slip. Pay attention, finally, to the smell of the codebase. Carmack’s thing about concentration versus architecture astronautics. When the code feels hard to extend in the direction the product wants to go, the product is asking you to refactor before you add. That signal is rarely wrong.
Closing
An engineer who’s shipped a 0-to-1 product knows things a PM can’t, because she’s lived inside the failure modes. The 4am rollback. The silent data drift. The user who hated the thing for a reason no survey would have surfaced. The strongest product thinker on a team is often the staff engineer who refuses to write a ticket until the failure modes are on the whiteboard, and who treats every roadmap conversation as if the answer might be “we should refund this customer and not ship it.”
The senior engineer’s superpower in a product meeting is the same as her superpower in a code review: the ability to say no out loud, in writing, with reasons. Marty Cagan and Bob Moesta and Shreyas Doshi will give you the vocabulary. Carmack and Collison and the Bezos memo will remind you that the vocabulary is a means, not the point. The thing you ship is still your responsibility.