I recently listened to Ezra Klein’s interview of Brian Eno from 2025 (link), which was just re-uploaded to Klein’s podcast feed.

The overall interview is delightful. One of the things Eno mentioned was the importance of having a “practice” as a musician or artist, something he learned from the work of John Cage.

It got me to thinking: do I engage in a practice in a way that supports my work? If I am honest, it hasn’t been the case throughout a lot of my career. Reading, discussing, and using other products can support a PM’s work, but to me, only doing that outside of work doesn’t constitute a practice because these are passive activities.

I’ve always dabbled in side projects, but that didn’t feel much like product work. Because of my limited coding ability, that always felt more like learning to code and building technical knowledge. I couldn’t do enough on my own to where it feel like I was exercising my product muscle.

Recently, however, it’s felt different thanks to AI. For the past several weeks, I’ve been able to launch full projects in the scope of a weekend, which I would have taken months to do before. The speed and scope are amazing in themselves, but what feels special now is that it feels a lot more like doing product work in my day job. I’m spending less time wrestling with getting code and services working, and spending more time thinking about what I want to build and how it should work.

And so finally, I do feel like now I can truly have a product practice in a way that an artist can have a practice that goes throughout their life. It’s still early of course for this, but it’s incredibly exciting.

What changed?

What’s changed recently to allow this? Of course, the models have gotten better. With Fable, Opus 5, and the other equivalents out there, things just get done. The limitation is much more now your ability to articulate what you want. Isn’t that most of the battle with product management?

But it’s not just the models. I think it’s also that the services and infrastructure around the models has gotten better now so that they can do complete product development tasks on their own, including deployment and release.

In my case, I’ve been making heavy use of the Cloudflare CLI, which is incredible because it enables an agent to basically do everything in Cloudflare on its own. And there isn’t much in terms of web products that you can’t do on Cloudflare.

Even 6 months ago, while the models had their incredible inflection point around Opus 4.7, to me it still was about driving better code.

But, now, it’s at the point where I feel like I can just work with models to do things as I normally would with a developer and a designer. In a weekend project, I can do product work: set priorities, make decisions, and critique work in progress. In my day job and if I look back throughout my career, how many product decisions and moments like this do I have during a week? Not too many. But with a product practice in off hours, I can double or quadruple the number of decisions I can choose to make in a week. I hope it helps make me sharper in my day job, but it’s also gratifying for personal projects in a way that was so hard before.

It's really terrible to see executives right now laying people off "because AI". Yes, an employee can do a lot more than they once could, but I'm guessing that a lot of these companies aren't really thinking about the systemic and long-term changes they'd need to make this work out well.

It seems to me that AI is creating a new kind of leverage - a leveraging of human capital. And, like precursors to other financial catastrophes in the past, a lot of companies are thoughtlessly over-leveraging their people with AI right now.

So, I'd like to make a prediction: within the next 2 years, a major company (public or otherwise) is going to have a significant, multi-day outage. They may not say it publicly, but it will be due to a dramatic increase in size and complexity of systems (juiced by AI), and not having the people to actually figure out and fix what's broken, when it does.

This book acts as both a guide for improving small talk as a skill, and also an argument for why small talk is important in life. I thought it was helpful on both fronts.

Fleming is very knowledgeable on the subject of speech and communication, but the book is written in a very accessible way that isn't academic at all. She makes the case that small talk is the most important communication skill and not just a necessary evil to tolerate. So many of our current societal ills are directly related to the lack of connection people feel with those around them. Small talk is one answer to changing that.

A really useful book—one of those that I wish I had read 20 years ago.

A nice little book. It's primarily an argument in favor of gift economies instead of the traditional monetary-based economies that we rely on. I think the case is fairly convincing on the small scale. It made me want to share more with my neighbors, with the people I'm connected with professional, and on online communities in general. I was less convinced by her case for gift economies to be used as a part of the broader economy, which is something I felt was tacked on at the end and not thoroughly developed

I enjoy learning about different ways to view concepts that we tend to take for granted, like how Born to Run opened my eyes to a different way of approaching running. These always tend to come back to indigenous knowledge.

A quick read, and I thought it was worth it as essay to make you think.

Today, the team who makes Zed announced a new speaker series about agentic engineering. In reading their motivation for it, I really appreciate the thoughtful way in which they're approaching working with AI:

Software development is changing and we find ourselves at a convergence. Between the extremes of technological zealotry ("all code will be AI-generated") and dismissive skepticism ("AI-generated code is garbage") lies a more practical and nuanced approach—one that is ours to discover together.

