this is sippey.com

Ken Norton, who always brings the donuts, delivers some wisdom from his career in product management.

The “art” of product management matters more than the “science” over the long term. In product management, there’s an art and a science. The science is all of the stuff you read about: managing a backlog, writing a PRD, KPIs, marketplace dynamics, growth metrics, analytical thinking, the latest agile whatever. The “art” gets dismissed as soft skills: communicating, empathy, leading without authority, having difficult conversations, storytelling, making decisions when you don’t have all the information, dealing with ambiguity, inspiring others, and connecting deeply to customers and their problems. The thing is, science gets more attention because it’s easier to understand, and therefore better for hustling boot camps and selling software tools. This trend is troublesome because it implies there’s one “right way” to do product management, and all you need to do is learn the technique or buy the right tool, and you can pass the interview, get the job, and win.

I’ve been working with Reforge the past few months as an “Executive in Residence,” helping to teach two fantastic courses: Product Management Foundations, and Mastering Product Management. Both of these courses are packed full of incredibly useful frameworks for developing product strategy, working through a product design process, developing a roadmap, setting and evolving OKRs, etc. But in the weekly case discussion I’m leading with the Reforge members, what I’m trying to do is bring the “art” to the science — helping the hundreds of people on our Zoom calls understand that learning most often comes from making mistakes, and getting things wrong. I think that approach working? Some people dig it…some people want more framework time. 🤷‍♂

Frameworks and tools can improve your chances of getting things right, but the longer I do this job the more obvious it is to me that a massively underappreciated role of the PM is how you make people feel when you’re side by side with them, shipping and iterating.

Go subscribe to Ken’s newsletter. It’s consistently excellent.

Robin Sloan, in The slab and the permacomputer, puts a finger on what makes deploying a contract to the Ethereum blockchain feel so…different.

Even so, I can’t deny that Ethereum’s “world computer” is interesting and, even more than that, evocative. The Ethereum blockchain is one entity, shared globally, agreed upon by all its participants: that’s what makes it useful as a ledger. The Ethereum Virtual Machine, a kind of computer — simultaneously sophisticated and primitive — is likewise one logical entity, even if it’s distributed in space and time.

As with a lot of things in crypto, the feeling is as much mystical as it is technical. I understand why people get excited when they deploy an Ethereum contract: it feels like you are programming not just a computer, but THE computer. That feeling is technically wrong; it is definitely just a computer; but since when did the technical wrongness of feelings prevent them from being motivating?

One of the “mystical” Web3 things that is delightfully breaking my brain is that the EVM is forcing us ask the question (again): What’s a computer?