Faire turns its engineers into "product builders" so AI doesn't make product design the bottleneck

The article, published on Faire's engineering blog (The Craft) and written by Thuan Pham, Jorjena Dankha and Matt Bolohan, describes how the company has responded to AI dramatically speeding up the writing of code. According to the piece, for decades programming was so expensive and slow that good teams invested heavily up front in product requirements, flow design and prototypes to reduce risk before building. With AI automating much of the coding work, that logic has changed.

The key figure Faire offers is that, over the past year, the typical engineer roughly tripled their complexity-weighted PR throughput, and top performers did much better still. The metric covers 214 engineers present in both periods. It uses an AI-based scoring service that weights for complexity so that small PRs don't inflate the numbers, and the same model was used for both periods. Each person is compared against their own baseline across two 12-week windows: October 24, 2025 to January 15, 2026, versus July 31 to October 22, 2026.

The problem they identify is that the heavy product design process, which used to keep pace with code, became the new bottleneck. They rule out the simple fix of hiring many more PMs and designers, because more people means more handoffs, and handoffs were already slowing work down. Instead, they chose to develop their engineers as “product builders”: engineers who understand the business, have good judgment about what to build and not just how, and share responsibility for customer success.

At Faire these profiles are called “product engineers” to distinguish them from other specializations (platform, infrastructure, security). The authors note that the idea also applies to those areas: their customers are other engineers, and for them design thinking means the elegance and usability of an API or a component architecture. What separates an engineer from a “builder” is this added layer of product and design thinking, in any domain.

The basic development sequence (ideas, requirements, design, code, launch) still exists; what changes is how teams move through it. Instead of routing each feature through PMs and designers for requirements and specifications, product engineers take most features end to end, many of them in parallel. This frees PMs and designers to focus on the thorniest customer problems, where they too can use AI to prototype and quickly refine requirements and design decisions.

The program began on July 1 with a six-month timeline to take all product engineers through the learning curve. The article highlights three tactics. The first is candor: leadership was explicit with teams about what the change meant, comparing AI to earlier productivity waves (compilers, open source, the cloud, modern frameworks) and acknowledging that it is both exciting and intimidating, because everyone must learn new skills or risk becoming obsolete. According to the authors, that honesty built more trust than trying to sugarcoat the situation.

The second tactic is practical guidance grounded in real experience. In the first half of the year they created a couple of “AI Amplified” pods, small cross-functional product teams, as an experiment to find where the real bottlenecks in the development cycle lie in the AI era. Based on that, they set the goal that every product engineer should own a feature from start to finish and ship it, and they built an enablement hub with skills for AI coding agents, resources, live training and a “playground” for rapid prototyping. They also introduced a three-tier “Complexity Tier Framework” that matches a task's cross-functional complexity to the engineer's current capabilities. They clarify that the tier reflects cross-functional complexity, not engineering difficulty: a technically hard task within a single team and with a familiar UX can still be Tier 1.

The third tactic is a commitment to coaching. The authors warn that, with AI making everything faster, enthusiasm can easily turn into unproductive impatience, and that sometimes you have to slow down a little to retool and then go much faster. They acknowledge a tension: they wanted engineers on the highest-impact problems but were constrained by their level of skill development, so they directed some capacity toward smaller-scope opportunities. Now, with greater proficiency, they tackle big problems by breaking them into subproblems that a product engineer can own end to end.

To do this deliberately, they updated written performance expectations, brought in senior PMs and designers as mentors on the principles of product and design thinking (backed by product, design, analytics and experimentation toolkits) and set up assessments every two months. Engineering managers rate each dimension as Developing, Capable or Strong, with input from their product and design counterparts. Managers themselves are assessed by the same standard by their directors and their product and design partners.

As for results, four months into the new model, two months after launch 71% of product engineers had already shipped a feature end to end, and in the first assessment the share rated Capable or Strong in product and design thinking rose from 41% to 65%. The second assessment is underway, and the goal is to reach 85% or more by year-end.

The article gives two examples. In one, an engineer noticed that recommendations in a beta program for retailers weren't personalized enough, analyzed the data, wrote the PRD, aligned with their PM and a data science partner, and launched richer recommendation sources that increased the program's order volume by 1.5%. In another, an engineer proposed refactoring retailer sign-up, realized it required a new product surface, designed the flows with a designer and ran an experiment; when the sign-up completion rate came out negative, they investigated and found a flaw in how the experiment was being measured, and once it was fixed the result was positive.

The authors conclude that when AI moves the bottleneck, people can move with it: smart, motivated engineers learn quickly if they are spoken to candidly, given work matched to their level and receive real product and design coaching. It is worth noting that this is a corporate piece from the company itself, which also ends with a job posting, and that the metrics (AI-weighted throughput, internal skills assessments carried out by the managers themselves) are internal and cannot be verified externally.