As I'm trying to figure out how to navigate the changing world of work, so much of the content out there tends towards the maximalist end of the spectrum. People are playing on this weird cocktail of excitement, worry, and uncertainty to promote themselves. In the background is the combination of widespread tech layoffs and unemployment with the gold rush mentality of VCs, entrepreneurs, and companies trying to ride the AI wave.

What I appreciate about how the Zed team talks about AI (see this great Changelog interview with Nathan Sobo), is that they have the courage to walk a middle path between the hype and skepticism. Work is changing, for sure. But you don't have to buy in to the predominant narratives on social media and surrender to FOMO in charting a path through it all.

In some of the recent projects I've been working on, I've been using the fantastic OpenRouter, which makes it trivially easy to test and compare the output of different LLMs. It's an interesting experience, because it's easy to see the differences in quality, speed, and cost between each model. It puts me in the mindset of "what's the cheapest model that gets the job done?"

As I was cycling through the different models, a dark future of employment dawned upon me. What if we humans are just considered another "model" to route a request to, whose output will be compared against all of these other models? People will send a request to cheaper models like Claude Haiku, to more expensive models like Sonnet and Opus, and then to the most expensive models of all, humans, which might cost 100x, 1000x, or 10000x for a given request.

If you do all of your work through a computer today, this is already something that is 100% technically feasible.

The biggest shift here is going from binary thinking to gradient thinking. A lot of people tend to solipsistically think of the AI replacement question as a binary yes/no. Can an AI do my job or not? With that lens, the answer is usually "no" (at least from their own perspective).

But this is not how those paying for jobs (micro-jobs like a single LLM, but also macro-jobs like a normal salaried position) will think. They'll think of it like a gradient. Can an AI do this job? The answer is yes already. It can take the inputs and give the same kind of outputs that a human would.

The only question is, how good of a job can it do? And at what price?

When you start to think that way, things get a lot scarier.

One thing that's jumped out to me as I use more and more AI tools, especially for coding: using pen and paper is even more important now that it was before.

It's always been important to work out things on paper. The Feynman anecdote on written notes comes to mind:

Weiner: Well, the work was done in your head but the record of it is still here.
Feynman: No, it’s not a record, not really, it’s working. You have to work on paper and this is the paper. OK? (source)

Initially, using an LLM as a sounding board to work things out is tempting, and feels like an easy way to start. But I find that it's essential to work the basics of what I want out for myself first before going to the LLM. Without some clarity in my mind, it's easy to be led into a local maxima, even when it's just me and the LLM in the room.

So now I find myself drawn to pen and paper even more than before. Work it out for yourself, then go to the AI.

After Anthropic recently added modest Claude Code capability to their Pro plan, I've been testing it out. I'm still undecided on whether I like it better than Cursor or not.

I did run into one annoying thing, however, in the setup. It wasn't very straightforward to set up MCP integration with Linear. This is important to me because it's become a surprisingly important part of my workflow to just ask the LLM to see tickets. For some reason, the documentation on Linear's side, on Anthropic's side, and within Claude itself weren't very helpful in figuring it out.

Trying to add Linear MCP using the normal syntax and the SSE syntax didn't work. The approach of adding it to Claude desktop and importing it into Claude Code didn't work iether.

What did work, however, was using the JSON syntax. So, without further ado, here is how you add the Linear MCP server to Claude Code in a way that will connect correctly (as of June 2025):

claude mcp add-json linear '{"command": "npx", "args": ["-y","mcp-remote","https://mcp.linear.app/sse"]}'

Notepads is a relatively new feature that got introduced in the recent Cursor 0.41 (September 2024). When I first read about the feature, I got pretty excited. Specifying context is arguably the most important part of using Cursor effectively.

I've always felt it cumbersome to have to manually @mention the whole list of files needed to work in a particular area of my project. It's slow and it's prone to error—sometimes I just forget to mentino a file or two and it throws everything off.

The promise of Notepads is that you can pre-specify a context (like multiple files along with extra instructions) and then just @mention the notepad going forward instead. For example, if I'm working in my Rails app, I can create a Notepad for all of the relevant controller, model, views, and javascript files as a shortcut for working in an area.

I'm still playing with the feature, but I'm hopeful that it will be a big unlock in effeciency for my workflow.

The main problem I found is that, for some reason, it's a huge pain in the ass to figure out how to use Notepads. As of this writing, I couldn't find anything in the Cursor docs, the Cursor subreddit, or a cursory Google search on how to do it.

