We can't find the internet
Attempting to reconnect
Something went wrong!
Hang in there while we get back on track
Cheap building moves the hard part
A former PM working in e-commerce ops says he built an analytics system "in a couple of days." It replaced a Fabric-to-Power BI setup that cost a lot in freelancer fees and kept breaking. He chose to build add-ons for the order-management system instead of replacing it . His case for PMs is that AI gets "80-90%" of system requirements, "and sometimes that remaining 10% is huge." He adds that nobody is posting jobs for this work yet, so you have to create the market yourself . Replies pushed back on the cost. Building is cheaper, but "the cost of alignment. Stakeholder management. Making product and technical decisions" is not . Teams also bought SaaS to hand off maintenance and to get deep domain knowledge that is hard to find . Hiten Shah takes the macro view. He's "increasingly convinced" that most consumer and enterprise software "will be completely rewritten" .
Domain depth and finances as PM leverage
Productify argues that every industry keeps its own scoreboard: margins, unit economics, regulation, market share. A product can launch beautifully and still be "a success only on paper" . Knowing which problems are already solved commodities and which are still open "is itself domain knowledge," and that knowledge saves months . The author's advice on AI: it makes "breadth cheap," so use the time it saves to go deeper on fewer problems .
On One Knight in Product, Simonetta Batteiger makes the financial version of this argument. Token-heavy AI features add "a new margin risk." Costs should be tracked by user, workflow and interaction pattern, and doing that "starts in the code" . Her rule of thumb is that a team should return at least five to seven times what it costs. She also notes that most PMs "don't know what their team costs" . Her fix is to ask finance which revenue levers matter. She says no one in her course has been refused those numbers . She also says AI's non-determinism means PMs need rollback options, kill switches and evals in case a new model drifts .
A r/ProductManagement thread on "PM career as pursuit of power" debated where authority comes from. One reply: "There has to be one person with final decision power, and that is typically the PM" . Another said a good PM shares many decisions, guided by the team's expertise and the problems customers will pay to solve .
Evals: the demo isn't the evidence
Aakash Gupta shows why a clean demo proves little. An agent that fails 3% of the time still passes all 50 tickets in about 22% of runs . His "real" rollout sequence: an LLM judge says "95% good and catches zero failures." Then comes a 5% ship where "evals go up, usage stays flat." After that, a power user eats the margin, and a new model "calls tools differently" . His conclusion is that what decides success sits around the model: context, tools, permissions and checks .
AI PM listings: a few years of AI proof on top of normal tenure
Gupta also hand-classified 113 AI PM listings from LinkedIn. 69% explicitly wanted AI or ML experience, or 55% on a softer reading. Only 14 required that experience in production or at scale . Plain "Product Manager" listings asked for AI experience almost as often as AI PM listings (66% vs. 70%). The median listing asked for 5 years of PM experience . He suggests building real AI products people actually use, as opposed to fabricated credentials . This adds to his earlier 651-role analysis.
Briefly
- Row, then steer. Lenny Rachitsky summarized a playbook for PMs at big companies, from Atlassian CPO Tamar Yehoshua. The PM and designer vibe-code an alpha. Once it shows pull, they bring in engineers. Then the PM steps back to align, prioritize and unblock . It's a practical answer to the "no one steering" problem Atlassian described earlier.
- Rekhi's six-month workflow update. Sachin Rekhi now treats Codex as being as powerful as Claude Code . He calls local markdown context files "an anti-pattern" now that MCP-backed shared document repositories exist . He also recommends rebuilding design systems in code, documented in Storybook, so engineers can turn prototypes into production code faster .
- Companies agents can read. Building on Patrick Collison's argument, Hiten Shah says an agent should understand a business well enough to decide when it's relevant and complete the purchase. He thinks founders will have to design for this from the start .
- The Company OS combines an assistant with access through Slack, Telegram, iMessage, and GitHub, plus enterprise roles and permissions, a rollout dashboard, shared skills and context, and a security layer. Its stated use case is reducing repeated status and context-routing requests.
- In a test with his team, the bot searched 12 months of sponsor emails and found three sponsors by name who had asked for a media kit. A one-line Slack request then generated a PRD, prototype plan, engineering spec, and engineering-agent task list in three minutes; after human approval, the media kit went live.
- Gupta reports that Zapier CEO Wade Foster rated basic ChatGPT use “Capable,” a Claude OS “Adoptive,” and a complete Company OS “Transformative” on a PM AI-fluency scale.
- An agent with a 3% per-ticket failure rate can still pass all 50 tickets in roughly 22% of runs, making a flawless demo weak evidence; checks are needed to expose failures .
- In one AI-feature rollout, the team’s judge rated 95% of cases good but caught zero failures. The sequence described was to label real cases, check the judge against those labels, inspect traces, and pilot at 5%; evaluations rose while usage stayed flat. After a model change, rerun evaluations because tool behavior may shift . The author argues that context, tools, permissions, and checks around the model are decisive to whether the feature works .
- In the author’s manual review of 113 LinkedIn AI PM listings, 69% explicitly asked for AI/ML experience, though 40 judgment calls mean a softer reading lowers that to 55%; only 14 listings required production or at-scale experience. Plain Product Manager roles asked for AI experience nearly as often as AI Product Manager roles (66% vs. 70%), and the median listing asked for five years of PM experience . The author’s career advice is to build real AI product work, get people using it, and document decisions as verifiable “synthetic experience”—not fabricated credentials .
- Aakash Gupta introduced a Company OS intended to work through Slack, Telegram, iMessage, and GitHub, with enterprise roles and permissions, a rollout dashboard, and an assistant for early adoption . In his team’s example, it searched 12 months of sponsor emails, found three named sponsors who had requested a media kit, and turned a one-line request into a PRD, prototype plan, engineering spec, and task list; after human approval, a media-kit page went live .
- For PM career choices, define what “best” means before comparing employers: commenters suggest weighing exposure, craft-building leaders and problems, impact, mentorship, and the burden of shipping, alignment, and politics; they also distinguish priorities such as an early-career start, compensation, entering banking, challenge, or an easier pace.
- Commenters characterize Revolut as cutthroat or toxic and speed-driven, while also associating it with strong product talent; one cross-company anecdote says some ex-Revolut PMs seek a more sustainable pace and some people move to Wise for greater ambition.
- Monzo accounts conflict: a former PM who says they worked there from 2023 to 2026 reports substantial PM influence, pay of £95k+, lighter workload and better work-life balance, and learning value; a separate interviewee describes the salary offered as average, while other commenters characterize Monzo as slow or process-heavy.
- A former PM working with e-commerce clients argues that AI-assisted bespoke tools can make narrow workflow gaps worth solving: they built an analytics system in days after a costly, unreliable Fabric-to-Power BI setup, and chose to extend an order-management system rather than replace it. Another commenter describes a custom e-commerce pricing and assortment simulator as an alternative to spreadsheet work or a broad SAP rebuild.
- The product work is translating business context into requirements, not just generating code: the PM estimates AI covers 80–90% of system requirements but says the remaining gaps can be significant. Another commenter reports building a tool that synced three departments’ differently used inventory system while a six-figure ERP migration was delayed.
- Lower build costs do not remove ongoing product and engineering work: commenters point to alignment, stakeholder and technical decisions, bug fixes, feature requests, and scaling as continuing costs. They also caution that custom tools can be hard to maintain, while SaaS may remain attractive for outsourced updates and hard-to-recreate domain expertise.
An emerging zero-to-one playbook for PMs at big companies: the PM and designer vibe-code a working alpha; once it shows pull, they bring in engineers; then the PM steps back from coding to align, prioritize, and unblock.
- For this 63-variant clothing launch, the seller plans to start on Shopify and is still deciding about Amazon. Commenters recommend checking the actual retailer, marketplace, or 3PL requirements before buying GS1 codes; their general guidance is that internal SKUs may suffice for an own-site store, while some retailers and marketplaces require globally recognized identifiers.
- One commenter says Shopify lets sellers add barcodes to variants later, including by bulk CSV, so the seller could start with internal SKUs and switch when needed; the commenter cautions they are not in retail and advises checking Amazon’s requirements.
- Barcode placement is also a product-experience consideration: plan labels and packaging so a sales channel’s barcode needs do not undermine unboxing or make returns harder.
An early-stage founder said they focused on completing a neat end-to-end build, expected distribution to follow, and had no GTM strategy beyond cold-email outreach pitching the product . Commenters recommended reversing that sequence: choose a narrow prospect group, talk with them about their problem, and try delivering an initial paid result manually; use what customers will pay for and what the work reveals to decide what to automate next . One commenter suggested finding 20 tightly targeted prospects, using permission-based outreach, manually over-delivering to the first 4–5 clients, and then testing whether they would pay for ongoing service .
PMs need both product craft and domain depth: strong execution and a polished launch do not ensure success unless the product wins on the industry's actual scoreboard—such as margins, unit economics, regulation, or market share—and delivers a viable business outcome. Domain depth means sustained knowledge of a few important problems and where they break, not merely an industry label; some knowledge must be rewired across companies, regulations, cultures, and geographies. Craft helps structure discovery, while domain knowledge reveals which problems are commodities to standardize and which remain open for differentiation; the author recommends using research, customer conversations, product data, and frontline teams to build that depth, then focusing on fewer problems. AI can speed common-knowledge learning, brainstorming, and prototyping, but does not replace practiced problem solving or judgment on tough trade-offs; use the time saved to go deeper on fewer problems.
- Product managers should understand the company’s P&L, balance sheet and, where relevant, cash flow, and judge potential impact against the business’s scale . Ask finance or a business-unit lead which metrics and revenue levers matter, then connect roadmap choices to financial drivers, strategy and customer needs rather than prioritizing on financial estimates alone .
- For AI features, track usage-linked costs by user, workflow and interaction, and develop a credible return hypothesis—such as earlier revenue or cost savings, or customers paying for the feature—because added usage can raise costs without improving revenue or savings .
- AI product work also requires planning for non-deterministic behavior and reliability, safety and security risks, including prompt injection; use evaluations and prepare rollback or kill-switch options . Unexpected or harmful behavior can undermine trust, prompt cancellations and damage revenue .
San Theft Auto launched as an open-source, multiplayer racing game set in San Francisco; its creator says GPT 6 mapped the city in Blender using 950M tokens. Hiten Shah called it especially fun for people familiar with San Francisco, including driving around as Jensen Huang.
- As discovery and purchasing move to agents, a minimum viable company must be understandable to software well enough for agents to identify when it is relevant and complete transactions; founders should design for this from the start.
- A linked argument predicts that consumer agents could make improving product quality a more effective competitive strategy and increase the importance of product-quality information; whether agents concentrate demand on a few products or disperse it around individual preferences remains an open question.
Andrew Chen reports riding Waymo’s new Ojai vehicle in San Francisco and gives it a strongly positive, brief user reaction: “it’s so nice.”
For college-football scoreboards, put the possession indicator beside the team name as a football or other icon, rather than beside the score; the current indicator is hard to see and its placement by the score is confusing.
- The thread highlights a tension between PM decision authority and earned credibility: one commenter says PMs typically hold final product decision power, while the original poster argues a seat at the table should come from competence, domain expertise, and doing what it takes to deliver value—not title alone.
- A practical model is to stay accountable without making every decision unilaterally: understand customer problems, markets, buyers, and users, then share decisions using the team’s expertise. One commenter adds that high-level vision setting belongs to executive business alignment, with Product as an input.
- For a consulting offer, sell a measurable customer outcome rather than general expertise: one suggestion was a paid call audit to identify where leads are lost, followed by a 10-call teardown that scores lost calls, addresses recurring failures, and uses before/after close rates to shape the next engagement.
- Anchor the payoff in the customer’s own economics instead of assumed deal values; a proposed revenue-share model also calls for setting a baseline close rate, though the founder raised a concern that closed deals could be hard to verify and numbers manipulated.
- Sachin Rekhi’s AI workflow update treats agentic platforms as a category: he says ChatGPT Codex is now as powerful as Claude Code, with Cursor, Grok Bot, Google Antigravity, and GitHub Copilot also pursuing similar capabilities. He now favors storing company context in a shared document repository with a robust MCP server over local markdown files, and generating richer HTML reports and dashboards instead of defaulting to markdown.
- For team use, he emphasizes teaching people to apply their own judgment to AI output and remain accountable amid AI slop, and designing workflows so output quality compounds with each use. For AI analysis, he says golden examples and a semantic layer can support accuracy users can trust.
- For product design and delivery, he recommends reimplementing design systems in code and documenting them in Storybook to improve consistency and help engineering turn prototypes into production code. He favors using the agentic platforms teams already use for prototyping and complex, cross-source workflow automation rather than separate tools such as Bolt, Replit, Lovable, Relay, or Gumloop.
A startup cofounder reported that responsibilities kept expanding despite adding teams, while role boundaries were not respected . A reply framed this as an organizational-design problem: adjust incentives, communication boundaries and channels, and ownership structures; project management can help shift culture, but organizational design is what matters and may take several iterations .
- Validate demand before building: conduct customer discovery to test whether enough customers will pay enough; launching without knowing who will buy can make distribution appear to be the problem when demand was never established.
- Deliver manually to early customers before building scalable software or automating: manually serving the first 15 can reveal edge cases and communication breakdowns, while systems scale workflows that already work predictably by hand.
- Prioritize selectively: require a clear reason for each feature, channel, or hire before taking it on, to avoid adding more to maintain.
A Product Design post links to an article framing structural adhesives as an obstacle to circular product design.
Hiten Shah argues that most consumer and enterprise software will eventually be completely rewritten, with the resulting products feeling very different from today’s software.
Domain vs Product Craft: Which One Wins?

