Explore the ideas
The ideas on this site often connect across several notes, professional experience and readings. Explore lets you follow a recurring question, read a series in sequence, or browse individual pieces by topic.
Questions connect ideas across the site. Series develop one line of thinking over time. Topics give you the broadest view.
Three paths through the ideas.
Each path brings together notes, relevant professional experience and external ideas that sharpen or challenge the question.
- How do teams make better decisions? How information, trade-offs and timing shape product decisions when several directions look reasonable. Start hereMost product disagreements come from missing information
- How do people build shared understanding? How teams interpret context, surface disagreement and work across Product & Engineering boundaries. Start hereShared context is not shared understanding
- What changes when AI becomes part of the work? What AI changes about contribution, ownership and system design when it becomes part of everyday work. Start hereAI accelerates contribution, not mastery
Two series to read in sequence.
Questions connect different parts of the site around a problem. Series are narrower and sequential: each one follows a line of thinking across notes intended to be read together.
-
Product Judgment in Practice
Evidence, trade-offs, urgency, timing and disagreement before implementation begins.
Product decisions Teams and collaboration -
Building My Own AI Operating System
A first-person series about moving from one general assistant to smaller AI-first services with explicit jobs, boundaries and ownership.
AI and automation Software systems
All notes and readings by topic.
Topics classify every note and reading. Use them when you want breadth rather than a guided path.
Product decisions
How teams frame trade-offs, priorities and commitments when no option is complete.
8 notes 6 readings
Notes in this topic
- I built March to plan with AI without becoming a content machine I wanted a view of the publishing runway without turning empty space into pressure. March keeps the plan visible so AI can help question it while the editorial decisions remain mine. AI and automation Product decisions
- The transition to Product Management starts before the title changes The transition into Product Management often begins before the role changes, when attention shifts from implementation alone to problems, trade-offs, communication, and product judgment. Product decisions Teams and collaboration
- Temporary solutions become permanent Temporary solutions are often necessary, but once adopted they become part of the product and can quietly turn into long-term constraints. Software systems Product decisions
- The urgency of customer requests Not everything that feels urgent is a real priority. In product work, reacting before urgency is understood can lead teams to the wrong decisions. Product decisions
- Product decisions are mostly trade-offs Product discussions often look like debates about the right solution. In reality they are usually debates about which trade-off a team is willing to accept. Product decisions
- Most product disagreements come from missing information Product discussions often look like disagreements of opinion. In reality, teams are often missing the same piece of information. Product decisions Teams and collaboration
- Waiting is one of the most underrated product decisions Product teams are often rewarded for shipping new things. But building something is not always progress. Sometimes the smartest decision is simply to wait. Product decisions
- The real job of a Product Manager is managing disagreements Much of product work is about helping smart people who see the problem differently find a way forward. Teams and collaboration Product decisions
Reading around the topic
-
This Is How Successful People Make Such Smart Decisions (opens in new tab)
Introduces the idea of having strong opinions, weakly held. While the principle encourages flexibility, in practice many disagreements are not caused by strong opinions but by incomplete context. What appears as healthy debate is often people optimizing for different realities.
-
Blurring boundaries: Toward the collective empathic understanding of product requirements (opens in new tab)
Based on a study of 18 cross-functional teams, the paper shows how product understanding improves when knowledge and participation cross role boundaries. Product & Engineering do not need to own the same work, but they do need enough shared understanding to interpret requirements, question assumptions, and plan together.
-
Boundaries Between Product & Engineering (opens in new tab)
Draws a useful boundary between shared product responsibility and absorbing another discipline's work. Better collaboration does not make Product accountable for bugs, technical debt, or architecture; it requires clearer ownership and more direct paths for information and escalation.
-
The AI Great Leap Forward (opens in new tab)
Many organizations are pushing for rapid AI adoption, often prioritizing visible progress over actual value. This leads to systems that look functional but lack validation, reliability, and long-term maintainability.
-
The Product-Minded Engineer (opens in new tab)
Argues that engineers should engage with product decisions, not just implementation. Decisions improve when context is shared across roles instead of being handed off. Highlights how Product & Engineering collaboration leads to better trade-offs and outcomes.
-
Using Platform Engineering to simplify the developer experience — part one (opens in new tab)
John Lewis treats its paved road as a compelling default rather than a mandatory route. The part I find most useful is what happens outside it: repeated exceptions become product-discovery evidence, while one-off needs can remain explicit and locally owned. This is a vendor-hosted operator account, so I read the mechanism as a case to think with rather than a universal rule.
AI and automation
How AI changes contribution, automation and product capability without removing judgment or system constraints.
12 notes 12 readings
Notes in this topic
- Adding MCP doesn't make a product agent-first Adding MCP to an existing API can create enormous value by making an established product accessible to agents. Designing a product with agents as first-class users is a different problem. AI and automation Software systems
- Better output makes shallow review more dangerous AI can make work look ready before its reasoning deserves trust. Review depth should follow the consequences of the decision, not the polish of the output. AI and automation Teams and collaboration
- I need my AI dashboard to leave things out A useful AI dashboard should reduce the first pass over the work, not reproduce every open item. Its omissions, priorities, and explanations all need to remain inspectable. AI and automation Software systems
- Friday connects the services without owning their work A coordinating layer can compare state, explain disagreement, and direct attention without becoming the source of truth for the services it connects. AI and automation Software systems
- Designing for unattended development Unattended development is not the same as leaving an agent alone. It requires explicit eligibility, isolation, verification, stop conditions, and a separate decision about what may enter the stable codebase. AI and automation Software systems
- Why I started building Friday Friday is my second attempt at the original Jarvis ambition. It began when August and March created a concrete coordination problem between them. AI and automation Software systems
- I built March to plan with AI without becoming a content machine I wanted a view of the publishing runway without turning empty space into pressure. March keeps the plan visible so AI can help question it while the editorial decisions remain mine. AI and automation Product decisions
- I built August because copy and paste was not collaboration AI could help with a document, but the work around each answer kept falling apart. I built August to keep the draft, its review state and my decisions in one place. AI and automation Teams and collaboration
- I stopped trying to build Jarvis I started with a general AI assistant and no recurring job for it. The useful parts appeared only after I built smaller services around work I was already doing. AI and automation Software systems
- Shared context is not shared understanding AI makes context easier to retrieve, but access to the same information does not automatically create shared understanding, alignment, or better decisions. Teams and collaboration AI and automation
- AI accelerates contribution, not mastery AI makes it possible to contribute much earlier in a new environment. But contributing faster is not the same as deeply understanding the system. AI and automation Teams and collaboration
- When should Machine Learning be used? Machine Learning should only be used when there is enough meaningful data available. Without the right data, a rule engine is often the smarter choice. AI and automation Software systems
Reading around the topic
-
AI Coding Is Not the Same as Software Engineering - And It Matters (opens in new tab)
Generating code quickly is not the same as building systems that can evolve, scale, and be maintained over time. As AI accelerates implementation, the long-term complexity and quality of software increasingly depend on architecture, trade-offs, and engineering discipline rather than raw output speed.
-
CPU work and GPU work (opens in new tab)
Introduces a useful distinction between work that can tolerate probabilistic exploration and work that still needs guarantees, validation, and deterministic controls. The useful idea is not the metaphor itself, but the operational reminder that the shape of the work should determine the shape of the process.
-
Coding Is No Longer the Constraint: Scaling Developer Experience to Teams and Agents at Spotify (opens in new tab)
Shows how AI leverage compounds earlier investments in developer platforms, standardization, ownership data, and automated feedback loops. As implementation gets faster, the limiting work moves toward review, prioritization, and the human judgment needed to decide what should change.
-
Context Engineering: A Practical Guide for AI Agents (2026) (opens in new tab)
Shows why useful context for AI agents is not just retrieved information, but structure across code, history, systems, and decisions. It gives a concrete software-systems example of why better access to information still does not remove ambiguity, hidden dependencies, or the need for interpretation.
-
Even with AI, cognitive digital twins retrieve information more than they actually understand work (opens in new tab)
Draws a useful boundary between retrieving explicit traces of work and actually understanding how work happens under real constraints. It reinforces the idea that better access to context does not automatically create shared understanding, especially when tacit knowledge, judgment, and interpretation are still required.
-
How I Escaped AI Autopilot (opens in new tab)
A strong articulation of how fluent AI output can make passive review feel like real understanding. It extends the distinction between contribution and mastery by showing how attention, ownership, and verification become more important when output already looks polished and plausible.
-
How we really build production-grade AI agents: beyond models, toward data and API quality (opens in new tab)
Argues that production agent reliability depends on the data, APIs, and controls around the model, not only on model capability. Its most useful lens is to treat APIs as policy surfaces: contracts that bound actions, expose evidence, and make validation, observability, and human approval explicit.
-
Programming in 2026: excitement, dread, and the coming transformation (opens in new tab)
The article explores the growing tension between the speed of AI-assisted software creation and the long-term complexity of maintaining real systems. It questions whether rapid AI-generated output is actually improving software engineering, or simply accelerating the accumulation of fragile and difficult-to-evolve systems.
-
Revisiting "No Silver Bullets" in the age of AI (opens in new tab)
A modern revisit of Fred Brooks' No Silver Bullet in the context of AI-assisted software development. The article explores whether AI meaningfully changes software engineering productivity, or whether the essential complexity of software systems still dominates. What stands out is the distinction between accelerating implementation work and reducing the deeper organizational, contextual and decision-making complexity involved in building software systems.
-
The AI Great Leap Forward (opens in new tab)
Many organizations are pushing for rapid AI adoption, often prioritizing visible progress over actual value. This leads to systems that look functional but lack validation, reliability, and long-term maintainability.
-
The broken ladder: AI, remote work, and early-career hiring (opens in new tab)
The paper challenges an easy explanation for declining junior hiring. Across 243 million new hires and 407 million job postings, the association with working from home remains robust when estimated alongside GenAI exposure, while the apparent GenAI effect weakens. It complicates my interest in remote work as career access: widening where experienced people can work may coexist with weaker entry routes. This is a discussion paper covering four anglophone labour markets, not a final verdict on remote work.
-
Thoughts on slowing the fuck down (opens in new tab)
Coding agents make it possible to build much faster, but they also remove the natural constraints that used to limit mistakes. Small issues that would normally be manageable can quickly compound into systems that are difficult to understand, maintain, or trust.
Software systems
How architecture, platforms and temporary choices shape what products can become.
9 notes 9 readings
Notes in this topic
- Adding MCP doesn't make a product agent-first Adding MCP to an existing API can create enormous value by making an established product accessible to agents. Designing a product with agents as first-class users is a different problem. AI and automation Software systems
- Stop asking people for information the system already has Much process work moves facts between tools. Useful automation connects what is already recorded while keeping system interpretations separate from source truth and human judgment. Software systems
- I need my AI dashboard to leave things out A useful AI dashboard should reduce the first pass over the work, not reproduce every open item. Its omissions, priorities, and explanations all need to remain inspectable. AI and automation Software systems
- Friday connects the services without owning their work A coordinating layer can compare state, explain disagreement, and direct attention without becoming the source of truth for the services it connects. AI and automation Software systems
- Designing for unattended development Unattended development is not the same as leaving an agent alone. It requires explicit eligibility, isolation, verification, stop conditions, and a separate decision about what may enter the stable codebase. AI and automation Software systems
- Why I started building Friday Friday is my second attempt at the original Jarvis ambition. It began when August and March created a concrete coordination problem between them. AI and automation Software systems
- I stopped trying to build Jarvis I started with a general AI assistant and no recurring job for it. The useful parts appeared only after I built smaller services around work I was already doing. AI and automation Software systems
- Temporary solutions become permanent Temporary solutions are often necessary, but once adopted they become part of the product and can quietly turn into long-term constraints. Software systems Product decisions
- When should Machine Learning be used? Machine Learning should only be used when there is enough meaningful data available. Without the right data, a rule engine is often the smarter choice. AI and automation Software systems
Reading around the topic
-
AI Coding Is Not the Same as Software Engineering - And It Matters (opens in new tab)
Generating code quickly is not the same as building systems that can evolve, scale, and be maintained over time. As AI accelerates implementation, the long-term complexity and quality of software increasingly depend on architecture, trade-offs, and engineering discipline rather than raw output speed.
-
CPU work and GPU work (opens in new tab)
Introduces a useful distinction between work that can tolerate probabilistic exploration and work that still needs guarantees, validation, and deterministic controls. The useful idea is not the metaphor itself, but the operational reminder that the shape of the work should determine the shape of the process.
-
Coding Is No Longer the Constraint: Scaling Developer Experience to Teams and Agents at Spotify (opens in new tab)
Shows how AI leverage compounds earlier investments in developer platforms, standardization, ownership data, and automated feedback loops. As implementation gets faster, the limiting work moves toward review, prioritization, and the human judgment needed to decide what should change.
-
Context Engineering: A Practical Guide for AI Agents (2026) (opens in new tab)
Shows why useful context for AI agents is not just retrieved information, but structure across code, history, systems, and decisions. It gives a concrete software-systems example of why better access to information still does not remove ambiguity, hidden dependencies, or the need for interpretation.
-
How we really build production-grade AI agents: beyond models, toward data and API quality (opens in new tab)
Argues that production agent reliability depends on the data, APIs, and controls around the model, not only on model capability. Its most useful lens is to treat APIs as policy surfaces: contracts that bound actions, expose evidence, and make validation, observability, and human approval explicit.
-
Programming in 2026: excitement, dread, and the coming transformation (opens in new tab)
The article explores the growing tension between the speed of AI-assisted software creation and the long-term complexity of maintaining real systems. It questions whether rapid AI-generated output is actually improving software engineering, or simply accelerating the accumulation of fragile and difficult-to-evolve systems.
-
Revisiting "No Silver Bullets" in the age of AI (opens in new tab)
A modern revisit of Fred Brooks' No Silver Bullet in the context of AI-assisted software development. The article explores whether AI meaningfully changes software engineering productivity, or whether the essential complexity of software systems still dominates. What stands out is the distinction between accelerating implementation work and reducing the deeper organizational, contextual and decision-making complexity involved in building software systems.
-
Thoughts on slowing the fuck down (opens in new tab)
Coding agents make it possible to build much faster, but they also remove the natural constraints that used to limit mistakes. Small issues that would normally be manageable can quickly compound into systems that are difficult to understand, maintain, or trust.
-
Using Platform Engineering to simplify the developer experience — part one (opens in new tab)
John Lewis treats its paved road as a compelling default rather than a mandatory route. The part I find most useful is what happens outside it: repeated exceptions become product-discovery evidence, while one-off needs can remain explicit and locally owned. This is a vendor-hosted operator account, so I read the mechanism as a case to think with rather than a universal rule.
Teams and collaboration
How context, disagreement and collaboration affect decisions across Product & Engineering.
7 notes 6 readings
Notes in this topic
- Better output makes shallow review more dangerous AI can make work look ready before its reasoning deserves trust. Review depth should follow the consequences of the decision, not the polish of the output. AI and automation Teams and collaboration
- I built August because copy and paste was not collaboration AI could help with a document, but the work around each answer kept falling apart. I built August to keep the draft, its review state and my decisions in one place. AI and automation Teams and collaboration
- The transition to Product Management starts before the title changes The transition into Product Management often begins before the role changes, when attention shifts from implementation alone to problems, trade-offs, communication, and product judgment. Product decisions Teams and collaboration
- Shared context is not shared understanding AI makes context easier to retrieve, but access to the same information does not automatically create shared understanding, alignment, or better decisions. Teams and collaboration AI and automation
- AI accelerates contribution, not mastery AI makes it possible to contribute much earlier in a new environment. But contributing faster is not the same as deeply understanding the system. AI and automation Teams and collaboration
- Most product disagreements come from missing information Product discussions often look like disagreements of opinion. In reality, teams are often missing the same piece of information. Product decisions Teams and collaboration
- The real job of a Product Manager is managing disagreements Much of product work is about helping smart people who see the problem differently find a way forward. Teams and collaboration Product decisions
Reading around the topic
-
Common software project conflicts and how to navigate them (opens in new tab)
A breakdown of common sources of conflict in software projects, from priorities to ownership and expectations. What stands out is that many of these aren't real disagreements, but people making decisions with different context. Several conflict types described here feel like symptoms of the same underlying issue: unevenly distributed information.
-
Blurring boundaries: Toward the collective empathic understanding of product requirements (opens in new tab)
Based on a study of 18 cross-functional teams, the paper shows how product understanding improves when knowledge and participation cross role boundaries. Product & Engineering do not need to own the same work, but they do need enough shared understanding to interpret requirements, question assumptions, and plan together.
-
Boundaries Between Product & Engineering (opens in new tab)
Draws a useful boundary between shared product responsibility and absorbing another discipline's work. Better collaboration does not make Product accountable for bugs, technical debt, or architecture; it requires clearer ownership and more direct paths for information and escalation.
-
Even with AI, cognitive digital twins retrieve information more than they actually understand work (opens in new tab)
Draws a useful boundary between retrieving explicit traces of work and actually understanding how work happens under real constraints. It reinforces the idea that better access to context does not automatically create shared understanding, especially when tacit knowledge, judgment, and interpretation are still required.
-
The Product-Minded Engineer (opens in new tab)
Argues that engineers should engage with product decisions, not just implementation. Decisions improve when context is shared across roles instead of being handed off. Highlights how Product & Engineering collaboration leads to better trade-offs and outcomes.
-
The broken ladder: AI, remote work, and early-career hiring (opens in new tab)
The paper challenges an easy explanation for declining junior hiring. Across 243 million new hires and 407 million job postings, the association with working from home remains robust when estimated alongside GenAI exposure, while the apparent GenAI effect weakens. It complicates my interest in remote work as career access: widening where experienced people can work may coexist with weaker entry routes. This is a discussion paper covering four anglophone labour markets, not a final verdict on remote work.