We can't find the internet
Attempting to reconnect
Something went wrong!
Hang in there while we get back on track
Factories, one silo at a time
In TBM 448, John Cutler argues that as AI threatens professional expertise, people are moving "one layer up." Instead of doing the work, they design, orchestrate and govern the systems that do it. He calls this a way to protect professional identity and possibly gain a new source of organizational power . Engineering is leading the "software factory" story because it saw the earliest measurable AI productivity gains. Cutler says it's an open question whether a factory model fits product development, where discovery, design, building and learning are deeply intertwined .
His main complaint is about boundaries. Engineering factories say little about what happens before and after code is produced. PM factories stop where software factories begin. GTM factories cover only their own slice . In his words, we're "reimagining the future of work one professional silo at a time" . His alternative is the cross-functional team as the unit of value, owning the problem, discovery, decisions and outcomes together .
"Liquid software"
Patrick Collison now adds an "improvements" box to his personal vibecoded apps. Whatever a user types is handed to an agent that implements it. One other user has already shipped 150 improvements in a few days . He asks openly whether the approach stays maintainable, how it would work for collaborative software, and whether it can be secure and reliable. For personal tools, though, he says it "definitely works great" . Hiten Shah replied: "This is the way" .
The PM job market is splitting
Aakash Gupta cites Live Data on worldwide hires. In February–June 2022, 52,664 PMs started jobs at a new company. In the same months of 2026, the figure was 29,223 (an early read). Over the same period, AI PM hires rose from 789 to 1,988 .
Gupta also summarized Google AI PM Director Jaclyn Konzelmann's five-question rubric:
- Pitch a beachhead product that feeds data into a larger platform .
- Your moat has been copied for free by a model update. Her rubric scores how you lead and talk to your team, not only your strategy .
- Describe failures from AI systems you actually shipped .
- Name the overlooked feature in a famous AI product .
- Build conviction without an A/B test, treating qualitative evidence as rigorously as quantitative data .
Gupta reviewed 316 public profiles of people in product roles at companies that train AI models. 85% were PMs before joining, 24% started their careers in product, and 2% have PhDs. His suggested path: own the AI feature closest to the model, learn to build evals, then move to a team where the model is the product .
When the signals contradict each other
Ravi Mehta's workshop case is loosely based on a real Tripadvisor story. Every A/B test wins and beats the holdout, yet overall conversion is falling fast . Neither number is wrong. His point is that you have to explain how both can be true before you decide anything. A second case, an AI tutor, asks what to optimize when better learning outcomes may cost user satisfaction and retention .
Hiten Shah argues that marketing has become a way to avoid changing your mind. Teams rewrite messaging, tune onboarding, then spend more, instead of questioning the product or who it's for . Because acquisition decides who becomes a customer, it also shapes product feedback: "attract the wrong people and you can spend months building exactly what they ask for." AI makes campaigns cheaper, but acting on wrong assumptions costs as much as ever .
Working practices
- Product and sales (ProductTank Auckland). Define the ideal customer profile (ICP) by the economic value the customer gets in their own P&L, not by your price or features . Before escalating a feature request, check deal size, strategic value, whether it repeats across a segment, and cost to deliver, because "one large prospect is not equal to a market need" . Hold individual requests at a gate. Only a recurring pattern moves on to product opportunity and then the contractual roadmap. Review the ICP and value proposition quarterly based on evidence .
- Shared agent memory. On r/startups, a team asked how to share Claude Code/Codex notes. The most concrete reply: treat the notes like code. Keep one AGENTS.md at the repo root linked to topic files, review changes in PRs, and date and justify every note . Keep machine-specific workarounds out of it .
- GenAI unit economics. A creative subscription app with about 4,000 users and 50 agencies can't break even without losing price-sensitive subscribers . The top advice: split contribution margin by customer type and usage decile. Test capped individual tiers and agency tiers with overages on new signups, and temporarily keep existing customers on current pricing . The founder rejected switching to cheaper models because the quality drop would be noticeable .
- Product and sales should jointly define the ideal customer profile and value proposition around customer-derived economic value, such as impact on the customer’s P&L, rather than the vendor’s price or feature set. Product should analyze users, problems, and what to build; sales should validate commercial fit, bring market evidence, and help prioritize buyers.
- Treat feature requests as market signals to qualify, not automatic roadmap commitments: check whether a request is a one-off or a recurring segment pattern, and weigh deal size, strategic value, repeatability, and delivery cost. A recurring pattern can advance through a request gate toward a product opportunity and contractual roadmap.
- Replace escalation-only contact with an agreed operating rhythm: frequent sharing of roadmap intentions, joint customer discovery, monthly product-sales insight sessions, win-loss reviews with follow-through, a shared log of objections and requests, and periodic evidence-based ICP/UVP reviews. Make clear which roadmap items are intentions versus commitments.
- For high-stakes commitments, one telco used a cross-functional “tiger team” with finance, technical, and sales leadership to assess feasibility and give sales a realistic delivery window before going back to the customer. Sales KPIs and commission plans also shape behavior and may need adjustment when incentives produce the wrong outcomes.
Teams using Claude Code/Codex can repeatedly rediscover workflow failures when agent notes stay on one developer’s machine; the post reports 65+ notes in one repo and says colleagues’ agents start from zero. A team process described in replies is to keep shared, version-controlled agent guidance (a root AGENTS.md plus linked topic files), load it at startup, and review changes in PRs; give entries a reason and date, and remove anything teammates cannot verify or explain. Keep laptop- or rate-limit-specific workarounds out of shared guidance unless they apply to the team, since they can make other agents work around problems they do not have. For human and cross-tool access, commenters also suggested shared locations such as Confluence and centrally curated knowledge bases that pull from multiple sources.
a16z Speedrun said it was investing up to $1M in new startups, offering $10M in credits, and providing coworking at its new San Francisco offices; applications were in their final 48 hours, with a follow-up post saying the deadline was tomorrow.
- The AI “factory” shift moves professionals from doing work toward designing, orchestrating, and governing systems that do it—a response that can preserve professional identity and create a new source of organizational power. The post says software engineering is an early center of this framing, but whether factory models fit end-to-end product development remains open because discovery, design, building, experimentation, and learning are intertwined.
- Profession-specific factories risk reproducing the silos cross-functional product development is meant to transcend: engineering factories abstract away upstream and downstream work, product-management factories stop where software factories begin, and design is left between them. The post’s alternative is a cross-functional team as the unit of value creation, collectively owning the problem, discovery, decisions, and outcomes.
- For a creative subscription app with about 4,000 users and 50 agencies, blended economics may hide important differences: analyze costs by customer type and usage decile—the advice suggests the heaviest 5–10% may drive most compute or storage costs—and track contribution margin after variable infrastructure and support for each cohort.
- To test monetization on new signups, the advice proposes an affordable individual tier with usage caps or credits, agency pricing per seat or workspace with higher included usage and overages, and temporarily grandfathering existing customers. Cost-side suggestions included routing simpler requests to smaller models and caching, though the founder cautioned that cheaper image/video models would visibly reduce quality and risk losing clients.
- Treat internal user research and external market signals as complementary discovery inputs, then test the hypotheses they generate with experiments; one comment frames product-market fit as alignment between a specific segment and an effective solution.
- Let behavior guide the starting point: study the job for a small cohort that repeatedly returns or pays; if usage is scattered, select a segment and test whether people use or pay for a small offer. A reply also suggests asking current users whether they would care if the product disappeared as a fit check.
- One suggested retention heuristic: persistent nonzero cohort retention supports deeper user analysis, while retention that decays to zero may make existing-user data more useful for diagnosing churn than fit.
- Treat weak campaign performance, signups that do not translate into retention, or slowing growth as prompts to reconsider product and target-customer assumptions—not only to revise messaging, onboarding, or spending.
- Acquisition shapes who becomes a customer and whose feedback influences the product, so attracting the wrong audience can lead teams to build what that audience requests. Use campaigns to learn what could change the business, interpreting responses rather than merely measuring them; AI makes campaign production cheaper but does not reduce the cost of acting on bad assumptions.
Hiten Shah endorsed @patrickc’s pattern of adding a freeform “improvements” input to personal apps, connected to an agent that implements submissions; one user reportedly made 150 improvements in a few days, lowering the barrier to fixing rough edges and adding features. The pattern is described as effective in personal use, but its scalability, maintainability, collaboration, security, and reliability remain open questions.
- A deeptech founder advises against making startup founders the sole GTM/ICP focus: the founder says many are cash-constrained and will fail, while prospects may build solutions themselves or buy from market leaders, limiting the long-term revenue potential of hard-won customers.
- Treat this as a deliberate segment bet, not a blanket rule: a commenter says established-company sales can tailor a product to the current market, while startup customers may help define a future market—a higher-risk, higher-reward path. Vercel and Supabase were offered as counterexamples of companies winning with founders, and the original poster conceded foundational services may be different.
- Worldwide PMs starting jobs outside their companies fell from 52,664 in February–June 2022 to 29,223 in the same months of 2026 (an early read, reported as a 45% decline), while AI PM hires rose from 789 to 1,988 (2.5x).
- Google AI PM Director Jaclyn Konzelmann's five-question candidate rubric tests whether a candidate can connect a narrow product beachhead to a larger platform opportunity, using the beachhead to generate data ; respond to a moat replicated by a model update with both strategy and team communication/leadership ; describe real production failures and redesigns in an AI workflow ; identify an overlooked feature in a well-known AI product ; and build a rigorous case for a bet using qualitative signals, proxy data, and tech trends when A/B testing or precedent is unavailable .
- In Aakash Gupta's review of 316 public profiles in product roles at companies training AI models, 85% had been PMs before joining a lab, 24% started their careers in product, and 2% had PhDs; he recommends moving toward model PM work by taking AI-feature work close to the model, learning to build evaluations, and then joining a team where the model is the product.
A former coach, Agile coach, or Scrum Master asked how to move into a product role or become a product coach, noting that product-role experience is needed for the latter . One commenter cautioned that Scrum- and delivery-focused experience is closer to PO work than PM work, and asserted that 80% of PM work happens outside delivery .
- A student is building Product Reps, a free PM-intern interview-prep hub for posting real interview questions, sharing and discussing answers, and getting AI feedback. Its premise is repeated practice and community feedback rather than reading frameworks alone.
- Feedback recommended anonymous posting, optional company names, asking only for the interview round and question, an “I was asked this too” vote to show frequency and help flag invented questions, and seeding the feed to avoid an empty-feed problem. The builder says they are adding these features and seeding prep questions.
- During development, suggested indicators include schedule and development cost, time to market or first sale, and successful beta exit with favorable feedback. One commenter prefers “time to money,” arguing that shipping quickly is not enough if the product misses the business goal.
- After launch, suggested measures span commercial results—revenue, growth, profit, and churn—and product outcomes such as adoption, retention, and whether users solve the intended problem. Free-tier adoption as a potential route to revenue and the effort required to maintain the business were also mentioned.
Product data fluency goes beyond using analytics tools: PMs should investigate apparent contradictions, challenge assumptions, and turn evidence into a decision. In one example, A/B tests showed gains while overall conversion fell; neither measure was wrong, so the evidence must be reconciled before advising whether to move the team elsewhere . For an AI tutor, product managers may also need to decide how to optimize when better learning outcomes could come at the expense of user satisfaction and retention .
A product-team leadership question as generative AI automates layout, design-system, and code production: the author argues that design leadership may shift from producing screens toward systems orchestration—integrating structural constraints, human needs, and delivery realities across work historically divided among designers, engineers, and PMs. The open question is whether teams will instead keep measuring success by screens shipped per sprint.
After a poor review under forced stack ranking and a move to a new team, the poster says leaders’ view of their impact differed from their own. Advice: align early with the new lead on role measures, comparison group, and progress through the review cycle; collect objective evidence and report it transparently. A commenter suggests asking what success looks like in 90 days and sending a weekly Friday recap of completed work and next steps (three bullets maximum) to build alignment and a visible record of output. Another commenter cautions that stack ranking can consume effort in disputes over performance metrics and undermine collaboration, while coercive management can add non-value-creating costs.
- Validate demand before investing in a build: the founder recommends selling first and using repeated conversations with potential customers to shape the product.
- Keep the product focused on a niche rather than adding features to address the entire market, even if that means leaving part of the market unserved.
- In his building-compliance AI attempt, the founder said potential customers did not trust him or the product and that being unlicensed may have contributed; a technical MVP and substantial compute access did not resolve his trust and go-to-market problems.
Patrick Collison is adding a freeform “improvements” input to his personal vibecoded apps, connected to an agent that implements submissions. He says this makes polishing rough edges or adding features extremely low-friction; one user had already implemented 150 improvements in a few days. He describes the pattern as “liquid software” that lets users modify their tools, and says it works well in personal use. Whether it can scale while remaining maintainable, collaborative, secure, and reliable is still an open question.
- A practitioner with payroll-product and HRIS implementation experience says they have not found an HRIS system users like, and advises HRIS PMs to build resilience, navigate organizational politics, understand customer problems and competitors, and know their product’s differentiator.
- HR technology products increasingly need to interoperate across ATS, payroll, and HRMS systems, making integration knowledge important for PMs in this space.
For product managers moving between verticals, emphasize measurable resume outcomes—such as revenue growth, adoption, or retention improvements—instead of listing responsibilities.
TBM 448: The Software Factory as Identity Defense (and Reinvention)