Every Product Manager has heard both sides of this.
Domain people say “you can’t build products in this industry if you don’t know the industry.”
Craft people say “a good PM can learn any domain.”
Both are half right.
Today we cover:
Why I lean towards domain (and where I see it hurt)
Domain is depth, not an industry label
The craft-first trap
A learning from my own world, payments
My verdict
A short word on AI
From our sponsor: Jimo Agent walks new users through your product, on the screen in front of them.
👉 A user types what they’re trying to do, and Jimo builds a step-by-step guide fitted to that screen. It can also answer from your docs, or do the thing for them. Nothing has to be rewritten when a screen changes, and Jimo customers onboard new users in half the time.

My honest starting point
Domain matters a lot. If you don’t know the problem space and the solution space, you spend your time catching up before creativity can even kick in. You are stuck understanding, not creating.
I see this show up in two places, in any industry.
1. Business success is defined by the domain-related outcomes, not by the Product Craft Outcomes.
A PM can follow every craft step (documentation, structures, backlog management, PRD writing, Great acceptance criterias and more) and still not win (by which I mean success as defined by that industry itself).
Every industry has its own scoreboard: margins, unit economics, regulation, market share. You can launch a product beautifully, but if the P&L doesn’t work or you can’t compete in that industry on its terms, the launch was a success only on paper.
A launch means the team shipped after a lot of effort (hence often the blood ,sweat and tears feel like success when that product is finally out). Winning means it also makes sense in the real world: positioning against competitors, user preference, ease of conversion, and a business goal you actually reach.
Solve the customer problem yes, but do not stop there. All solved customer problems don’t always lead to successful business outcomes.
2. The core of the product is often not just the user experience
PMs without domain knowledge are usually strong on front end and user experience. They design a perfect journey and win the argument for it. But they are weaker on platform, core and infrastructure topics, and many dependencies live exactly there.
So feasibility becomes “whatever my engineers tell me.” Can it scale? Can we build more experiences on top of it? How much product debt is there? Do incremental features keep getting slower? These questions come from domain knowledge, and a UX-first PM often does not know to ask them.
Domain is not an industry label. It is depth.
Saying “I work in healthcare” or “I am a logistics person” does not mean much. Staying with few very important problems in your domain long enough that you know exactly where it breaks, that is domain knowledge. If you keep jumping from one problem to another, knowledge stays surface level and creativity never kicks in.
Also, domain is more local than people admit. The same industry looks different across companies, regulations, cultures and geographies. Every time you move, part of your knowledge needs rewiring.
An example from my world: payments
I work in payments, so let me quote some of my own learnings. Your industry will have its own version.
In payments there is a universal layer: pay-ins on time, pay-outs on time, the basics of payments infrastructure, and a lot of finance and accounting underneath. That travels with you everywhere. Then local layers sit on top:
→ A cash-heavy market with room to digitise vs an already digitised one
→ A credit-hungry culture vs a credit-cautious one
I learnt this the hard way. Every time I changed companies or geographies, I assumed I knew the domain. Same domain, different regulation, customers, partners and culture.
And here is the contrast I care about most. A craft PM can make pay-ins and pay-outs meet the industry standard. A domain-knowledgable PM makes them better than everyone in the industry. Swap payments for your own domain and the pattern holds: shallow knowledge gets you to standard, depth gets you past it.
The craft-first trap
Now the other side, and I will be fair to it.
Generalists also have a role to play. They find patterns in how domain experts work and bring structure to it. This frustrates domain experts, who just want to get things done. And craft people can apply too much craft, while domain experts worry too little about it. Both sides need to come closer.
But here is what I see when a craft-first PM lands in a domain they skipped. They go back to fundamentals. Start discovery, study the market, list customer types. All good practice. Except the problem in front of them is often a commodity problem that many others in the industry have already solved.
Knowing WHICH problems are commodity and which are still open is itself domain knowledge. It tells you where to copy the standard and where to be original. That saves months.
In my experience and observation, craft people who skip domain struggle more than domain people who skip the perfect craft.
My verdict: they feed each other
You can enter from either side:
→ Start with domain, and gain product craft along the way
→ Start with craft, and gain domain through product discovery
When I join a new company, my routine is mostly craft used to earn domain: study the market, talk to customers, study product data and behaviour, talk to sales and key account managers, go to conferences, and subscribe to newsletters from that region (my favourite hack). Craft is how I earn domain. Domain is what makes the craft pay off.
The real risk is stopping at one. And whichever you choose, go deep on a small set of problems instead of staying broad across many.
And what about AI?
Briefly…
AI is very good at common knowledge, simplifying, brainstorming and helping you learn a new domain faster. It helps you formulate your thoughts, check your biases and build prototypes quickly. PM work is mostly information in, action out, and I now spend less time reading and writing without losing quality.
But AI does not make you a better problem solver or product craftsperson, because that comes from practice in real life. And it is only as good as what you feed it. It stops helping at the edge of what it knows, and at tough trade-offs where you need creativity, not a summary.
So AI makes breadth cheap. Depth is where your own creativity comes in.
If you are worried about your PM career, here is my weekend advice: go through each workflow, make it AI-enabled, check what others are doing, and try some workflows in an entirely new way. Then spend the time you save going deeper on fewer problems.
Over to you
Where are you today?
A) Domain first, still building craft
B) Craft first, still building domain
C) Both, and they feed each other
Tell me in the comments
Thanks for reading Productify by Bandan! This post is public so feel free to share it.
PMs need both product craft and domain depth: strong execution and a polished launch do not ensure success unless the product wins on the industry's actual scoreboard—such as margins, unit economics, regulation, or market share—and delivers a viable business outcome. Domain depth means sustained knowledge of a few important problems and where they break, not merely an industry label; some knowledge must be rewired across companies, regulations, cultures, and geographies. Craft helps structure discovery, while domain knowledge reveals which problems are commodities to standardize and which remain open for differentiation; the author recommends using research, customer conversations, product data, and frontline teams to build that depth, then focusing on fewer problems. AI can speed common-knowledge learning, brainstorming, and prototyping, but does not replace practiced problem solving or judgment on tough trade-offs; use the time saved to go deeper on fewer problems.