So here's how to use Notepads, at least as of Cursor 0.42:

1. Open Composer (Cmd+I)
2. Click the "Open control panel" icon in the top left of the Composer window (looks like a dial)
3. In the left sidebar of the Composer control panel, see the "Notepad" section.
4. Press (+) to create a new Notepad
5. Type whatever context you want into the Notepad, including @mention for files
6. Exit out of the control panel
7. Now, you should be able to @mention the notepad you just created in places like the chat sidebar

Enjoy!

The more I build with AI tools, the less and less I ask them to do. When I started using Cursor, I had gotten caught up in the demo hype. I asked it to build big, complex features in my product. Features I didn't define very clearly and that would take serious architectural thinking across many files to make work.

I quickly found myself spending more time chasing hallucinations and weird AI decisions than actually building new features. I learned that it was a lot cleaner and faster to ask the AI to take smaller, more focused, steps. This change of approach allowed me be productive again.

But what's the cost of conceding to this kind of pragmatism?

In this morning's Stratechery, Ben Thompson took a contrary view of Tesla's recent "We, Robot" robotaxi event that has been widely mocked among a lot of people in tech. While Thompson acknowledges a lot of the weaknesses in the demo, he pointed out that what Elon Musk does well is communicate and pursue a big dream. By doing that, you're forced to break through the current constraints that exist with the big step changes required to make the dream feasible.

This approach is what allows you to make big leaps and tends to be proven right in the end. On the other hand, more incremental, pragmatic approaches tend to win in the short term but then dramatically underperform the big dreaming approaches in the long run.

It's not quite the same thing as the AI coding problem, but it was a good reminder for me. It's okay in the short term to think incrementally and work pragmatically. After all, you need to actually release something now. And, unlike Elon Musk, most of us don't have billions of dollars to bridge the gap between the present and the dream.

But it's important not to lose sight of the initial dream and the more hopeful applications of AI that you had when you first learned about these tools.

Eventually they're going to get good enough to handle those dreams. If you get stuck in the pragmatic mode of thinking, you're going to limit what the AI can do.

Pragmatism is good, but sometimes it's important to dream a little every now and then.

The Distance Beteween Demos and Products

Over the past several weeks, I've gotten excited about all these new AI tools that have been coming out. As a product manager with some knowledge, but ultimately fairly limited technical skills, it's unlocked a whole range of new technologies and technologies that are not just for the realm of productivity that I couldn't have done otherwise.

what's really been interesting, however, hasn't been the new things that I've discovered, but it's instead been the old truths that I've always known that have only been further highlighted by these new AI tools

the first lesson that's been reinforced for me is the huge distance that exists between demos and full products. You see a lot of cool demos of these new AI tools. People create new products from scratch in minutes, it seems. I found the reality to be a lot more complex than that. Yes, it's easy to get something running in a day, but there's a huge gulf between that and getting it to scale - something that's actually releasable to a customer

It reminded me of hackathons I've participated in at companies: someone makes something really cool in a day or two, and then the executives go, "Oh, it just took you a day or two to make that? How soon can you have this in production?" The answer: Months. Years. And no one wants to hear that.

With AI, I think we've figured out the zero-to-demo workflow. But the demo-to-product workflow still seems to be a challenge, something that's in flux.