“Software factory” is a kind of identity defense (and branding). And there’s a historical precedent here.
I’ve been pondering the almost Dionysian fervor surrounding all these new “factories” people are building. The sheer exhilaration, obsessive energy, and unmistakable pride people seem to take in building systems that build things.
Imagine your whole profession of “building” has shifted. Things that underpinned your identity are no longer considered valuable. Historically, your expertise gave you considerable influence over what could be built, how it would be built, how long it would take, and what trade-offs were necessary. Suddenly, the act of producing software became dramatically cheaper. Your traditional source of scarcity (and therefore power) is threatened.
What do you do?
You move up a level. You become the architect of the software factory. You control the orchestration, infrastructure, standards, quality gates, security, evaluation, and deployment systems. You may no longer have a monopoly on producing software, but you can establish authority over the means of production.
When technology automates work central to your professional identity, one attractive response is to become the person who designs, operates, and governs the automation. That can be productive adaptation, genuine craftsmanship, identity preservation, and a defense of professional authority. All at once.
This is not new. As industrialization transformed traditional crafts, some skilled craftspeople shifted their attention from making things to designing the systems that made things. For example:
Eli Terry (clockmaker → clockmaking machinery)
Josiah Wedgwood (potter → factory design and production systems)
Henry Maudslay (metalworker → precision machine tools)
Joseph-Marie Jacquard (weaving → programmable looms)
Frederick Winslow Taylor (machinist → scientific management)
You shift your focus to “building” a factory. It is like CI/CD, infrastructure as code, automated testing, deployment pipelines, and developer platforms. But now for AI agents. You get to preserve the identity of being a builder.
Let’s go back to 2012. What were we debating then?
Netflix’s Adrian Cockcroft described an organization with little need for operations staff, because the cloud let them automate so much of the old work. John Allspaw at Etsy called “NoOps” “the dumbest marketing term ever coined in my field.” Julian Dunn wrote a post titled “Chef, devops, and the death of system administration,” and argued that “pure systems administration is eventually going to die out as a profession.” Jez Humble argued there’s no such thing as a “devops team,” and then conceded that somebody has to build the platform developers use to self-serve. Around the same time, James Bach and Michael Bolton drew a line between “testing” and “checking,” so that automating the checks wouldn’t be mistaken for automating the tester.
Same dynamics.
In an idealized version of product development, I’ve always imagined the cross-functional team taking precedence. It has an identity of its own. Makers. Value generators. People with different skills, perspectives, and experiences coming together to figure out what is worth building, how to build it, and how to learn along the way. Inclusive building. The team is the unit of value creation, not any particular function or discipline. The team collectively owns the problem, the discovery, the decisions, and the outcomes.
What I think is happening right now with the “software factory” is that the narrative is emerging primarily from within the engineering community, partly for the psychological and identity-related reasons I’ve been discussing.
There’s also a practical reason.
Some of the earliest and most measurable productivity gains from AI have been in software engineering. So it’s understandable that engineers are among the first to experience both the extraordinary possibilities and the threats to their established expertise. And it’s understandable that they’re imagining the future through the lens of their own craft: orchestration, pipelines, infrastructure, automated testing, and factories.
It’s perfectly logical, for all the reasons mentioned, that we’d gravitate toward the software factory metaphor. But it’s an open question whether the emerging factory model is actually a good fit for the domain of end-to-end product development, where discovery, design, building, experimentation, and learning are deeply intertwined.
And it’s not just software engineering. Everyone seems to be building a “factory” right now, whether they call it a software factory, a product management system, a GTM factory, a content engine, or something else.
There’s a much broader movement underway. As AI threatens the skills, expertise, and activities that underpin our professional identities, we’re embracing the technology and trying to position ourselves one layer up. Instead of doing the work, we design, orchestrate, and govern the systems that do the work.
It’s a way to preserve our identities, demonstrate our continued relevance, and potentially establish a new source of organizational power.
What isn’t happening nearly as much as it should is a serious consideration of the cross-functional nature of the problem. Most of these emerging “factories” seem to stop at the boundaries of existing professions. Engineering-led software factories are often remarkably abstract about what happens upstream and downstream of software production. Product management factories tend to stop where the software factory begins. GTM factories focus on their own slice of the value chain.
And poor design is sitting somewhere in the middle wondering WTF is going on.
We’re all enthusiastically building systems that preserve our professional identities and potentially give us a new source of power, but we’re still organizing those systems around the very functional boundaries that cross-functional product development was supposed to transcend.
We’re reimagining the future of work one professional silo at a time.
- The AI “factory” shift moves professionals from doing work toward designing, orchestrating, and governing systems that do it—a response that can preserve professional identity and create a new source of organizational power. The post says software engineering is an early center of this framing, but whether factory models fit end-to-end product development remains open because discovery, design, building, experimentation, and learning are intertwined.
- Profession-specific factories risk reproducing the silos cross-functional product development is meant to transcend: engineering factories abstract away upstream and downstream work, product-management factories stop where software factories begin, and design is left between them. The post’s alternative is a cross-functional team as the unit of value creation, collectively owning the problem, discovery, decisions, and outcomes.