New Year’s is a terrible time to stick to a resolution (or follow a new strategy.) Spring is not a great time to be cleaning. The air is warmer, the days are longer. I don’t want to be cooped up in an attic, going through the remnants of old hobbies. I want to be sitting on patios drinking margaritas with the people that I love. It’s much more effective to spend the time between years cleaning and leverage spring energy to propel change in your life.

After Christmas, there is a natural rhythm for cleaning up and reorganizing your physical space. Rolling up Christmas lights, stuffing them back in the closet. figuring out where to put new gifts you received, and what to get rid of to make space for them. It’s the last week of the year, the closest we get to the capitalism meat grinder taking a beat.

This period is perfect for clearing the deck and closing loops. Wrap up those projects. Get ready for tax season. Getting the house in order physically, mentally, and spiritually. In Japan, they call it Oosouji, “big cleaning.”

Then, January rolls in. It’s dark. It’s cold. The elements test you with the shittiest weather, rain 3-5 degrees above freezing. All of the chill of snow without any of the fun. I would choose a tornado over a 36℉ storm. I force myself up at 5 am to make it to the gym. It is beyond crowded. I do what I can. I’d work out outside, but you know, the rain.

I stay home. I open the work laptop. A 12 encircled red greets me. An inbox full of people who had the audacity to circle back in the new year.

I press on. February rolls around. Statistically, the worst month for seasonal depression. Whatever seasonal joy I had in the reserves is gone. If I was doing good on eating habits, too bad, combo breaker: Girl Scout cookies are back. I am not trying to be my best self right now. I am trying to survive.

And I always do. The sun rises, soup season comes to a close. People crawl out of their blankets. I was walking to my car from the doctor’s office, and a woman at the crosswalk, apropos of nothing, looked at me and says ‘wow it’s so beautiful out today!’ There is an energy in the air.

When the sun rises, so does serotonin. A 2017 study in Current Biology by Stothard et al. showed that humans’ circadian rhythms shift earlier in spring. People wake up more energized, more biased towards action, with more daylight to act on it.

Trying to be resolute in January is working against nature. Doing so in spring is working in harmony with it.

And as a bonus, the gym will be less crowded.

The Product Triad is my three-tiered model of how I deconstruct the ‘skill of product’. It's the model I'm using to organize Own the Outcome.

Product thinking: Innovating and evaluating products using your intuition and taste.

Product management: The art and science of making tradeoffs between stakeholder goals, customer desires, and engineering capacity.

Product practice: Bringing product thinking to bear when designing, coding, writing, and communicating.

Product thinking

Product sense (also sometimes called Product intuition) often feels inscrutable. “I’ll know a good product when I see it.” To the outsider, it looks like magic, as if some people see the world differently and are more in tune with design. But how does that work?

Intuition is the subconscious process of making predictions, developing expectations, spotting relevant cues, deciding what’s important, and applying or inventing solutions. For more on developing these skills, see the sample chapter How to improve your product intuition

I draw a distinction between intuition and product taste. Intuition drives your output, but taste informs it. Taste also shapes what you take in. Taste combines empathy for the user, domain knowledge of the situation, and your creative ability. Your creative ability is how skilled you are at inventing, identifying, and remixing existing solutions to solve problems. I’m borrowing this definition from Shreya Doshi’s How to improve your product sense.

Are some people born with better taste, more skill, and greater vision for what’s possible? Possibly, but it can be trained. You can intentionally improve your product intuition and cultivate your taste.

Product management

Product management—the only one of the three you can get as a job title—is about deciding what gets built and why.

Product managers have to be aware of customer desires and collect and absorb feedback. They read between the lines and understand what’s going on in customers’ heads. The only way to know what’s important is to have good taste. The only way to understand your users is to have empathy for them.

Then, they must understand stakeholder goals. Most commonly, the stakeholder is the business, organization, or client signing your paychecks. If you’re building a product for yourself, then the stakeholder is you. They will have multiple goals around monetization & growth, which vary based on their industry, monetization model, how they’re financed, and where they are in the product lifecycle.

To get anything done requires engineering capacity. Engineering capacity is made up of the resources you have available, how fast you can build, and what constraints you have from tech debt, governments, and the laws of physics. It’s why we can’t give customers and stakeholders everything they ever wanted. If you could, this wouldn’t be any fun.

Product practice

Intuition and taste are great, but only if they change the output of your work. Product managers can write a tome of roadmaps, user stories, and business cases, but none of it matters if those artifacts aren’t well-informed and actionable.

Building a better product isn’t something you can sit down and do, any more than eating healthier is a task you can check off your to-do list and be done. It’s a new way of seeing the world. A different way of practicing your craft. You bring it to bear in the hundreds of tiny decisions you make every day. How you pay attention to detail and what you do about it.

It permeates every part of the product experience. How it’s built. How it works. The words used to describe it.

There’s no such thing as a solo creative process. All design is collaborative, even if it’s between a creator and a single user. We have to bring this to how we work with others. Within an organization, the only way to be effective is to bring this to your output and build trust and influence. You need to communicate effectively, persuade, and push back on your teammates.

Everything is a product. The software you build, the documents you create, the dinner parties you throw. Hopefully, this framework can help you do that a little bit better.

Sign up to be notified when my book on product thinking for engineers is available for purchase.

In April, I wrote about some of the techniques for putting my Leeroy Jenkins ethos into action. The reception was positive, so here are five more. These are centered around building momentum and getting started when you're stuck.

1 - Break Inertia

The hardest part is getting started, so make getting started dead simple. If you are stuck in a doom loop, move. Physically move. Stand up. Flap your arms. Anything to get you physically moving. Not starting a project? Do anything. Sketch a note. Archive an email. Create an empty file. Anything! It’s all about pattern breaking.

2 - Just Push Buttons

Don’t know how to get started? Start. Action produces information. You will learn more by doing than by theorizing. I’m reminded of a quote from Ricki Heicklen about their quantitative trading school:

So when people walk through the door, the very first thing we do is have them start trading. Absolute number one, immediately just throw people in without explaining the rules, without explaining too much logic about what is all the syntax going to look like? We say, “Hey, we’re going to go around, play this trading game,” and we get them started and correct as they go. And that’s because a very very big part of our pedagogical philosophy is that the best way to learn how to trade is to trade.

“You need sufficient knowledge to get started” is a self-limiting belief. Getting started is how you know what to do next.

3 - Ask an AI

If you have no idea where to get started, an LLM can get the juices flowing. But to the first point, be wary of planning disguised as procrastination.

I wouldn’t take any plan at face value, but if you don’t know what to do next, brain dump whatever facts, wants, desires, and constraints you have, then prompt your model of choice(if you don’t have a model of choice it’a Opus 4.6) with something like:

I would like to (achieve this goal, build this product, write an essay about this). Study (my notes) Interview me and ask me questions to build out (a step-by-step implementation plan, list of potential actions). (that plan should include A, B, C)

Tweak as needed, then go through the exercise. Don’t give the AI solutions. Give it problems, and see where it goes. Even if the plan is bad, the questions could get your brain moving and spark other ideas. You’re exploring, not handing agency over to a flanker.

4 - Moments over Systems

As James Clear says, “You don’t rise to the level of your goals, you fall to the level of your systems.” While there’s truth to this, it can nerd snipe people into believing “you need a system to get started.” You don’t. System or not, you can make decisions and seize good moments.

Systems help with long-term change. But they hurt when you dodge short-term wins because you’re fixated on some bigger fix you’ll put into place “one day.”

You can pass on that glass of wine with dinner. You can order the grilled entree instead of the fried one. You can make one good decision in a single moment. You don’t need a diet plan, a nutritionist, or an app with macros and charts. You can be good without being perfect.

And besides, what is a system but a way to make the good choices more consistently?

5 - Spontaneous Deep Work Sprints

Ive read many productivity and management books, and one of the most consistent pieces of advice I see is this: the secret to getting a lot done is long, uninterrupted time blocks. They suggest you book appointments with yourself and put them on your calendar. Start the blocks like you’re going to the movies: use the bathroom and grab a snack before you lock in.

I’ve tried this several times, and it never sticks. Some productivity tricks work for some people, but personally, I have never been able to take “an appointment with myself” seriously. Hard as I try, I never stick to the work block. The other challenge is distractions: I’m on the manager schedule, and things come up needing immediate attention. Other times it’s slow, where I’m monitoring and on-call, ready to hop in where needed.

What works for me is grabbing time blocks when I can get them. I don’t schedule them, but when I have a deep work task, and I spot open time on the horizon, I decide then and there to lock in for 30, 45, or 60 minutes. The shorter timeframes are a catalyst: How much can I knock out in a sprint? I don’t think knowledge workers sprint enough, going as hard as they can for a short burst.

“Sprint” has lost its meaning in tech. You cannot sprint for 2 weeks. A sprint should feel fast, feel hard, feel uncomfortable. You should take a break after a sprint. Consider a working HIIT session.

It’s ‘moments over systems’ in practice. I can’t reliably block off time, but I can be opportunistic about the time presented to me.

Conclusion

Putting these together, I realize struggling to get started is being trapped by the Nirvana fallacy: You don’t start today because there could be better conditions tomorrow. When in fact, these are lies we tell ourselves, mental labor we bear. If we were to look at it, we would see that it is pointless. We can throw it away. We can walk lighter, freer.

You don’t need motivation to start; you need to start to build motivation. You don’t need a system or a plan to take action; you need to take action before you have a system. You don’t need to make an appointment with your future self; you just need to move.