've tried to use Obsidian for a couple years now. My main aim has been to use it to set up a nice Zettelkasten system, which I've always hoped to do after reading "How to Take Smart Notes" years ago. Frankly, I've always struggled to get into a good rhythm with it, even though it's clearly something that will be very useful for the way I work (I'm a heavy notetaker).

Earlier this year, I read the fantastic book "Duly Noted" by Jorgé Arango, which re-energized my interest in really figuring out my note-taking system with Obsidian once and for all. It's made me think more deeply about why it hasn't worked out for me in the past and become more sensitive to the friction points in the workflow that could be preventing me from using it more often.

I've identified a few friction points on both the levels of the tool and my own mental model for note-taking. One breakthrough I've had recently is in the area of customization.

Initially, I've been reluctant to customize Obsidian and add a bunch of plugins like many do. The plugin ecosystem is arguably the best thing about Obsidian.

But I was reluctant about customization because I'm generally a fan of using vanilla tools out of the box. The more customization you do, the harder it is to migrate to new systems down the road, and the harder it is to use a tool across multiple systems at once. Previously, my primary note-taking system was Notion, and it's a fairly opinionated tool that doesn't invite or even necessitate a whole lot of customization.

I've now realized that applying this mentality to Obsidian is wrong. Because it's based on the file system and doesn't really have a strong opinion about how you create notes, the tool itself is too simple from the beginning to allow for an easy workflow. For example, with Notion, I never had to think about where images are saved when I add them to a document—it just becomes a part of the document. In Obsidian, however, I did have to make decisions about this, otherwise the default option caused my vault to become cluttered with attachments immediately.

I've found that this willingness to customize and break Obsidian out of its defaults is a really important step for actually making it a useful tool. With an open-ended tool like this, it's more important to prioritize utility (through customization) first, rather than preserving the optionality that would come with using the out-of-the-box configuration.

After reading Carse's Finite and Infinite Games, I've begun to recognize that the garden could be the most important metaphor for product development (at least the kind I like to do, anyway).

The key idea is that, as the gardener, you don't "make" anything happen. A garden isn't a machine that you create and control directly to get the outcome that you want. The machine approach is the default way that most people and companies think about product. Instead, a gardener creates the right environment for things to grow, and allows them to happen. This mindset of indirect action is an important mental shift.

But beyond the core concept, I realized this morning as I was watering my own (real) garden that I don't have a strong sense of where the gardener should apply intent in this model.

In gardening, I like the idea of serendipity. If I see something growing on its own when I didn't plant it myself, I like to let it go and see what happens. If it's growing on its own without any extra effort from me, there's a sense that it is the most robust thing that's perfectly suited for the time and place that it's growing. This approach can work well: last year, the most successful producer we had was a tomato plant that sprouted up this way.

This year, however, I have a dilemma. I have a zucchini plant that sprouted up spontaneously and is growing very well. Unfortunately, it's so big that it's crowding the sun from nearby cucumber plants that I had intentionally planted earlier. On one hand, the pure gardener's mindset of "seeing what happens" would indulge the zucchini - if it's showing the be the most successful, shouldn't I go with it? On the other hand, if I let it shade out the cucumber plants, I'll lose out on plants I really wanted to have happen. How does the gardener balance serendipity and intent?

This reveals that the gardener asserts intent (or doesn't) at several steps in the process. First is the seeding - you can intentionally choose what seeds you plant and where. The second is environmental control - what conditions do you foster for things to grow? A third is management - if different things sprout up, do you allow them to continue?

What's the best way to do all of these things? Perhaps there is no easy answer; it depends on the situation and the gardener and the garden. If you don't allow anything you didn't plant to grow, you forgo many opportunities that might be perfectly suited to your garden. If you allow anything to grow, you're at the mercy of pure serendipity and it may not provide you things you really wanted. At the end of the day, mindfulness and intent is still the most important thing.

One thing I've been thinking about a lot these days is the impact of the individual in the company relative to the impact of the company itself. As an individual contributor, how much of your performance and impact is determined by you, and how much is determined by the context in which you operate?

It's a question that has serious career implications. The answer potentially implies a big change in the kinds of narratives we tell ourselves about our careers and the careers of others.

As I saw the news about Squarespace being acquired by the PE firm Permira the other day and was reflecting on my own career, I was shocked to realize how much of the work I did as a product manager was really determined by the funding structure.

I've worked underneath several funding structures in my career: subsidiaries that had been acquired by large companies, a VC-backed firm, an Angel-funded firm seeking VC funding, a SPAC company, and a PE-owned company.

When I think about it, the funding structure guided almost everything, because it determined the company's motivations and incentives. At the subsidiaries, pure revenue and company performance weren't the guiding principle; it was whatever the parent company's priorities were. At the VC-backed companies, all of the work and cadence were dictated by what we could show at the next board meeting. The SPAC company was all about spending money and the ability to raise more money. And on and on.

A lot discussions of product management treat the discipline as if it exists in a bubble—there's a "good" way to operate and decide what you work on regardless of where you're at. But, in practice, to me, it seems that the organizational incentives from things like funding structure dictate the majority of what you actually work on. Maneuver within the lines best you can, but it's never an open field of opportunity.

The funding structure determines the end goal of what the company views as valuable. And that perspective on value dramatically narrows the range of "valid" initiatives you can actually pursue.

When interviewing, this comes in to play. Interviewers often judge you on what you worked on or perhaps how you decided to pursue an opportunity. But how much of that was really up to you? And are most interviewers sensitive to the layers of incentives that exist in an organization that bear down on all that? I don't think most do, even if they're product managers themselves.

If you're evaluating a place to work, don't discount the funding structure - it may be more impactful on you than the company's product, industry, leadership team, or any other factors we usually consider.