Over my career, I’ve often left meetings flummoxed as to why my help wasn’t landing. “I can help the client optimize their funnel. Why aren’t they listening?” “I told this report exactly what they needed to do to solve their problem, but why did they seem annoyed?” I’ve now come to realize there are [different ways to advise people](https://www.statetransition.co/p/consulting-models-and-failure-modesat), and it’s crucial to know which skill to apply when.

There are four kinds of work you can do in an advisory role: coaching, consulting, mentoring, and managing. These terms seem interchangeable, but they’re not. They’re distinct skillsets that serve different purposes. Apply the wrong skill to the wrong problem, and you could get disastrous results.

The 4 types of advisory work

Coaching

Coaching is people-oriented. The primary goal of coaching is to help people grow and achieve their goals. To coach effectively, you need to listen actively and ask good questions. A good coach will get you to give an answer to a question that surprises even yourself.

Consulting

Consulting is solutions-oriented. The goal is to deliver information, expertise, and strategy. When consulting, you need to identify root causes and be able to give advice in a way people will hear. After a good consultation, you’ll feel you have a strategy and know exactly why you’re implementing it.

Managing

Managing is project-oriented. The goal is to close loops, move needles, and track performance. The most valuable management traits are the willingness to have uncomfortable conversations, make decisions, and take ownership. A good manager sets a high-quality bar, holds you to it, and brings out your best performance.

Mentoring

Mentoring is expertise-oriented. The goal is to share specific examples and lessons that help someone build knowledge and expertise. The most valuable mentoring skills are contextualizing expertise and showing, not telling. Your Miyagis, your Yodas, your Professors Xavier.

What happens when you apply the wrong skill

Know your role and shut your mouth

When I was a freelance web developer, I wanted to position myself as a ‘strategic partner’ for two reasons: the work was more interesting, and I could charge a higher hourly rate. I rubbed some clients the wrong way when I tried to contribute to the overall vision.

Once at a local bar, I ordered a whiskey bramble. “Are you sure?“ the server replied, “It’s a fruity and sugary drink.” I felt judged. I knew what I was doing; I was not looking for a more “masculine” order. If I want to put blackberry liqueur and lemon juice in my booze until it tastes like Dimetapp, that’s my business and mine alone. I understood how some of my clients must have felt.

You can’t coach those who don’t want to change, or consult those who don’t want advice. At best, you waste your time. At worst, you damage relationships. Unsolicited coaching or consulting is the professional equivalent of mansplaining.

When to help people, and when to let them struggle

When mentoring, your goal is to give answers. When coaching, your goal is to ask questions and help the coachee discover answers within themselves. The challenge is knowing when to help and when to step back and let people figure it out. It’s tempting to jump in and offer solutions when you see someone struggling. Growth requires discomfort; there is value in wrestling with a thorny challenge.

A heuristic: frustration is ok, confusion is not. People can grind on hard problems, but when they have zero idea what to try next, nudge them in the right direction.

Using the model

How would you rate yourself on each of these, on a scale of 1 to 10? If you broke your week down into a pie chart of the four types, what would it look like? When you think through the four models, you can pinpoint where to focus when skilling up.

“Are they asking for expertise, or do they just want a pair of hands?” “Does this person need help, or do I need to set expectations and hold them to it?” The four models help you pick the right tool for the job. This is why I think it’s important to draw these distinctions. If you can recognize when to apply each skill, you can be a more effective leader.

In 1995, riding high on Donkey Kong Country, Rare kicked off a new project titled Dream: Land of Giants1, a fantasy adventure game. Donkey Kong Country had been a revelation the year before. Rare put a fresh spin on the platforming genre with new environments, a two-player tag system where each character had distinct strengths and weaknesses, and pre-rendered graphics: 3D models captured as 2D sprites. It looked and played like nothing anyone had seen. It felt like the next step in evolution for platformers after Super Mario World.

If Donkey Kong Country could stand toe to toe with Super Mario World, Rare figured they could build another masterpiece on the scale of Legend of Zelda.

Project Dream did spawn another hit, but it looked nothing like the original vision. Here’s how Rare iterated and pivoted their way to the final product.

Initial feedback was tepid

In the initial beta, players explored a fantasy/fairytale setting. You played as Edson, assisted by his pet dog Dinger. This two-character system expanded on the Donkey/Diddy duality of DKC.

Then, Project Dream ran into two problems that forced a pivot. First, the technological landscape shifted. The SNES was riding into the sunset to make way for the Nintendo 64. The game became a 3D project, as was the style at the time. They built a new rendering system for the new hardware.

Second, playtests delivered bad news. The setting was too cliche, too bland, and didn't engage players. They moved to a "harder-edged piratey theme." But changing the environment wasn't enough. The game still felt generic and lacked a hook. So they started experimenting with character designs. One of them: a sword-wielding bear named Banjo.

They pressed on, and got some good news and some bad news. The bad news? Their new rendering system was so deep and complex that the game would take far too long to finish. The good news? Everybody loves the bear.

The project got scrapped. Started again. Now the bear is the main character, his sidekick a bird named Kazooie who lives in his backpack. It wasn’t until the fourth restart of the project that Rare struck gold again.

The final result

Then Mario 64 launched and redefined the platforming genre, dragging it into the 3D era. Banjo felt archaic. The game evolved into a 3D platformer, closer to Mario again. Banjo Kazooie went on to be a smash success, and ranks among the best 3D platformers of its era2.

If you've ever wondered how game companies come up with ideas like "Bear and his bird friend rescue his sister from a wicked witch," now you know. Banjo-Kazooie could have never started as Banjo-Kazooie. Traces of the original iterations survived. The main villain, Gruntilda “Grunty” the Witch, is a wicked witch fairy tale trope. Levels like Treasure Trove Cove harken back to the project’s pirate era. The end result required its circuitous journey.

What we can learn from this

Here's the thing about Rare: they cared about the core idea, and were willing to torch everything else to chase it. They dropped characters, settings, themes, rendering engines, and entire prototypes. It was never about fantasy, or pirates, or bears. It's about friends exploring a fascinating world.

This is an excerpt from my upcoming book on product thinking for engineers, Own the Outcome. Sign up to be notified when it is available for purchase.

Previous posts:

In the past few weeks, agentic assistants have gone from helping people schedule meetings to [kickstarting a “religion” on Clanker Reddit](https://molt.church/). I’ve worked through multiple iterations of engineering management tooling and realized three things:

1. There is a certain skill to building these kinds of systems.

2. It requires a mental shift in how you work to use them effectively.

3. If you aren’t careful, you can get lost in the sauce and spend too much time working on your ‘systems’ instead of being productive.

1 - The art of agentic agent design

Context is everything

Context is the information you give the LLM to work with. The value you can get out of AI is directly proportional to how much of your work you can put in plain text.

When starting, build a capture spot: a place to easily capture data throughout your day. It could be a folder, an Obsidian vault, anything. It’s a reversible decision, don’t overthink it. You don’t want to think about where you put stuff.

Then, document processes. Start noticing repetitive tasks, and how you might automate them, in all or in part. The more structured and repeatable the process, the more effective the tool will be. Remember the rule: if you do the same thing three times, write it down.

Think in building blocks

In building blocks of agentic agents, I inventoried the individual units of a system. A skill, a standard operating procedure, a file, a folder—these can all be blocks. In software development, blocks are "modules" or "units of code." When working with these systems, it helps to think in building blocks.

There are three software development heuristics I’ve found useful with modules and building blocks alike:

1. The Single Responsibility Principle - A block should only have one job or responsibility.

2. Loose coupling - A block should depend on other blocks as little as possible.

3. High cohesion - The elements of a block should belong together.

You shouldn't try to build one skill that does everything. Even a single process could have several sub-processes. Let's say you want to build your system to help you better handle meetings. That may include:

1. A skill that reviews your notes and helps you prep for meetings

2. A skill that integrates with your calendar to schedule meetings

3. A 3rd-party tool that transcribes meetings and adds them to your capture spot

4. A skill that processes meeting transcriptions and pulls out relevant information

hink about building each part of the system individually. You don’t have to solve everything. Solving one piece can be a win.

It requires practice to figure out the right level of abstraction for ‘block.’ From above, I could in theory have a different skill for each type of meeting. It may be valuable, it may be overkill. How similar are the meetings? That’s where cohesion comes into play.

If you can’t describe what a block does without using the word “and” twice, it should be split up.

When you want to modify or swap out a block, you want to do so with as little friction and side effects as possible. Building self-contained single purpose tooling speeds up iteration.

Check out Anthropic’s collection of official plugins. Imagine if you had to install all of them just to use one feature. Instead, they split their tooling into a few dozen different blocks, so you can pick and choose what to bring into your system.

Single responsibility applies to chats as well. LLMs get dumber the longer they run. They keep every message in context. The further you are from your initial instructions, the more likely they are to drift. Mistakes and misunderstandings accumulate1. Better to clear out the chat and start a new one every time you switch tasks. Even if you are doing the same kind of task many times over, it can be useful to start fresh regularly.

Define your primitives

When starting, think about the primitives of your work and how to model them in plain text. A primitive is any core object you want in your system. Here are some examples from mine:

• projects

• tasks

• people

• teams

• meetings

What's fun is coming up with features that map to your idiosyncrasies, that you don't find in many other projects. I added the monkey primitive, inspired by the HBR piece "Management Time: Who's got the Monkey?" I can track when I'm waiting on a response or feedback from someone (monkey on their back) or someone is waiting on something from me (monkey on my back).

Iteration is (also) everything

Fighter pilot John Boyd gave us the OODA loop: observe, orient, decide, act. Read the situation, pick your move, execute, repeat. You don’t have time to strategize in the middle of a dogfight. You have to act fast and stay in the flow.

In a tactical sense, these multi-dimensional interactions suggest a spontaneous, synthetic/creative, and flowing action/counteraction, rather than a step-by-step, analytical/logical, and discrete move/countermove game. — John Boyd, Patterns of Conflict, p.177

AI enables OODA looping at a quicker tempo. You can build, test, and iterate faster than ever before. Experimentation is fast and cheap. Don’t be afraid to try something, and throw it away if it doesn’t work. There will be throwaway work. This isn’t waste; this is part of the process. In creative work there is a cycle of expansion and compression.

That’s why you want well-designed modules. Faster to iterate on small, well-contained subsystems than a sprawling mess.

The difference between a good product and a great one is the number of iteration loops. Quality in creative work comes from labor, not genius. Author John McPhee wrote the book “Draft No. 4.” You don’t have to read it—the title alone can make you a better author if you’ve never considered starting a draft over for the fourth time.

Don’t try to get things perfect on the first shot. Make something, examine what went wrong, adjust your system, and try again.

Use LLMs for design & ideation

Whenever I start a non-trivial piece of work, I go through this "spec-driven development" process:

1. Sketch out a plan of what you want to achieve. Provide as much context as you can. Let’s call this doc spec.md

2. Here’s the important step many skip: Go to Claude with this prompt: study spec.md. interview me and ask me questions so you can improve the spec and then write an implementation plan.

3. After you answer the questions, ask it to write an implementation plan.

4. Start a new chat and ask it to start on the next phase of the implementation plan. (Planning and building are two different tasks, so we clear the memory.)

You can even take it a step before that, and ask the LLM to figure out how you could use the LLM. A tweet from my former coworker Kris Puckett:

Based on what I shared, ask me 5-7 questions to understand my workflow better. Then suggest 3 things I could build, ranked by impact vs complexity.

Work in these kinds of loops. Get comfortable with them. I can’t emphasize this enough. More iterations get you to where you want to be faster.

2 - A mental shift in how you work

Try working chat-first

The best way to figure out what LLMs can do is to start working chat-first. Whatever you want to do, start with a prompt. If you are already comfortable working in text, this shouldn’t be a large shift for you.

The Dual Loop Framework

When I’m cooking, I have two Claude terminals open in parallel. I call these, borrowing terminology from The E-Myth Revisited: the “working on the business” loop and the “working in the business” loop. The “on the business” loop is the system working on itself. I notice a problem, and I deal with it there. The “in the business” loop is getting the work done. These are separate enough that they can work together without running into one another.

That’s why you want well-designed modules. Easier to parallelize work with small, well-contained subsystems than with a sprawling mess.

The out-to-lunch task

Occasionally, there will be tasks that take a while for the LLM to complete. Something that has helped me: kick these off when you leave at the end of the day, or go to lunch. The agent can chug away while you’re away, and you can review the output when you return.

3 - Avoid getting lost in the sauce

Years ago, I spent too much time playing the game Cookie Clicker2. This is an idle game where you click a cookie. It taught us all that number-go-up is fun in and of itself—you don’t need the game itself to be fun. There was something hypnotic about building up the cookie clicker system and letting it farm points in the background.

If you’ve been sniped by similar dopamine-hijacking games, watch yourself when working with an LLM. They are a Skinner box, a slot machine where the jackpot is that it does your job for you. They can be hypnotic, even addictive.

There may come a time when you’ve heard of vibe coding, you are tired of typing in a chat box, and so you decide to build a piece of software to support your system. That’s awesome, and you can make a powerful tool. Just maintain focus, and don’t get too distracted building the system instead of building with the system.

I justify this meta-work to myself because I see the value as two-fold: It’s not just a productivity system, it’s a skunkworks project to test new LLM-powered coding techniques. Still, there are diminishing returns on that as well.

If you go down this route, a few words of caution:

Think hard about the architecture, languages, and data storage tools you use to build your system. These will be the hardest to reverse. If you have no idea, I recommend building it as a web app you run locally, with NextJS, TypeScript, SQLite, and a UI framework of your choosing.

Make sure your system has back pressure. Add testing and typechecking early and keep them up to date.

4 - Where do we go from here?

It’s nice to have a system that can automate some tasks for me, and take random unstructured data and help keep it organized. A big part of management is making sure everyone has the information they need, knows who to ask, and is empowered to make decisions.

A question I’ve asked myself during my recent career transition: Which job is more AI-proof, an engineering manager or an engineer? After using LLMs for both, I feel confident that both are safe. LLMs cannot replace the systems design skills needed to engineer software that scales and has a long lifespan. LLMs cannot provide the human connection, empathy, and support that a good manager, mentor, or coach can.

Read part 1 here:

A bin of building blocks

When I was a kid, I loved Lego. What kid didn't? Most of the time, I had a bin, a menagerie of simple colors and cubic pieces. Christmas was the only time I got a set, with themed pieces and instructions. A medieval castle is a medieval castle set, but a bin? It can be anything! It could even be a castle!

The joy of personalized software is that it can be anything, built by you, for you. Instead of giving you instrcutions, I’m giving you a bin. You can study the list, and think about how you can connect these together to build not just any system, but your system.

An example

I have projects and tasks stored in Obsidian files. Then I added a prioritizer agent with a rubric for prioritizing tasks, and a /plan-day command that fetches my agenda from Google Calendar via the gog skill and uses that to rough out a plan for the day. Then it creates a daily journal note for me, with the agenda at the top.

Each bolded word is one Lego in the system. Now to break down what each Lego looks like and how they fit together.

1 - Basic Tools

Claude

Claude, built by Anthropic, is the tool I’m most bullish on. I have a theory that the first follower into a market ends up winning. The Sega Saturn crashed, the Sony Playstation thrived. N*Sync had bigger hits than the Backstreet Boys. ChatGPT is the default, but I find Anthropic’s tooling more useful, so I’ll focus on it.

Four ways to interact with Claude:

1. Standard - I’m lumping the web browser and mobile apps together here. It’s fine if you just want to ask a question, but there is little room to systemize.

2. Installed app - the chat, but a little more featured. You can manage integrations and connect to your file system.

3. Cowork - a research preview behind the paywall, Claude Cowork is Anthropic’s response to latent demand for agentic personal assistants. I haven’t tried this one yet because my preferred method is...

4. Claude Code - a command-line tool that leverages Anthropic’s LLMs. My personal favorite. The command line is the most powerful way to use the computer and the one I’m most used to as a programmer. The terminal can be intimidating, but if you’re moving your work towards text files and automation, it’s a useful skill to have, and not as hard as it looks.

Think of the command line like cooking: it’s as complicated and skill-based as you want it to be. Some people are master chefs who know a litany of techniques. Some, like me, are more utilitarian. I can roast a vegetable, fry an egg, pop a tart. You don’t have to be an expert. A few skills go a long way.

A demo of cowork:

Obsidian

Obsidian is a note-taking tool. The perfect mix of simplicity, utility, and power. You write notes stored as plain-text files. You can link files with wikilinks like [[this]]. Thousands of plugins are available to extend functionality. You can add graphs (Excalidraw), queries (Dataview), or task management (Tasks). If you're interested in an Obsidian + Claude Code setup, there's a plugin that brings a terminal directly into your notes. Plain text is the easiest way to feed an LLM. It gives you permanent storage that is readable and writable by man and machine alike.

Optional: IDE (Cursor or VSCode)

If you’re getting into managing code as part of this exercise, you may want a tool for editing it. These super-powered text editors are called IDEs (Integrated Development Environments). The two best options: VSCode, Microsoft’s editor and the standard choice in the biz, and Cursor, an AI-powered fork. You can use AI via Cursor directly, but if you’re using Claude Code it may not be necessary1.

Extending Claude Code

Assume any LLM-based tool is 60% ready-to-go out of the box. You have to put in some effort to get it working how you want. It doesn’t know you, your goals, or your processes. The better you are at getting context out of your head and into Markdown files, the more effective you’ll be. Claude offers a variety of structures to customize and amplify its abilities:

Claude.md

If you’re getting started, put your rules and general logic into Claude.md. Think of this as an initial prompt Claude has at the start of every conversation. You can tell it how you want it to behave, your goals, boundaries, and constraints. Here’s an example (credit to Alex Hillman for this one) to set a communication style:

## Communication Style
- Never end sentences with ellipses (...) - it comes across as passive aggressive
- Ask questions one at a time
- Acknowledge requests neutrally without enthusiasm inflation
- Skip validation language ("great idea!", "perfect!", "excellent!", "amazing!", "kick ass!")
- Skip affirmations ("you're right!", "exactly!", "absolutely!")
- Use neutral confirmations: "Got it", "On it", "Understood", "Starting now"
- Focus on execution over commentary

💡 Pro-tip: Claude loves structured information. Headers and bulleted lists are easier for it to parse.

Slash commands

Slash commands are reusable commands you call while typing into the terminal. Claude has many built in by default, like /clear to empty its memory and /model to select the model. You can also write custom commands for repeatable processes.

If you aren’t sure how to write a slash command (and this will be a recurring theme), ask Claude to write one for you. LLMs are adept at writing text that LLMs can read. You can ask Claude to make modifications later, or go in and make more surgical edits yourself.

Example: have a /fetch-calendar command that gets your daily agenda, or a /line-edit command that does an editing pass on your article.

Agents

If you do this for a while, your Claude.md file will get large. You’ll realize a lot of the rules only matter in certain contexts. When that happens, break it down into agent files. Claude has a slash command, /agents, to help you write them.

Example: I have a frontend-engineer agent that knows how to write code according to my guidelines and style. I have an appointment-maker that knows my meeting preferences and how it integrates with Google Calendar (more on integrations in a bit).

MCPs

MCPs, short for Model Context Protocol, bridge Claude and third-party systems. Think: wrapper for an API. Claude has a list of common MCPs people integrate with.

Example: Two that I find useful, that you can install with a single command, are Notion and Playwright. If you use Notion for work, this gives your system an easy way to read and write files. Playwright, and this is a fun one, gives Claude the ability to open and use a web browser. You can add it with a single command:

claude mcp add playwright npx ‘@playwright/mcp@latest’

In theory, Playwright is the only MCP you need to integrate with every website on the planet. It’s slower and less reliable than direct integrations, though. If you’re worried about handling credentials, what I do is say: “If you run into a login or account verification page, show it to me and I’ll log in.” Then the system won’t have access to your credentials.

Unlike agents and slash commands, I never write custom MCPs. Some are useful, but I find skills and scripted integrations more effective. Still, I can’t deny a one-line command for web access is powerful. If you want to dive deeper on why MCPs may not be the best choice, highly recommend: Your MCP doesn’t need 30 tools, it needs code.

Skills

Skills add extended capabilities to Claude’s toolkit. They contain three key parts: a SKILL.md file explaining what it is, what it does, and how; scripts, code the skill can execute; and examples, which the skill uses to inform its work. Skills can be used by you, or by an agent.

(As a rule, Claude loves patterns and examples. Show, don’t tell, if you want consistency).

When starting with skills, shop the shelf. Anthropic offers skills you can download: Anthropic skills library. A few that might interest you:

• skill-creator - always install this one. You’ll want it when you start creating custom skills.

• The ones that allow Claude to read and write other file types: pdf, pptx, docx, xlsx.

Another source worth checking: Clawdbot. Clawdbot is an open-source, out-of-the-box agent framework. You could start using it as a base, but be warned, it can get expensive. Anthropic has two billing models: Monthly (a set amount of usage each month) and API billing (charges per use). Clawdbot runs exclusively on API billing, which can get pricey. I have run up $25 bills in a couple hours of usage.

BUT, Clawdbot is open source, which means you can browse its internal skill library and copy some into your project. Here are a few I’ve been experimenting with:

• gog - integration with Google Drive and Google Calendar.

• obsidian - for creating Obsidian bases.

• things-mac - integrate with my personal todo list app.

• apple-reminders - programmatically set reminders for myself.

There are many ways to manage context in Claude Code. For a deeper dive, I recommend Understanding Skills, Agents, Subagents, and MCP in Claude Code: When to Use What

2 - Data structures

How will you store and manage the data you’re working with? As stated earlier, plain text is king. Plain text integrates with everything. Free forever. Lasts forever. Start with plain text files. Two syntaxes in particular:

Markdown

Markdown is the lingua franca of plain-text formatting. You can apply simple syntax: bolding, headers, links, lists. No, you cannot change the font or colors. Yes, this is a feature. Everything I write, I draft in Markdown first.

Example

# Markdown

This is a paragraph in markdown. Some text is *bold* and some is _italic_. You can have a

## Hierarchy

### Of Headings

#### To give your document structure

You can even
* make
* a
* list.

• Frontmatter - Frontmatter is a flavor of YAML (which stands for “YAML Ain’t a Markup Language”... yes, it’s a corny recursive acronym). All you need to know: it lets you add structured data to a Markdown file. In Obsidian, these are called “properties.”

Example:

---
title: Building blocks of agentic systems
publish_date: 2026-01-26
section: Root Nodes
blogchain: Prompt Protocols
---

JSON

The next step up: JSON files, which stands for “JavaScript Object Notation.” JSON is a file of nested structured objects. Common use case: config files. Once you start a Claude project, you’ll see ./claude/settings.json as an example.

{
  title: "Building blocks of agentic systems",
  publishDate: "2026-01-26",
  section: "Root Nodes",
  blogchain: "Prompt Protocols"
}

SQLite

SQLite is a dead simple database that lives in a single file. Useful when you have several types of data and want to map relationships between them. SQLite helps when you need to aggregate records or create relations between them. If you’re an accountant who’s put 600 transactions in Markdown files, it might be time to consider SQLite.

3 - Computing

LLMs are cool and advanced, but as we’ve seen with plain text, the most powerful tooling combines them with simple computing practices that have been around for decades.

You may have seen the GPT ‘gotcha’ where many LLMs could not correctly count the number of ‘R’s in the word ‘Strawberry’

A brief explanation of why this happens (hat tip to Zhu Liang):

LLMs break text into smaller chunks for processing through a process called tokenization. Then they catalog them with token IDs. When an LLM “sees” the word “strawberry,” what it gets is a series of token IDs {496, 675, 15717} that map to certain tokens {”str”,”aw”,”berry”}. It sees 2 tokens with an ‘R’, so it thinks there are two ‘R’s.

Now, let’s compare that to Python code that does the same thing.

word = "Strawberry"
word.count('r')

None of that tokenizing and indexing. Your computer doesn’t have to send a prompt to a model in a data center and wait for a response. It just. Counts. the. letters.

What I’m saying: there’s a lot of work that doesn’t require intelligence. If a process is repeatable and doesn’t require judgment or abstract reasoning, you’re better off having code do the job than an LLM.

Scripts

But hasn’t this always been possible? Code to automate tasks is nothing new. What’s new is how easy it is to have an LLM write simple scripts for you and run them. This is what made the command line interface such a powerful pattern: LLMs run on text. Command lines are built on a philosophy of text in, text out. Combine them and you can build powerful systems.

A script is a single-file, single-purpose computer program. Typically written in Bash, Python, or JavaScript. Sometimes the model writes, executes, and deletes a script behind the scenes.

Web based UIs

Some tasks are arduous to work in via text. Maybe you want to add some pizazz to your work. One option: ask Claude to build a small web page or app that runs on your local computer.

It will not get it right the first time. There will be bugs. You’ll need to iterate.

Be wary: this is an easy rabbit hole. If you aren’t careful, iterating and maintaining your UI system becomes a job of its own and a distraction from your original goals.

I prefer Next.js for these. You also don’t need great design skills: several free off-the-shelf design systems exist. Here’s a list. Pick one that matches your vibe:

• Retro UI

• AI SDK Agents

• Cult UI

• Tailark

• Kokonut UI

• Magic UI

• Eldora UI

• Aceternity UI

• shadcn/ui

• Kibo UI

• Mantine

• Naive UI

• Ionic Framework

• Shoelace

• daisyUI

• Paper CSS

Cron

Cron jobs let you run scripts or commands at regular intervals. Maybe you wrote a “check-inbox” command that you run manually to sync with your inbox. With a cron, you could have it run every hour. Crons let you trigger scripts at different parts of the day.

Version control (Git)

I don’t know how other document-based knowledge workers survive without a version control system like Git. Git lets you keep a changelog of all committed changesets to your pile of files. Typically it’s used for code, but nothing stops you from using it for Markdown files. You can also create branches, like a temporary copy, and try something. If it works, you merge changes into your main copy. If it doesn’t, throw the branch away, no harm done, no permanent changes made.

Version control lets you iterate fearlessly. You can also use tools like GitHub to back up your work online, and even share it publicly.

A good rule of thumb: add a directive to your Claude.md to make a git commit when it finishes a unit of work.

4 - Integrations

Lastly, think about what tools you use in your day-to-day work. Apps your job provides, or tools you use personally to be more productive. Common culprits: Email, Google Drive, Notion, Slack, task trackers, and calendar apps.

Can you think of ways you might want your system to interact with them? To fetch data, write to them, or take actions? See if they have a publicly available MCP or API. Maybe you can find a Claude Code skill on GitHub or another marketplace. Between all of this, there are ways to create new slash commands, skills, or documents that help you do your job more effectively.

What comes next

Building these systems takes time and several rounds of iteration. In the next and final part, I’ll go through my notes and process for building my agentic assistant over the past few weeks.

Update: Part 3 is live:

My feeds have been overrun with take after take after take after take after take about how "Claude Code isn't just for code anymore." Everyone seems to be supercharging their "second brains" and building "LifeOSes" and "Agentic Assistants." So, of course I had to try it. And I was surprised how quickly I was willing to let it run a small part of my life.

Opus 4.5 was a step-level change. Anthropic's model hit a point where it's smart, fast, and reliable enough that people, myself included, can hand off tasks to it with a good amount of confidence. Then Clawdbot got people's heads turning. The "Claude Code for everyone" era begins. I am become Linguini, Opus, my rat.

I was already keeping an engineering manager notebook, inspired by the CTO's hidden notebook. I've long believed in the file over app philosophy. I was already using Claude Code for note cleanup and line editing. Then, my step-level change came when I watched Alex Hillman's video demonstrating his "JFDI system":

After watching, I started building new tooling around my day-to-day work. I went from manually tracking meetings in Obsidian to having an agent fetch my calendar, book my meetings, and pull in AI transcriptions and synthesizing them into status updates and task lists.

A different kind of unicorn…

Alex hit on something in his video: no project management system or CRM ever fits quite right. Work is idiosyncratic. Everyone has unique contexts, motivations, strengths, and foibles. Ashe Magalhaes has a wholesome system with a compliments workflow, birthday reminders, a custom friend social feed, and gratitude journaling.

Vaughn Tan hits on this in Boring Tiny Tools: “Generative AI coding tools now enable high-utility, highly customised, but narrowly scoped software.”

A new genre of software is emerging. Maybe “Unicorn” will no longer refer to a billion-dollar company, but to rare, one-of-a-kind precision software, tailor-made just for you.

…if you can build them

But don’t expect a magic silver bullet. Despite what people selling AI courses tell you, I don’t know that Claude Code is for “everyone.” I’m not gatekeeping or acting superior, only setting expectations for what raising your rat looks like.

Do you have systems? Can you get them out of your head, breaking them into components with clear instructions, constraints, and success criteria? Sure, you can get a system up in a couple of hours, but larger gains take many, many rounds of iteration. Alex keeps a dev log of his assistant (or at least he did; this prompt implies his agent is now self-blogging). He’s at 96 days and counting.

I was already taking notes to a near-unhealthy degree and tracking tasks in markdown files. It helps that I have 15 years of experience as an engineer. Turning fuzzy business requirements into code is kinda my jam.

Could this eventually be a job I have? Acting as a translator and transcriber for people who can’t cross the brain-to-LLM bridge? Vaughn Tan thinks so. Again from Boring Tiny Tools:

What's missing is someone to bridge that gap. Someone who can help articulate workflow needs in ways that can be rapidly prototyped, who can evaluate where a Boring Tiny Tool would make sense, and who can help grow an internal organisational culture for doing this systemically.

This requires an unusual combination: understanding of product strategy, enough technical fluency to evaluate what's feasible, and deep appreciation for how work actually happens versus how organisations think it happens. It also requires not having a vested interest in any particular technical solution.

Could I build a system like this for someone else? Technically, yes, but I’m not convinced it would be good. It would be better to teach or collaborate with people and let them figure out what to build and how to get there. You have to cook with your rat.

This piece attempts to teach Claude Code for the non-engineer. If you’re the target reader, I’d love to hear if you found it valuable, or if it’s all still mind-boggling.

If you want someone to riff with on this stuff, shoot me an email or DM.

But for now, I’m off to do another few rounds of iteration on my agentic agent, whom I’ve christened Agentic Agent, because I hate anthropomorphizing AI. Next week, I’ll go into more detail about how I built my initial prototype.

Update: Read parts 2 and 3 here:

In part one, I took a look at patterns of software design that help enable your user's agency. In this piece, I'm examining the patterns that are used to strip away agency. In the pattern language of product design, these are the swear words.

1 - Needy programs

There has been a shift in how technology interacts with users. I sensed this for a long time, but couldn’t articulate it. That is, until Niki Tonsky captured it with the term “needy programs.”

Older programs were all about what you need: you can do this, that, whatever you want, just let me know. You were in control, you were giving orders, and programs obeyed. - Niki Tonsky

Need programs get in the user’s way, and put the wants of the software provider over the needs of the person using it.

Accounts

I hate it when I buy something from an online store, a niche gift from a place I don’t plan on returning to, and now I have an account with them. To paraphrase Mitch Hedberg, I give you money, you send me a package. There is no need to bring email subscriptions into this. I not 15% off of my next purchase, I want you to get off of my back about a next purchase.

Updates

A man shopping for a washing machine sees on the label that it has Wi-Fi capabilities. He approaches a floor person. “Why does a washing machine need internet access?”

“So the manufacturer can install security updates,” responds the employee.

“Why does a washing machine need security updates?”

“Because it’s connected to the internet!”

I once sat down to play a game on my Playstation 5 and was greeted with a barrage of pop-ups. The game needed updates. The console needed updates. The freaking television? Updates.^[1]. I’m showing my age, but I miss when you could plug a cartridge into a system, turn it on, and it would just go.

Notifications

We are bombarded by notifications. Product teams know we cannot resist the siren’s call of the red numbered dot. We sit there popping these pimples on our smartphones, hoping they don’t come back. Notifying the user is fine in some cases but should be used sparingly. Notifications are a to-do list the user didn’t sign up for.

Login Modal Ambushes

I don’t need to know about your new feature the moment I log in. I logged in to do a task, and these in-app advertisements are getting in my way.

Bloat

I purchased a smart TV and, to my surprise, the home screen lagged the first time I turned it on. Response time was slow and the interface was difficult to use. The home screen had ads, pre-installed garbage apps, home connect features, and background processes running for speech control, AI features, and metrics collection. I had to find a tutorial online and spend 20 minutes in the settings getting the television to a usable state. I considered setting up an LG developer account so I could enable developer mode and disable even more stuff., I should not have to do this level of tech support on a brand new product. Lord help me if my in-laws ever buy an LG TV.

2 - Removing decisions

You should make decisions as easy as possible for users. But be wary, simpler isn’t always better.

We want software to be easy. Ideally, it makes decisions as easy as possible for us. But at times, this can go to far: simplification can steal choice away from the user. It’s the difference between a Prix Fixe menu and an airline that doesn’t let you choose your seat.

Overly simplifying interfaces

Consider touch screens in modern cars. It’s a cleaner look, replacing a swath of dials and buttons with a sleek screen. When I was growing up, we didn’t have radio buttons in forms, only buttons on the car stereo.

This simplicity comes with a cost. You no longer get the satisfying thonk sound when you switch stations. And a study by a Swedish car magazine shows that drivers take four times longer to complete a task on a touch screen compared to analog controls. This isn’t an inconvenience, it’s dangerous. The simplified design removed affordances. Drivers can no longer feel their way around the controls. drivers have to navigate menus to find the settings they’re looking for.

Greedy defaults

Smart defaults make selections for the user to reduce cognitive load. Greedy defaults exploit the shortcuts the user’s brain takes to get them to act against their own self-interest. A common example: a checkbox for “subscribe for updates” in a store checkout page that’s already set to yes. Many applications have tracking and other behaviors that benefit only the company turned on by default.

Hijacking the user’s machine

Only steal the user’s focus when it’s helpful to them, not to force their hand. Users own their machines and should decide what to do with them.

Respect the machine’s default behavior. Don’t override basic functionality within your application, or behaviors expected within an element. Examples: removing the ability to right-click on items, disabling the esc key, or having a video with no way to stop or scrub playback.

Holding the user hostage

Some applications force users to stay within a process, or worse, in a subscription, without their consent. If they can quit, they make it difficult. Give users opportunities to cancel out of any process. Let them stop a process and come back to it later. Users should be free to come and go as they please. It’s an app, not a cult.

This goes for their data too. Your application should let users export their data and take it elsewhere. Part of the genius of the Unix philosophy is that every program takes plain text as input and returns plain text as output. Use common file formats and sensible structures. Be more like Unix.

Don’t implement cancellation flows that are intentionally confusing, long-winded, or hidden. If someone can sign up for a product online, they should be able to cancel online, without picking up the telephone.

Case study: Algorithmic feeds

This is a whole other article, but I believe Google killing their Reader product contributed to the global rise of far-right fascist movements. Between 2013-2016, the way users consumed information via the internet changed. All major social media applications switched to algorithmic feeds. At the same time, Google killed their RSS reader to push people toward their own algorithmic feed product, Google+. Creators started making content for the algorithm instead of building more natural ways of connecting and sharing information. It wasn’t apparent at the time, but in retrospect it was a foundational shift from people searching out content to having content pushed at them. From pull to push.

Researchers have defined what they call attentional agency. Imagine a tug-of-war with the agent (user) on one side, the advocate (person controlling the algorithms) on the other, and the platform as the battlefield. Advocates give you options to select from based on what they think will increase engagement, not what best matches what you asked for. Chronological feeds contain 50% less hateful content and 3x the amount of links to news sources on average. Algorithmic feeds have more tabloids and mainstream news; chronological feeds have more local sources.

Users spend 73% more time on and engage nearly 20x as much with an algorithmic feed vs. a chronological one. Users also experience a palpable increase in anger (0.47 SD), anxiety (0.23 SD), sadness (0.22 SD), and a 21% increase in hostility toward out-groups.

The metrics the business cares about went up, with a real cost for the user. We feel worse, we have less control, and the platforms profit.

3 - Defrauding the user

Sometimes using the internet, it feels like everything is a little bit of a grift. If it isn’t in your face, it’s behind your back.

Deceptive pricing practices

As of 2023, Google Workspace offered two pricing tiers: Business Plus and the more expensive Business Starter. Starter was not available during signup. The only way to get it was to sign up for the more expensive plan, then downgrade. Users should be informed about how much they will pay, what they will receive, and whether it’s one-time or recurring.

Fake Urgency & Social Proof

Every time I see a store with “only 2 left!” there always seem to be only 2 left. Like the general store in O Brother Where Art Thou, these places are a goddamn anomaly. Authentic urgency is fine, but creating imaginary scarcity is fraud.

Public by default

Applications with a social component tend to default to everything being public. While this is useful for catching senators with questionable Venmo transactions, it’s harmful to users at scale. Users should opt-in to behavior that could pose a risk, and sharing things online poses a risk.

Pricing page traps

Ever click on a feature and instead of getting it, you get an upsell to the paid option? Actions should do what the user expects.

4 - Emotional Manipulation

This is the big one. Many “growth hackers” and product people don’t understand the difference between persuasion and manipulation. There’s nothing wrong with being aware of emotion in design (if you want to explore that topic, I recommend Aaron Walter’s Designing for Emotion). The problem arises when you use these techniques to make people act out of fear instead of from a place of agency.

Confirmshaming

Opt-out buttons worded in a belittling or derogatory manner, making users feel bad about declining. A chilling example, care of Deceptive Design (who coined the term):

The eCommerce website mimedic.com sells first aid packs and medical supplies. They used the following pop-up when asking for permission to send website notifications:

The copy "no, I don't want to stay alive" is troubling, given the context of serving people who have been exposed to trauma and death in their work.

Gamification & Gambling Mechanics

Gamification adds game mechanics to systems with the element of play stripped away. Leaderboards, quests, achievements, unlocks, and XP to drive behavior. It is psychologically manipulative. Uber rolled out a “quest” feature for drivers, offering bonus cash for hitting milestones. But as drivers got close to their goal, Uber fed them lower-paying rides, keeping them behind the wheel longer. They’re out driving, eyes burning, concentration fraying. Uber isn’t helping drivers have fun; it’s putting them and others at risk to increase profits.

Gamification can have positive effects too. I used to go to a CrossFit gym, fully aware that CrossFit is just gamified workouts. But it worked: it kept me coming back and got me in better shape.

Duolingo exemplifies the duality of gamification. On the paid plan, they use it to encourage language learning. On the free plan, they use it to encourage upgrading to the paid plan.

When you see gamified systems, ask: What behaviors is the system pushing? Who benefits most?

Engagement at any cost

The state of social media makes sense once you see how the numbers work. The algorithms are not trying to show you what you want to see; they’re trying to show you what will keep you engaged. Engagement can come from interest and curiosity, but it can also come from outrage, hatred, shock, anxiety, and fear. The latter is much easier and more effective.

You are the last line of defense

As software engineers, we are responsible for the work we put out into the world. Technology is powerful and has real impacts on society. I am reminded of an interview with Bo Burnham on the attention economy:

We used to colonize land. Now, it’s human attention. These companies—tech companies, social platforms—they’re coming for every second of your life. At first, they were trying to capture your free time, but now, every single moment you are alive is a moment you could be looking at your phone, gathering data, and being targeted with advertising.

And it’s not like there’s some evil mastermind. It’s just capitalism, and it keeps growing. These companies have to report to shareholders, so they can’t stay stagnant. Every year, platforms like Twitter or YouTube need their growth numbers up. The whole model is, ‘How do we get more of you, more of your attention?’

After we’ve colonized the entire earth, the only space left was the human mind and every minute of our time. Now, they’re trying to colonize every minute of your life. If you’re not online, that’s time they aren’t gathering data, targeting ads, or monetizing you. That’s what’s really happening.

I understand that pushing back against these asks is not easy. But I am reminded of another quote, this time from Jerry Garcia:

(This post is an excerpt from my upcoming book on product thinking for engineers. Sign up to be notified when it is available for purchase.)

Software feels more abusive each day, as if its annoyed it has to interact with you to get your money. Every time we log in, we accept cookies, dismiss a pop-up for the latest feature, watch an ad, hand over our phone numbers for “verification,” watch another ad, and then discover the free thing we used is now behind a paywall. Enshittification abounds. Software used to be a tool. Now products stay in control, stripping users of agency.

How can we do better? How do we design software that creates a more agentic user? A user who feels empowered to make decisions. Who takes action by choice, not coercion. Who sets a goal, believes it is achievable, and takes steps to accomplish it. Who can figure out the parts of the system that are unknown or unclear. Who trusts the tool will behave as expected, without unforeseen consequences, and provides a clear sense of where they are and where they’re going next. They approach tasks from a place of calm and control.

Case study: Unix Core Library

The Unix core library epitomizes many elements of agentic user design. A suite of 100ish single-purpose command-line tools, built at the foundational level of the OS, empowers the user to do whatever they want with text files. find to look for files, grep to search their contents, awk to process them, rm to remove them.

In the 1970s, Bell Labs had a tool-based culture. Engineers were encouraged to build tooling to solve their own problems. If others found them useful, they would roll the tools up into the Unix operating system. These tools were built around the three-pronged Unix design philosophy:

1. Do one thing and do it well.

2. Write programs that work together.

3. Everything is a file.

This way, instead of building products to solve every problem, they could build utilities people could apply to single fixes. They were building screwdrivers and gears so that other people could build specialized machinery. This philosophy led to the creation of agency-friendly software:

Setting and achieving goals: Users can compose tools together with pipes to create complex workflows for any text-based goal. If everything is a file, then anything is achievable.

Doing tasks because you decide to: The tool never suggests or manipulates. No “recommended workflows,” no attempts to influence your choices. It sits idle until you give it explicit commands.

Figureoutable: I won’t pretend using the Unix tooling is easy. It requires skill to wield. But the tools follow consistent conventions: flags with - or --, stdin/stdout patterns, and exit codes. Every tool has man pages and --help flags. Documentation is comprehensive and built in. Users can discover capabilities and see examples. Learn one tool’s patterns, and you’ve learned them all.

Empowered to make decisions: Tools don’t make hidden decisions on your behalf. You choose verbosity levels, output formats, error handling, and behavior. Every option is exposed as a flag. The tool does what you tell it.

No surprises: Every tool does its one job, no more, no less. grep always searches, sort always sorts. Tools are deterministic and transparent.

Useful feedback: Clear separation of stdout (results) and stderr (errors). Exit codes signal success (0) or failure (non-zero). Feedback is a file (everything is a file), parseable, so you can build on it.

The Unix CLI embodies “here’s what you can do” rather than “here’s what the product does.”

What lessons can we take from this and apply to building products?

Build software that is both simple and powerful

Products should be simple enough for novices and powerful for experts. Examples of power user features:

1. Hotkeys: I hope to one day be the kind of person who never touches the mouse. Hotkeys help people move faster when they’re willing to learn them.

2. Command palettes: A cousin of hotkeys, command palettes let users complete tasks via text instead of clicking and dragging.

3. Macros: Excel lets users script macros in VBA.

4. Advanced configuration: Give users more customization for those who want it. (Warning: these can create maintenance debt if you’re not careful.)

Anticipate the user getting stuck, and toss them a rope

Users will get stuck. Anticipate what bogs them down and be there when they need you most:

1. Confused. Make first-time use as simple as possible. Affordances and consistency clarify what to do next.

2. Stuck. Offer help, tips, or support docs to help them figure out the next step.

3. Unmotivated. Show progress, offer wins along the way, and connect the current task to their ultimate goal.

4. Distracted. Remove irrelevant elements from the view.

5. The task is hard and there’s nothing you can do about it. Acknowledge it. As Jake the Dog said in Adventure Time: “Dude, suckin’ at something is the first step to being sorta good at something.”

Robots & Iron Man Suits

There are two patterns technology can take when doing a task: It does it for you, or it makes you better. I call these robots and Iron Man suits. A robot handles something for the user. An Iron Man suit amplifies their abilities. GitHub Actions are robots. VSCode is an Iron Man suit. Everyone thinks ChatGPT is a robot, but it’s an Iron Man suit. Both can either enhance or take away agency.

Robots

With robots, the user hands off the task. For example, autopay for bills, CI/CD pipelines, and email filters. These patterns work best when:

• The task is repetitive and boring

• Success criteria are clear and measurable

• It’s recurring and predictable

Robots increase agency when they let you complete a task you otherwise couldn’t, or remove a task you don’t want to do from your plate entirely. Automated bill pay means you never have to think about when to pay your bill.

If you’ve watched any Sci-fi, you can imagine how this type of automation could start working against the user’s best interest. When software starts making decisions, it may do so against the user’s interests. Pod bay doors are all well and good until they won’t open. A bed that warms to the perfect temperature is nice until an AWS outage contorts it into an unusable position. They can become a black box that removes a user’s understanding and ability to decide. They can be difficult or impossible to modify.

Aim to take work off the user’s plate only when you can preserve their ability to decide and receive feedback.

Iron Man suits

Iron Man suits enhance the user’s abilities. Examples: feature-rich IDEs and design tools like Figma. Consider this approach when:

• The task requires subjective judgment and creativity

• The user needs to understand what’s happening

• The user is practicing a skill they can improve

Iron Man suits increase agency by giving you more power to complete tasks. I’m no designer, but tools like Figma and Canva enable me to communicate more visually. They enable me to complete a task I otherwise couldn’t.

The opposite happens when the Iron Man suit becomes a burden, adding to your workload instead of lightening it. Salesforce is configurable, but it’s so configurable that configuring it becomes a full-time job. Ticket trackers like Jira can streamline project management, but can also become a job unto themselves. Digital notebooks like Obsidian and OneNote can help you manage knowledge better, but can also become a burden instead of fuel for creative work.

Simplify decisions

Decision fatigue is real. If users feel it in your product, they may leave and never return. Make decisions few and easy, while preserving agency.

Keep choices to a minimum. Hick’s law: the time to make a decision increases with the number of choices. If you can’t reduce the number of choices, group them or give users ways to sort and filter (autocomplete, for example).

Give them smart defaults. A smart default is a choice that’s right most of the time. Make the right thing easy and the wrong thing hard.

Defer choices. If a choice doesn’t need to be made now, let the user make it later.

Agentic User Patterns

From looking at what agency is, how people attack it, and how others have put it into practice, we can form some patterns to guide us: We give users as few decisions as they need, but no fewer. We offer all the information and feedback they need to decide, but no more. We build products that do what they promise, when they promise, and nothing else.

Remember your place

Software is a tool for the user. The user is not a tool for your product. Design for agency: empower users to decide, feel confident, feel safe, and get shit done.

Thank you for reading. This post is part 1 of a 2-part series. The following post will explore this one’s shadow, anti-agentic dark patterns.

Subscribe now

It’s that time of year. The final week, where the worst versions of ourselves plan for the better versions we’ll be next year. We crawl out of the pile of discarded wrapping paper and plates. The background drone of holiday films begins to fade. The time to lock in approaches.

We all know resolutions are a fantasy. Most fail to lead to permanent change. Resolutions feel like a burden, like an exam you’re going to fail instead of a book that shows you a new way of thinking. You hit the gym for a week or three, then start to miss. It becomes a stressor. You toss the resolution in a desk drawer and ignore it until Q4 reflection time.

Last year, I found a different approach: I didn’t go in with a New Year’s resolution. I went into 2025 with a New Year’s strategy.

A resolution is a statement of a goal. Strategy is a framework that shapes decisions. Resolutions are rigid, strategies are flexible. Resolutions are narrow. Strategy is holistic. Resolutions lack a system for dealing with changing contexts. A strategy helps you decide what you’re going to do, how to prioritize, and empowers you to make decisions with confidence.

How to write a strategy

The word ‘Strategy’ conjures images of McKinsey consultants billing $600/hr to create slide decks. Decks with lots of charts. Charts that will do more harm than good. Strategy need not be highfalutin, and unlike McKinsey consultants, can deliver real value and change. Here’s a dead-simple summary of what I mean by strategy, riffing on the ‘kernel’ idea from ‘Good Strategy / Bad Strategy.’ A strategy has four parts:

1. Goal - What do you want to accomplish?

2. Diagnosis - What’s wrong?

3. Guiding policy - Your approach, what to do, what not to do.

4. Coherent Actions - How can you put this into practice?

That’s it. It doesn’t need to be a huge document or grandiose idea. It could be a paragraph. It could be a sentence. WWJD is a complete strategy.

(Tech bros made that weird, too, by the way)

An example

Imagine you're driving from San Francisco to Seattle, and you want to get there in under 12 hours. That's your goal. For those unfamiliar with the West Coast geography, 12 hours is a theoretically doable timeframe but the variance can be high. It's possible to lose 2 hours if you pass Portland at the wrong time, and there are several other traffic bottlenecks.

A possible strategy to achieve this somewhat optimistic goal would be to use multiple drivers to enable continuous driving while optimizing around traffic patterns rather than absolute distance or speed.

The strategy isn't "take I-5" or "drive fast", it's a higher-level approach that introduces new possibilities (can drive straight through), adds constraints (need to coordinate schedules), and impacts other decisions that might be made (no need for a sleeping stop). It's a set of fundamental approaches which generate a cascade of tactical decisions: when to swap drivers, timing of departures to avoid city traffic, length of rest periods, etc.

Dan Pupius, You need to be more strategic - A primer on strategy for software engineers

At the start of the year, I declared 2025 my 'year of actionable thinking', and I crafted the 'Leeroy Jenkins Strategy':

1. Goal - Spend less time overthinking, more time on execution

2. Diagnosis - Too much time spent on planning and infotainment.

3. General policies - Be intentional about planning and research. All information should be actionable. Favor taking small next actions and focus on progress over perfection.

4. Coherent Actions - See Jenkins Strategems, Just Push Buttons

At the beginning of the year, I was also moving from IC to engineering manager. I didn’t know what the job would entail. But having a strategy meant I could apply my original goal to novel areas. I could learn what questions to ask in meetings to drive decisions and keep us out of a planning bog.

An anti-example

My stated goal of publishing 10 posts in December. I had a goal, but lacked a diagnosis. I hadn’t considered the amount of holiday planning and activities, the ‘get it in by Q4’ work push, the general crud, the persistent cough all parents of young children have in winter. The sun, despite all the negative feedback, continues to set at 4:47pm. How can I be expected to hustle when the sun can barely put in a full day’s work?

3 ways to keep yourself honest

Once you have a strategy, you have to ensure you put it into action. Wisdom is realizing this video is sincere:

What helped me:

Regular check-ins - If you take away one thing from this post, let it be this: If you want to focus on a goal for the long term, set up a system to bring your attention to it regularly. Add a recurring task to your to-do list. Slap a sticky note on your bathroom mirror. Wear a charm or bracelet.

Strategy-driven preparation - What can you do today to enact your strategy in the future? Strategy can help you in the moment, but also beforehand, in planning and preparation. Map your route before you leave.

The Focusing Question - I’m a stan for Gary Keller’s The One Thing. Though I’ll admit you can get 90% of the value by asking yourself the “Focusing Question”, both regularly and when you don’t know what to do next: “What’s the one thing I can do such that by doing it everything else will be easier or unnecessary?”

What do you want to accomplish next year? How could you write a strategy to achieve it?

Maybe I should make a WWSLaBD bracelet 🤔

What is product taste?

Product taste is hard to define. The most useful model I’ve found comes from Shreya Doshi’s “How to Improve Your Product Sense.1” She decomposes it into three parts, stated here as “The Product Taste Equation:”

Empathy: Caring about the needs of the user and how they feel when they use your product. Defining problems and recognizing opportunities.

Domain knowledge: Knowledge about the space you can bring to bear on the problem; the set of tools you have at your disposal to solve that problem.

Creativity: Your capability to invent, identify, combine, and remix solutions to solve problems.

Taste is used to make subjective value judgements in your work. You apply all of these factors, together, to inform and improve both the inputs and outputs of your work.

Taste requires coherence

Taste is about fitting all three values together in a way that makes sense. A product made with good taste meets all of the goals, values, and preferences of the users and the creator.

Taste isn’t about deciding what’s “good” or what’s “bad.” It’s about deciding what is coherent and what isn’t. In his 1964 work Notes on the Synthesis of Form, Christopher Alexander describes a system of relationships he calls the “ensemble” of form, context, and fitness between them. Form is the shape and structure of a product. Context is the environment in which the product is used. Fitness describes how the product matches the intended function within its context.

Good taste is about deciding what works in context. Coherence is fitness. Good taste is being able to recognize a good fit. Taste brings clarity.

Taste as filter

When you can see what is coherent, you can begin to emphasize what matters most, and downplay or eliminate what doesn’t. These decisions happen at every part of the creative process:

When looking at data and analytics: Data can inform value judgements, but it cannot replace them. When we listen to numbers, we still decide which numbers are worth listening to and how much weight to give them. Taste is applied when people believe they are being purely objective. Leaning on “But the numbers say” without further justification is a cop-out.

When collecting qualitative customer data: Your taste dictates what questions you ask, and where you dig deeper and ask follow-ups. Like data, it helps you decide which feedback to listen to and which to ignore.

Prioritization: What do you solve first? Is a problem worth solving at all? Which strength should you play towards? All of these are ultimately questions of taste.

Taste is attention to detail

You can tell when someone has put in the effort to pay attention to every little detail of an application. You see it in intentionally designed loading states, in thoughtful, useful error messages. When you hit a weird edge case and the product is one step ahead of you, handling it gracefully. And you think, “Wow, they thought about everything.”

Details compound.

I was once sitting at a cocktail lounge on a business trip to SF, and I overheard a bartender teaching a new hire how to make a mojito. He talked about the order of the ingredients and how many ice cubes. How many mint leaves to put into the drink, and how to arrange them. He talked about how these details affected the drink's flavor and presentation. He mentioned that the person can see you making the drink, so the performance of making it is part of the service.

Did you know Spotify’s shuffle isn’t truly random? It avoids playing the same artist twice in five songs. Those are the kinds of details that separate good products from great ones. When you’ve put your empathy for the user over what is ‘technically correct.’

Taste in software engineering

What does taste look like when applied to writing code? At a foundational level, you may have ideas on what type of code you prefer to write. Do you write lots of small, single-purpose components, or larger, more utilitarian ones? How do you feel about TailwindCSS?2

Another form of taste shows in early systems design: realizing what’s changeable and what isn’t. Certain database decisions and interfaces will be difficult to change in the future, while others are more malleable. Some things are one-way doors, and some decisions reverse easily. The trick is knowing which one is which.

Software taste is about writing code that best fits your context. Coding with coherence. If you write software for a company with coding standards, you stick to those standards over your own.

It’s important to remember that in-code interfaces are a product. They are made with a purpose, for an audience (other engineers).

Taste is idiosyncratic

Everyone’s taste is different. Every company and every product exists in a different context. That’s what makes developing your taste worth investing in. Doing so will help you live a life that’s more coherent with both what you want and what you like. It is also specific to certain skillsets and proclivities.

For example, I feel I have a decent sense of what makes a good product or process. I’m smarter than the average bear when it comes to non-fiction business writing, else we wouldn’t be here together right now. I will never share my Spotify playlists, lest you see the cringy 00s nu-metal of my youth that I still listen to today.

The product taste equation includes your domain expertise. You can’t be an expert at everything. If you aren’t sure where to start developing your taste, start with what you’re best at.

How do you tell the difference between product taste, subjective preference, and bullshit?

You might be thinking, If taste is subjective and personal, why should anyone else listen or believe you? Why should you listen to anyone else?

One aspect of believability is a consistent track record of wins. Has the person had successes before? Do they seem to be right more often than not? Why do people let Rick Rubin produce albums? Because he got the best out of Jay-Z, Lana Del Rey, Adele, Weezer, Slipknot, Slayer, Black Sabbath, Johnny Cash, The Mars Volta, Macy Gray, and Tom Petty. If he’s producing your album, chances are he can get the best out of you to.

For subjective decisions, you can still be more objective on what you and others are applying that judgment to. Are you trying to decide what’s best for the user or for you? Are you trying to justify your pitch, or are you seeking the truth? Are you applying taste, or stroking your ego?

You can typically tell when someone knows what they talk about or cares about others. I once heard a product manager say in a meeting, “Here are the actions we want the user to take.” Which, to me, is at least a yellow flag. What does it say when they are more focused on driving the user towards what they want, instead of trying to empower the user to do what they want to do?

The best way to detect bullshit is to watch for inconsistencies and a lack of ability to explain why they are making a decision, from any logical, emotional, or aesthetic endpoint.

There will never be a complete answer. How do you decide who to listen to and who to ignore? Are you ahead of me this time? That’s right, it’s applying your taste.

This is an excerpt from my upcoming book on product thinking for engineers. Sign up to be notified when it is available for purchase.

Making cuts is easy when you’re removing the noise, fixing the bugs, and polishing the edges. It’s much harder to say no to a good idea. Or maybe that should be, a “good enough” idea. But the ability to do so is an essential skill if you want to do good work. It’s asking “why” instead of “why not?” when it comes to product decisions. There’s an old Stephen King quote:

Kill your darlings, kill your darlings, even when it breaks your egocentric little scribbler’s heart, kill your darlings.

— Stephen King, On Writing: A Memoir of the Craft

Deciding to get rid of something *hurts.* Taste requires leaning into that pain, seeking it out. Relishing it.

When working through the draft for my product engineering book, I wasn’t just removing clunky word choices and fixing run-on sentences. I cut *chapters*. Thousands of words representing days of my time. If the chapters were bad, this would be easy. But they were good points, and useful information to people. But they were incoherent with the central idea and goal of this book. A good chapter can make a good book worse if it doesn’t fit. Even if they were useful, they would take up more of the reader’s time, and risk distracting, you or much worse, boring them.

For an anti-example, see enterprise software. Checklist-based design that is built not for the people who use it, but for the procurement departments who purchase it. It’s a maximalist model: More features = more boxes checked = more potential sales.

Making cuts is often difficult and never popular. No one sits down at their performance review and gets high marks for the features they *didn’t* build in the last six months It’s one thing to kill your darlings, it’s something else entirely to kill someone else’s.. Sometimes the best you can do is ‘yes and...’ the direction somewhere else. If it’s about killing product feature, explain the costs of keeping it around, and what it’s keeping you from.

Humans are naturally biased against subtraction. We think in more. It can help to think of creation through subtraction: You are making space for what matters; You are gathering more resources to put towards other work. What does removing this get us?

This is an excerpt from my upcoming book on product thinking for engineers. Sign up to be notified when it is available for purchase.

Victorious over my November writing challenge, I’m feeling a mix of exhaustion and pride in what I’ve accomplished, mixed with excitement and terror for what comes next.

I challenged myself to grow my Product Thinking book up to a 150-page draft by the end of November. From June 2024 to October 2025, I wrote 21,000 words (~70 pages). In November, I wrote another 24,000 (~80 pages)1 words to reach the goal.

Here’s what I learned:

Number go up is stupidly, infuriatingly effective

It’s been a while since I challenged myself like this, and even longer since I succeeded at one. Apparently, the secret was to set up a spreadsheet, share it with a few friends, and track my progress.

I suspect it was the accountability in particular. I don’t know if they looked, but I knew that they could.

I kind of hate how effective this was on me. I am well aware of how companies use gamification to manipulate you: I am on day 87 of my Duolingo streak and I don’t even quiero aprendar Español anymore. I didn’t think it would work if I did it to myself.

But it comes with a cost

The metric was a tradeoff: I hit the goal. I have a lot of wet clay to work with. But I also spent a lot of time in ‘shitty first draft’ mode. I hesitated to edit because editing means fewer words, especially towards the end when it was down to the wire.

But in exchange, I have content to work with, I’ve built new writing skills, and I have more confidence that I can take on large self-directed projects. Worth it.

Being Consistent-ish

I needed to hit 778 words per day on average to reach my goal. But if I knocked out 2,000 in a day, I could take a day off and still be on track. I liked that the structure was consistent-ish. I wasn’t beholden to perfect daily consistency, awkwardly explaining to my in-laws why I’m furtively typing during Thanksgiving dinner.

There’s an apocryphal quote from Jerry Seinfeld about forming an unbreakable chain:

Seinfeld’s advice was “to get a big wall calendar that has a whole year on one page and hang it on a prominent wall,” then get “a big red magic marker.” According to the 2007 legend, it was Seinfeld himself who repeatedly emphasized the phrase “don’t break the chain.”

Later, in an interview with Oliver Burkeman, Seinfeld revealed he never meant this to be taken so literally:

‘It’s so dumb it doesn’t even seem to be worth talking about!’ Seinfeld told me. ‘If you’re a runner and you want to be a better runner, you say, well, I’ll run every day, and I’ll mark an X on the calendar every day I run! I can’t believe this was useful information to anybody. Really? There are people who think “I’ll just sit around and do absolutely nothing, and somehow the work will get done”?’2

Perfect streaks can be counterproductive. Chain systems can become a restraint instead of a motivator. If my Duolingo streak ever gets reset to 1, I promise you there will not be another 2.

We all have off days. Why punish yourself for being human?

Strengthening my words-per-session muscle

Before he founded Kit, Nathan Barry kept a writing streak of 1,000 words per day. He cited the “Seinfeld Strategy” as inspiration. He did this for 80 days and published The App Design Handbook. When I first heard about this, it sounded impossible. 1,000 words? That’s so many! How do you have that much to say, and so consistently?

Now, I’ve put in reps. 1,000 words feels easier now. That doesn’t mean I plan to bloviate and pump up my word count. What I do have now is ways to go deeper and make the material actionable: finding case studies to illustrate and adding exercises to put into practice. It’s not about using more words; it’s about having more of value to say using as few words as possible3.

I have no interest in writing a book on product theory. Knowledge is useless without strategies to put it into action. So, I lifted techniques from Diataxis, a framework for writing actionable documentation. It gave me more ways to think and talk about topics.

For example, The Big List of Product Heuristics is reference, Trust Over Titles: The Engineer’s Guide to Workplace Influence is a how-to guide, How to Improve Your Product Intuition is explanation.

What comes next

I’ve spent enough time in monk mode, typing away mostly to myself. My next steps are to socialize the work, collect feedback, and keep iterating. I’m doing this in two ways:

1. Another challenge - I’m setting a goal to publish 10 posts on Substack in December. A TenPoWriMo, if you will. Some, but not all, will be content from November edited into blog-shaped objects fit for human consumption. I’m excited to share thoughts on product taste and designing for agency soon.

2. Another beta book - I’m putting together a 20-30 page beta book from samples, and sending it out to readers for another round of feedback.

It’s been so long. It feels like I’ve done so much, and I’m just getting started. Beyond the mountains, more mountains.

Sign up to be notified when my book on product thinking for engineers is available for purchase.

1 - Needy programs, Niki Tonsky

Programs used to center what you need. Now software is all about what it wants from you. Requiring an account when you don’t need one, constant updating, notifications, pop-up windows announcing features you didn’t ask for. I appreciate that Niki coined a phrase for something I’ve observed all over the place.

2 - Collaboration sucks, Charles Cook

Don’t waste time in meetings and “collaboration” that doesn’t improve the product or lead to decisions. Instead, be a driver. Ship things yourself.

3 - Seeing like a software company, Sean Goedecke

This article brought clarity to = everything I’ve puzzled over about annual planning processes. Engineers love efficiency, legibility runs counter to efficiency, but legibility delivers utility when planning, making tradeoffs, and securing long-term enterprise deals. Seeing through the lens of legibility clarifies decisions up the ladder.

4 - A list of every interaction concept, Anthony Hobday

As a hoarding digital goblin, I gotta respect a quality collection like this one. A superb resource for thinking about how users think about interaction design. Props to Anthony for putting it together.

5 - If your product is great, it doesn’t need to be good, Paul Buchheit

A classic from the engineer who built the prototypes for Gmail and Adsense. An antidote to “more features = better” thinking. Instead, pick three key attributes or features, nail those things, then forget everything else. If you knock the core feature out of the park, users will overlook and forgive more than you’d expect. By focusing, you’re forced to find the true essence and value of your product.

Sign up to be notified when my book on product thinking for engineers is available for purchase.

Got a recommendation for something I should read? Drop it in the comments!

Poultry farms want to divert resources to female chickens early to increase egg production. Poultry owners once had to wait until chicks were 5 to 6 weeks old, when adult feathers started to come in, before they could separate the chickens. Then, in the 1920s, the art of chicken sexing was invented in Japan.

Expert chicken sexers can look at a 1-day-old chick and identify its gender instantly. It was the free 2-day shipping of the early agriculture era. They can categorize 800 to 1,200 chicks per day with 99% accuracy. Ask them how they can tell, and they say, “I don’t know.”

How can they do this? How does one learn such a skill?

The training is simple. At the Zen-Nippon chicken sexing school (imagine graduating high school and telling your parents your post-grad plan was that), trainees are shown chicks, make a guess, then get told if they’re right or wrong. They do this several times in a tight feedback loop.

Over time, their accuracy improves. They aren’t sure why.

We can learn to pick up on decision points, even if we don’t know what they are.

Subconsciously, our minds use heuristics to make decisions, even when we aren’t aware of what the heuristics are or what they judge.

We can learn to discriminate between objects and form categorizations from exposure to instances. The more features you build and the more you see, the more likely you’ll “just know” a solution to a problem when one comes up in a meeting, even if you don’t know how you reached that conclusion.

These processes are known as implicit learning. Times when learning takes place in the absence of awareness, and without access to what has been learned. While this knowledge is not available via introspection, it can be enhanced with intentional learning. When you learn intentionally, you are applying examination to the work.

Designers may look like or even feel they’re shifting and nudging as they iterate on an interface. In reality, they process a high level of decision points on some level: they consider more lines, edges, colors, interactions, and features than they could articulate. That’s not to say there isn’t reasoning, or that designers cannot reason. But they don’t have to.

The more proficiency you gain understanding and recognizing quality product, the less time and energy you spend making these decisions.

This is an excerpt from my upcoming book on product thinking for engineers. Sign up to be notified when it is available for purchase.

Attention

Banner blindness - People ignore elements similar to a common pattern if they’re not interested in that type of content, even if they aren’t sure what that content is.

Color - Stand-out colors grab people’s attention.

Doherty Threshold - People’s attention and productivity increase when interaction response is within 400 milliseconds.

Focus - Interfaces should contain the information needed and nothing more.

F-Pattern - Users scan web content in an F-shaped pattern, reading the first lines fully, then scanning down the left side.

Inattentional blindness - People might not see something they’re not looking for.

Jakob’s Law - People spend most of their time using digital products other than yours.

Novelty bias - People pay attention to new things.

Scanning - People look for information quickly. Information and interfaces can be designed to make scanning easier.

Visual weight - Attention is drawn to items with the most visual weight.

Z-Pattern - On pages with less text, eye movement follows a Z-pattern from top-left to top-right, then diagonally down and across.

Communication

Anticipation - Products should communicate with knowledge of what comes next.

Context-specific communication - Communication style should suit the context people are using the software in (for example, Mailchimp stops being jovial when there are problems or error messages).

Denotative color - Colors are assigned a specific meaning, either culturally or by the design.

Empty states - Empty states should communicate well with the user.

Preview changes - Show users previews of changes in real time and how the action will affect something as they consider options.

Status visibility - The product should keep users informed about what is going on.

Useful animation - Animation can help the user understand how the interface works.

Complexity

Bloat - Bloat is a function of too many features for too little cognitive space.

Combinatorics - If two or more sets of elements can be combined, then you have to account for X * Y total potential outcomes.

Discoverability - There should be ways for users to explore and discover how the software application works on their own.

Four methods of simplification - Remove, organize, hide, displace.

Halstead complexity measures. The higher the number of inputs, the amount and depth of nested elements, the types of actions available, the higher the complexity, the potential branching logic paths, the higher the complexity. The previous sentence would score quite high.

Law of Prägnanz - People interpret groups of complex and ambiguous shapes in the simplest form possible.

Operational simplicity vs perceived simplicity - Working simple vs. looking simple. These can be at odds.

Simple & powerful - Products should be simple enough for novices and powerful for experts.

Tesler’s Law - A system’s complexity cannot be simplified beyond its condition to function. Simple interfaces require complex code.

Context

Affordances - The design of a thing should tell you how to use it. For example, a form field for postal code should only be long enough for 5-9 characters.

External consistency - Things should behave similar to examples outside of your design.

Familiarity - The design should speak the users’ language and follow real-world conventions.

Internal Consistency - Words, actions, and other affordances should have consistent meaning.

Pre-attentive processing - People unconsciously take in information about their environment before they take it in consciously.

Copywriting

Document - Build a product that doesn’t require documentation, then document it anyway.

Grouping - Group similar items or action under group titles.

Inverted Pyramid - Present the most important information first, followed by supporting details.

People don’t read - Assume people don’t read the text in software.

Readability - Use typography that ensures your text is readable in your interface.

Specific actions - Actions should be specific so the user knows what will happen.

Decisions

Choice overload - Too many options hurt users’ decision-making ability. How they feel about the experience as a whole can be impacted as a result.

Deferred choices - If actions aren’t required now, they should be possible to leave until later.

Hick’s law - The time it takes to make a decision increases as the number of choices increases.

Smart defaults - Make the right thing easy and the wrong thing hard.

Errors

Emergency exits - Users can quickly correct mistakes or backtrack on choices.

Error prevention - Prevent errors where you can and provide clear feedback when you can’t.

Error recovery - Error messages should provide a solution.

Graceful degradation - When errors or failures occur, the system should continue to function in a reduced capacity rather than failing completely.

Worst-case design - Interfaces should be designed to cover the worst-case scenario.

Forms

In-line errors over global errors - Better to show errors in proximity to where they happened.

Labels over placeholders - Placeholders disappear, are not accessible.

Mark optional or required fields - You don’t have to mark them all but mark one or the other.

Radio buttons vs. Checkboxes - Radio buttons are single select, checkboxes are multi-select

Validation - Include logic to check that a field has been filled out correctly.

Interaction

Buttons vs Links - Buttons take actions, links go places

Confidence - The user should have confidence that performing an action will have the outcome they expect.

Control redundancy - It can be good to have multiple ways to perform an action - i.e. a keyboard shortcut, a button, a menu item.

Fitt’s Law - The time it takes to click a target based on the target’s size, distance, and position.

Keyboard-only interaction - Some people interact with software with their keyboard only, either for accessibility or power-user reasons.

Object permanence - Objects should not appear and disappear as if by magic, it should be made clear why they did through animation, layout, or some other tool.

Postel’s Law - Be liberal in what input you accept from the user, and limited in what you ask of them.

Principle of Least Astonishment - Systems should behave in the way users expect; surprising behavior should be avoided.

Simulated physical interaction - Items moving with momentum can help communicate how the application works.

Layout

Cause-and-effect - It should be clear what changes an action caused to happen.

Conditional elements - Hide elements if they are not relevant to the user.

Control proximity - Controls should be near what they affect.

Law of common region - When elements are positioned together within a region or boundary, the user perceives those elements as belonging together.

Law of connectedness - We assume elements connected by color, lines, frames, or arrows are part of a related group.

Law of Continuity - The eye follows lines, curves, and sequences of elements.

Law of Proximity - Similar items should be closer, unrelated items should be further apart.

Law of similarity - Elements that look similar will be perceived as being a related group.

Memory

Miller’s Law - People hold an average of seven things in their working memory they can identify.

Negativity bias - People remember bad experiences more than the good. The bad feelings of losing $20 is stronger than the good feelings of winning $20.

Recognition over recall - The machine is the user’s memory, not the other way around. A GUI lets you recognize commands, a CLI requires you to remember them.

Serial position effect - Users are most likely to remember the first and last items in a sequence.

Spatial memory - People remember elements by their position.

The Von Restorff Effect - One visually unique object will be remembered among a group of visually similar objects.

Zeigarnik Effect - Uncompleted or interrupted tasks stick in people’s memories more than completed tasks. Give users ways to track incomplete tasks in-app so they don’t have to do it in memory.

Speed

Doherty Threshold - Productivity soars when a computer and its users interact at a pace (<400ms) that ensures that neither has to wait on the other.

Immediate Feedback - Systems should respond immediately to user actions to maintain flow and confidence.

Latency - People assume a system is lower quality if interactions take more than 100ms.

Parkinson’s Law - A task expands to fill the time allotted for its completion. Design tasks to take as little time as possible. Give users estimates on how long things will take.

Task Flows

Communicate progress - Provide users with clear progress or task status visibility to keep them motivated.

Escape hatches - Provide the user with a way to abandon what they are doing.

Goal-Gradient Effect - The closer a user gets to a goal the more motivated they are, and the faster they move to complete it.

Incremental construction - A person might need to start on something now, add to it later, work on it over time, etc.

Midstream task change - Sometimes people change what they want to do in the middle of doing it.

Minimize clicks - Reduce the number of clicks & actions a user needs to complete a task.

Progressive disclosure - Display things in stages instead of all at once.

Remove steps - Steps the user shouldn’t have to take should be removed.

Save progress - Provide the user a way to save and come back to a task in case they get detoured.

Streamlined repetition - If something needs to be repeated it should be possible to repeat it endlessly.

Quality

Aesthetic-Usability Effect - People are more tolerant of minor usability problems when an interface has an aesthetically pleasing design.

Paper cuts - Lots of small usability issues add up to a negative experience.

Peak-End Rule - People judge experiences mainly on how they end.

Sturgeon’s Law - 90% of everything is crap.

Sign up to be notified when my book on product thinking for engineers, is available for purchase.

Sources

1. Nielsen’s 10 Usability Heuristics for User Interface Design

2. Every Interaction Design Concept

3. Laws of UX

The traditional NaNoWriMo challenge is:

1. 50,000 words

2. Start from scratch

3. All words related to the project count.

I’m doing it differently:

1. I’m aiming for 45,000 words, not 50,000. This is roughly 150 pages, the minimum I consider a viable book length.

2. I’m starting with an existing manuscript at 21,733 words.

3. Only words in the manuscript count. Notes, outlines, blog posts, etc., do not.

This means an average of 776 words, or 2.5 pages, every day. That feels difficult but achievable. I’m ready to finish this project, and I hope this will be the kick-in-the-pants that I need. The clock silences the ego.

For that reason, this Substack will be on the back burner for a month. I may post some drafts and content along the way if it feels worth sharing, or a random post if I have an itch2, but no promises. Then I will spend December getting back on my usual bullshit or recovering from the burnout of this challenge. Only time will tell.

I’m doing this along with a couple of people from the Useful Books author community. If you’re interested in taking on a similar challenge, respond in the comments or DM me. We can help keep each other accountable.

See you soon, hope you had a happy Halloween! 👻

There’s a game at play here. Six, give you more content than you can handle, informed by all the personal information they’ve collected. They engage you, drain you, and monetize you. They make money by stealing your attention and making your life worse. That’s an asymmetric game. We can’t win.

There’s another game. One where we share with each other. The way the internet once was. Thoughtful, human-to-human recommendations. That’s our co-op game. We can all win that one.

I find the most interesting books through recommendations from interesting people. Conversations with friends. Or, references in books or recommendations from their authors. The Algorithm will only show me things it thinks I’ll like based on its profile of me. Only a person can show me something that’ll change me, that I’ve never seen before, based on who I am. For example, The Uncertainty Mindset fundamentally changed how I think about business. It’s criminally under read, and I never would’ve found it if someone hadn’t told me about it.

Good recommendation game

There’s an art to making good recommendations. If you want people to appreciate what you’re giving them, you need good recommendation game. You make recommendations valuable by making them specific and unique. Recommendations are something of a homework assignment. You owe it to the recipient to put in some effort on your end.

A recommendation is more likely to land if you:

• Explain why you’re recommending this thing in this context

• Summarize the value and explain why it’s worth their time

• Call out a specific feature or pull an excerpt of what you’re recommending

• Recommend one onboarding piece instead of an artist’s catalog or YouTube channel,

• Share a list of 3-5 items. Telling me you have “60 AI tools I should add to my dev workflow” tells me nothing

• Give them a ‘hook’ that explains how your recommendation connects to their interests or work

• Give a comment that helps the OP explore their original idea further, or asks an interesting question of them.

A couple of threads worth reading on recommendation game: 1, 2

Be a tour guide

We are smothered by infinite content. People are hungry for guidance on what’s worthy of attention. They want help finding the top 1% among the slop.

You can be a tour guide by sharing your best finds. You can help others navigate. Recommendations are a public service. Doesn’t have to be a comment or convo, can be a post, that helps people without you even realizing it.

The Call to Action

Send me your reading lists! Your playlists! Your books, articles, podcasts, songs, and videos that had a profound impact on you. The ones that changed rewired your brain. Made you feel alive.

Tell me why. Practice writing an impactful recommendation in the comments. 👇

I promised ‘behind-the-scenes’ of the process when I kicked this off, so here goes. The two big stumbling blocks I hit, and where I’m aiming to go next.

The story so far

My goal was to create a ‘beta book ': a 20-30 page version of the book that I could send to a few beta readers for feedback. After a lot of writing, I ended up with 60 pages of content.

Roadblock 1: Initial beta doom loop. Working on something that large, for that long, and showing it to someone in a messy, unfinished state is terrifying. I spiral between “it’s not good enough” and “this isn’t fast enough.”

Eventually, I printed out the book, went over the whole thing with a red pen, and worked it into something I was comfortable showing people. The physical book set a good boundary. Editing in paper is more taxing than dragging and dropping digital blocks. Whatever came out of this phase, I decided that was the beta book.

The feedback

I was able to find some wonderful people who were willing to take the time to provide honest feedback. (You know who you are, much love ❤️).

Beta reading was painful and indispensable. Design is a collaborative process, and writing a useful non-fiction book is a design problem.

Key points:

1. More case studies, more examples, more exercises. I need to do a better job of painting a picture and putting the principles into action

2. Some topics were underexplored, such as taste and social responsibility.

3. I need to spend more time explaining and clarifying complex ideas, like the recognition-primed decision-making model

sticking point 2: The pile of grist? Grist is the raw material from wheat that is processed into flour and other useful commodities. I am sitting here with 60 pages, 133 notes, comments, and an ever-growing pile of articles, papers, books, and videos to sift through for research. I am buried in grist.

How in the world am I going to get from here to a polished 150-250 pages, which is my goal? I feel like I signed up for a marathon and just hit a wall on mile six. It has felt overwhelming thinking about how much further I have to go.

The plan

Stop overthinking, start anywhere. Same monster I’ve fought all. year. I’ll start cleaning up small mistakes, adding new information as I discover it, and applying the feedback I’ve received so far.

Focus

I am going to double down on the sections that are working and cut on the ones that aren’t. I’ll dive deeper into building product intuition and collaborating with others. I’ll cut back or reduce the focus on things like prioritization and estimation. That content might end up as content on this site.

Interviews

I am going to reach out and interview product-focused engineers, product managers, and designers across a variety of companies. This will help me collect more case studies and cover blind spots.

Read the canon

I heard (obviously false but truthy) that if you read the 4 books on the canon of a subject, you’re more knowledgeable about that subject than 98% of people. So, figure I need to start by digging into the most often recommended books on my subject:

• The Design of Everyday Things

• The Mom Test: How to talk to customers & learn if your business is a good idea when everyone is lying to you

• Inspired: How to Create Tech Products Customers Love

• Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days

• The Lean Startup

Collect

I love hoarding examples and frameworks like a little digital goblin1. As I go, I want to build reference materials on product thinking models, usability heuristics. Like when Anthony Hobday made a list of every interaction concept.

Want to help?

DM or email me if you’re interested in being a future beta reader. Or if you know any product-focused engineers who have a story to tell, I’d love an intro :)

Also, if you want to have a conversation about product thinking, taste, why engineers should care about this, or the obligations engineers have to their impact on society and the world writ large, reach out via DM or email, I’d love to have an interesting conversation!

The more interesting conversations I have, the better the book will be in the end. Hell, having an excuse to kick off interesting conversations is one of the reasons I started this project.

Sign up to be notified when my book on product thinking for engineers is available for purchase.