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 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.

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

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! 👻

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.

1946

Robert McNamara steps into Ford's World Headquarters in Michigan. A former statistical control officer from the Air Force, Robert is tasked with bringing mathematical rigor to Ford's purchasing department. For 15 years, McNamara's quantifiable decision-making practice lays the groundwork for modern management science. He climbs the corporate ladder.

1948

500 miles south of Robert, Edward Lansdale starts work in a different enterprise. A recent psychology graduate, Edward joins the CIA to explore unconventional tactics of influence and persuasion. His psychology-based strategy lays the groundwork for modern psychological warfare

1960

Both men had made huge strides in their careers. Robert McNamara is the president of Ford. Edward Lansdale works at the Pentagon, a special assistant for counterinsurgency reporting directly to the Secretary of Defense. He rises through the agency ranks.

1962

America is entrenched in Vietnam. Lansdale has a new boss: McNamara. There is belief his mathematical approach will win the war. Lansdale disagrees. While united fighting on the battlefield, they are at each other's throats in the war room.

McNamara believes he can solve for x, where x is ending the Vietnamese civil war. He runs the army like an assembly line, optimizing for metrics like enemy troop strength, area controlled, and body count. He's famous among deputies for his catchphrase: "If it can't be measured, it doesn't count."

Lansdale believes the war is being fought on what can't be measured: the hearts and minds of the Vietnamese people. We shouldn't optimize for body count but for loyalty and trust.

"You can kill a Viet Cong, but if you don't win over the villagers, he's back tomorrow" — Edward Lansdale

While Lansdale strongly disagrees, McNamara is his superior. It’s his duty to follow orders. The war rages for three more years. While McNamara turns in briefings boasting statistics like "enemy losses of 10,000 in the past week," Lansdale watches the enemy's conviction hold firm. Unable to solve the conflict on a psychological and personal level, the United States is forced to tuck its tail and run.

1968

Robert F. Kennedy (senior, the sane one, not the possum-nomming one), on how metrics miss what’s most important.

The gross national product does not allow for the health of our children, the quality of their education or the joy of their play. It does not include the beauty of our poetry or the strength of our marriages, the intelligence of our public debate or the integrity of our public officials. It measures neither our wit nor our courage, neither our wisdom nor our learning, neither our compassion nor our devotion to our country, it measures everything in short, except that which makes life worthwhile. — Robert F Kennedy, commencement address at the University of Kansas, 1968

2025

The stakes are lower, but the shape is the same. Companies track product performance and health through metrics. Instead of counting bodies, we count clicks.

I'll fight the same fight Lansdale did, even if it doesn't make me the most popular person. But I can't help it. Sitting in a room for 8 hours a day, alone, jumping between Zoom, Slack, Notion, and Cursor, and back again, is psychologically draining. What keeps me going is knowing that when I push pixels around, another human being sees them and accomplishes their goals without feeling frustrated or manipulated by my work. Remember: numbers don't use products, people do.

Motivations matter

To create a quality product experience, you must be attuned to your user. You need to be able to understand and feel their mental and emotional context, even if you can’t articulate it.

Your motivations show in your work. People can tell when a page was designed to help them, and when it was designed to manipulate them. AI has led to a proliferation of more and different kinds of slop, but slop has always existed. The question isn’t if something is AI-generated or not, the question is whether or the person who created it tried. People can tell if you tried.

Every product decision doesn't need to move a needle. Making users' lives easier, building trust with them, or making them smile at a delightful surprise is enough. If you can't do this, metrics approach zero because no one will want to do business with you.

Metrics are useful, but they are not a replacement for taste, effort, or care.

Don’t serve spreadsheets, serve people

How people feel when using an application cannot be quantified. It can be ruined by putting numbers over people.

People slack on social media, and feel guilty. They read rage bait and raise their blood pressure. The iSkinner Box of random red circles feeds an undercurrent of anxiety. No one feels good after a doomscroll. Our feeds fill with vertical videos created to serve the algorithm, not the audience. They lock their phone, curse the time wasted, and do it again. Tech companies have won the numbers game, but the people have lost a piece of their hearts and minds.

Why does this happen?

People hate uncertainty and love legibility. Our lizard brains interpret uncertainty as risk and trigger unhelpful threat responses. We become less rational, more reactive. What threatens us? The consequences of being wrong. We reach for numbers to give us certainty.

The nice thing about data is its friend: plausible deniability. If you make a decision based on perception, taste, or expertise, you own the outcome. If you point to a graph, you can pass the buck. You were doing what the data drove you to do.

We like legibility because it’s simple. It's difficult to compare two versions of a product UI and know which users will prefer. However, we can ask people on a scale of 1 to 10: Would you recommend this to a friend? Then it isn't a value judgment, it's a simple comparison. A much easier question to answer.

Taste, qualitative data, are all illegible, messy, and worth it.

Metrics are signal, not strategy

I'm not anti-metrics, I am anti-metric myopia. Some things can and should be boiled down to numbers. System performance can be quantified and changes measured.

Metrics can provide insight and help identify leaks in your product and opportunities we would otherwise miss. They are one lens through which to see the world.

Problems arise when you assign numbers to things where they don't belong, or you push less measurable aspects aside because they don't fit the equation you've devised for setting priorities.

The first step is to measure whatever can be easily measured. This is OK as far as it goes. The second step is to disregard that which can't be easily measured or to give it an arbitrary quantitative value. This is artificial and misleading. The third step is to presume that what can't be measured easily isn't important. This is blindness. The fourth step is to say that what can't be easily measured doesn't exist. This is suicide.
— Daniel Yankelovich, "Corporate Priorities: A continuing study of the new demands on business" (1972)

Metrics are useful, but they are not a replacement for taste, empathy, and giving a damn.

Leave a comment

Your feedback will help me make a better book for everyone, and is greatly appreciated.

Table of contents

1. What is product engineering?

1. How it behaves vs. How it works

2. The code-to-product spectrum

3. Focusing on the ‘why’ of your product

4. Everything is a product, everyone is a customer

2. Why product thinking matters

1. Product engineering helps you climb the career ladder

2. Getting a seat in the room where it happens

3. Most software sucks, many engineers are to blame

3. Product thinking in practice

1. Building your product intuition

2. Cultivating taste

3. Seeing the long-term vision

4. Learning product vocabulary & understanding your gut

4. Applying product thinking to code

1. Finding and minimizing edge cases

2. Removing roadblocks

3. Mistake prevention & error recovery

4. Creating delight

5. Prioritization

1. Does it even matter? How to know you are working on the right thing?

2. The importantce of serialization

3. “Keep the lights on” vs. “new feature” work

4. Prioritization principles

6. Problem definition

1. Defining the problem

2. Identifying pain points

3. Asking better questions

4. Who are the stakeholders, and why do they care ?

5. Identifying business problems

6. Identifying customer problems

7. Solutions design

1. How to derive solutions to pain points & problems

2. Seeing from the user’s perspective

3. Solutions and Shareholder Value

4. Finding quick wins

5. Solution archetypes

6. Balancing new solutions with existing product

8. Understanding the business

1. How does your business make money?

2. How company size & maturity affect product

3. What business value is, and how to create it

9. Iteration, editing, and revising

1. OODA loops and increasing velocity

2. Action produces information

3. Getting feedback early

4. Using analytics effectively

5. A/B testing and other forms of experimentation

10. Cross-functional Collaboration

1. Executive translations

2. Handling conflict

3. Building trust and influence

4. Talking about tradeoffs

5. Pitching ideas

6. Asking for & recieving feedback

7. Giving feedback

11: Conclusion

1. Putting it all together

Many engineers have a blindspot of impact of what they’re building.

There’s a lot of crappy software out there. Confusing interfaces. Presumtive modals. Death by a thousand clicks. Someone built those, and they are hiding behind excuses like “I built what I was told.” and “I did the best I could in my situation.” Sometimes that’s true, but even so, engineers have more power than they realize.

You can push back. You can ask why. Even within constraints you have insight, influence, and leverage. The problem is most of us haven’t been told how to take and wield it responsibly.

That’s what this book is about.

It’s for engineers who want to do better work—not just cleaner code, but better products. The book I wish someone would have gifted me earlier in my career.

I’m not interested in blame, I’m interested in responsiblity. The way to make software better for everyone is for more engineers to internalize that We are responsible for outcomes, not just implementations.

The best engineers I’ve worked with weren’t always the most technically-skilled or the fastest. They were the ones who understood the whole experience. They understood that every decision had a user on the other side.

What we build matters

Every software product changes someone’s life, even if it’s only a little, even just two minutes a day. That still counts. Time and attention are finite.

Are you respecting that?

Yes, we have to balance this with clean code, and scalable systems. But those are just part of the equation. What does using our software feel like? Does it help someone solve a real problem?

We’ve all done it, so we all know it: It sucks to ship garbage. Maybe there was looming end-of-sprint deadline. Maybe we could only justify “good enough.” But it's more fulfilling to ship quality. There are few things more human than helping others by thoughtfully creating something useful.

Doing more of this kind of work is possible, and it starts with a mindset shift.

Product thinking is a learnable skill

Taste is not an innate gift. It’s a muscle you can train. You don’t have to be a product manager or a designer to learn how to recognize good work, empathize with users, and develop a sense for what works and what doesn’t.

And it’s a skill that’s only going to appreciate over time.

In the vibe coding era, taste wins.

If anyone can spin up CRUD app with AI, what makes your work stand out? What you choose to build and how well you build it becomes the differentiator. That’s not a thought experiment. This is happening now.

The engineers who will thrive now and in the future are the ones who can build with care, precision, and a commitment to clarity and usefulness.

What’s in the book

Here’s what I intend to cover:

1. Building your product sense and intuition

2. Indentifying customer pain points, and solve them

3. Designing features that remove roadblocks and create delight

4. Gaining business fluency and understand how to align your work to business goals

5. Thinking through and making technical/product/business tradeoffs

6. Gaining influence at work without playing office politics

7. Communicating clearly and effectively with non-engineers

8. Taking ownership without overreaching

9. Prioritizing what matters, and letting go of what doesn’t

10. Leveraging product thinking to shape your career

Let’s build something better

If this resonates — If you’re one of the engineers who gives a damn, subscribe. If you do, you’ll get:

• Early access to chapters

• Behind-the-scenes looks at the process

• Subscriber-only invites to give feedback and shape the book

Subscribe now

We can’t fix the whole industry. But we can raise the bar, one button, one bug fix at a time.

Want a preview?

Here’s some sample content that’s already available:

Questions, comments, concerns?

Leave them in the comment section below, or DM me if it’s private. You can also find me on LinkedIn and Bluesky.

Inspired by Murray Davis's That's Interesting

Disclaimer: I never said the ideas would be correct, useful, or good. I said they would be interesting.

Influence is earned by demonstrating reliability and capability while building trust through relationships.

Influence is earned, not given

When studying for my new engineering management position1, I stumbled across this quote:

Once again, we see a new manager fall into the trap of relying too heavily on his formal authority as his source of influence. Instead, he needs to build influence by creating a web of strong, interdependent relationships, based on credibility and trust, throughout his team and the entire organization — one strand at a time. — Linda Hill, Becoming the boss

New managers think that just because they have a fancy new title, people are going to listen to them. As a recent engineer turned manager, I can assure you that’s not always true. There are ICs in the company that have more clout than me or most managers. It bears repeating, a better title does not by default give you more influence.

Trust starts with credibility. You can’t bullshit your way into credibility. You have to earn it by displaying competence and reliability. How?

You deliver. The right thing. When you said you would. Repeatedly.

Displaying credibility in your day-to-day work

There is unspoken power in being the person who delivers the final product to the user. You likely have more say in your day-to-day to make an impact than you realize. Here are some ways you can have more impact and start to build credibility at work:

1. Prioritize high-impact work over low-hanging fruit

Given a list of tickets, I might ask myself: “Which of these will have the biggest impact on the user?” “Are there any quick wins or low-hanging fruit I can tackle?” Sometimes, I do an easy little ticket in the morning as a treat2. As long as everything else is moving along, no one has ever complained about people making quality-of-life improvements of their own volition.

2. Prioritize quality

You can decide how much time you want to dedicate to quality. For example, I once built a new spending summary component for a debit card page. The designs didn’t call for animations, but I noticed the transitions felt clunky without them, so I took extra time to add them. The UI was higher quality because I decided it would be.

Everyone makes tradeoffs about time vs. quality3. Most people default to shipping faster. You can make yourself an outlier by moving in the other direction, even just a little bit. You must prefer visible product quality over invisible code quality, and you can’t go too far. No one wants to work with a slowpoke.

3. Write

If you take one action after reading this article, it should be to write and share a document at work.

Writing standards docs. By writing a resource about accessibility guidelines and common patterns, I helped indirectly increase how accessible our application was, not just in my department but company-wide. So few engineers are willing to take the time to write quality documentation, policy, and standards. Being the one to do it is a superpower.

Building trust & strengthening relationships

Competence is essential, but it isn’t the whole game. Many developers are good at writing code but only good at writing code. They don’t understand why they are limited in their career. Software is a team sport4. You have to build trust with others.

Building trust takes time—one person at a time, one conversation after another. The only way to build a cathedral is brick by brick.

Be honest, even in shortcomings, especially in your shortcomings. Managers hate surprises. If you’re going to miss a deadline, let them know upfront. The sooner, the better.

Getting along with people isn’t required, but it sure helps. Pedro Pascal sums up the attitude nicely:

“I know how to get along with everybody but it doesn’t mean I like everybody.” — (source, X fka Twitter5)

Take a human interest in people. Know the name of every dog, cat, and child your coworkers are responsible for.

Be genuinely likable. I’m pretty mid at coding. Most of my career success comes from being charismatic and funny. If people don’t like working with you, you’ll be included in fewer conversations. Thus, fewer relationships, therefore less power. Few of us are truly “changing the world” and could afford to be more playful at work.

Wielding influence

You’ll have opportunities to use your influence as you become more trusted. Start small. 1-on-1 conversations over big pitches.

Favor asking good questions over offering specific advice. As Micheal Bungay Stringer says in The Coaching Habit: Tell less and ask more. Your advice is not as good as you think it is. Questions are more valuable than many realize.

Pick your battles. You can’t win everything.

Share your influence generously. You can help others gain influence. You can give a voice to the voiceless. You can shine a light on people that deserve it.

And remember to use this influence for good. It gives you a unique opportunity to help your company, customers, and coworkers.

And y’know, make your product better and get a raise and a promotion. You don’t have to do all this for free ;)

Are you a developer contributing to customer satisfaction and business goals, or are you someone who costs money and causes problems?

Most managers hate working with most devs because they are the latter. Here’s a quick test to see if this is you:

• When you’re working, are you focused solely on closing out tickets?

• Do you stay silent when the designer pushes for a design that will take three times as long to build as a more straightforward solution? After all, it’s his job to make these decisions, not yours, right?

• Do you push to be part of projects at work that drive the most business value? Do you know what those projects are?

• Do you ever find yourself pushing for rewrites, refactors, or new technical solutions that don’t solve a problem you have today but might in the future?

If you answered ‘yes’ to any of these, you might be a developer who could benefit from focusing on product thinking.

No one likes using crappy software, and no one likes building it. But look around. Mediocre tech abounds. How does this happen? There are many factors, but if you’re a developer, you can only control your input in your part of the process. That input isn’t just code, but it’s how you communicate with teammates, managers, and product owners. Doing these effectively requires product thinking skills.

What is product thinking?

“Product thinking”’s definition is nebulous. Putting it into practice is inscrutable, yet it’s a fundamental building block of being a higher-level software developer.

“product thinking” is the art and science of balancing business strategy, customer experience, and engineering robustness. It’s about thinking about software from the perspective of how it behaves instead of how it works.

Another way of thinking about it is balancing the user's needs with the business's capabilities.

Feature-driven vs. product-driven development

The opposite of product-driven development is feature-driven development. This might sound weird at first. What is a product if not a collection of features? But there is a world of difference focusing on the collective rather than individual features. One sees the forest; one can’t see from the trees.

Feature-driven developers are:

1. Tech-centric

2. Solution-focused

3. Narrow-minded

4. Disconnected from stakeholders

5. Siloed

6. Focused on inputs

7. Robotic

Product-driven developers are:

1. User-centric

2. Problem-focused

3. Holistic

4. Aligned with business goals

5. Cross-functional

6. Focused on outputs

7. Empathetic

Feature-driven developers close tickets, fix bugs, and ship features. Product-centric developers solve problems, deliver value, and help people.

The only way we’ll improve software is to move more software engineers from the left side of the graph to the right. The reason I suspect engineers struggle with this is two-fold:

1. Product thinking is more abstract. The lack of ambiguity is the flame that draws a lot of engineers into the craft.

2. It’s a tacit skill - there is no leetcode for product thinking. It’s more of a way of thinking about your work than something you can practice deliberately.

Good product thinking requires developing your product intuition.

But can intuition be developed? People talk about trusting their gut, but don’t talk about how to train said gut to make better decisions. It turns out you can, and one psychologist figured out how:

How intuition works

Delving further into tacit skills, we can use Gary Klien’s Recognition-primed decision-making model, which describes how people make decisions in complex situations, to further examine what’s going on in a product thinker’s mind when building:

1. Developing expectancies - Using hindsight to figure out how the codebase got to this state and forecasting where it might go in the future.

2. Spotting relevant cues - Determining which information you should pay attention to and which you can ignore.

3. Prioritizing & Triage - Deciding what work needs to be done now, and what you can set aside.

4. Apply or create scripts - The mind seeks established patterns to follow in familiar situations. For novel scenarios, it develops new approaches.

Here’s a more in-depth look at the model1:

Like a language model, you can train your intuition for better results. You can use three tools: heuristics, patterns, and application.

1 - Heuristics

A heuristic is a practical rule of thumb or mental shortcut that helps you make decisions or solve problems quickly. They are more guidelines than a rigorous formula. They are generally but not always accurate. Some examples: “Keep code DRY: don’t repeat yourself,” “Premature optimization is the root of all evil,” and “If you have to explain a joke, it’s not funny.”

The gold standard: Nielsen’s Heuristics for User Interface Design

If you read only one other article on Heuristics, it should be 10 Usability Heuristics for User Interface Design from the Neilsen Norman Group, a research-based user experience consultancy. Putting these into practice will put you ahead of 90% of other engineers. A summary:

1. Status visibility: The product should always keep users informed about what is going on

2. Familiarity: The design should speak the users' language and follow real-world conventions.

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

4. Consistency: Words, actions, and other affordances should have consistent meaning

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

6. Recognition over recall: The machine is the user’s memory, not the other way around

7. Simple & powerful: products should be plainly simple enough for novices and subtly powerful for experts

8. Focus: Interfaces should contain the information needed and nothing more

9. Error recovery: Error messages should provide a solution

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

Other useful heuristics

There’s a handful of other adages out there that can serve as heuristics. Here is a collection of the ones I’ve found most helpful:

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

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

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

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

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

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

7. Teslers's Law - Demonstrates that a system's complexity cannot be simplified beyond its condition to function. Simple interfaces require complex code.

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

9. The Doherty Threshold - People's attention and productivity increase when the interaction response is within 400 milliseconds.

10. Sturgeon’s Law - 90% of everything is crap2

When building expertise and intuition, first, you learn the rules. Then, you learn which rule to apply and when. Then, you learn when there are exceptions to the rules. Then, you know how to break them.

2 - Patterns

While heuristics give you rules, patterns give you tactics. The more patterns you’re familiar with, the easier it is to devise a plan of action in different contexts. Patterns will even teach you tactics when you don’t realize it.

Studies have shown that we can learn to discriminate different objects and automatically form categorizations from exposure to instances of things. 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 came to that conclusion.

Look for similar problems

Whatever problem you’re working on, chances are you aren’t the first person to face it. How have other people solved similar issues in the past? For example, you must build a form to capture a user’s address. Plenty of people have done this before, and if you look, you can find common patterns3

• Using an autocomplete powered by Google Maps to fill in the address for you

• Calling them ‘postal code’ instead of ‘zip code’ if you are supporting non-US customers

• Using input masks or placeholders to show people the format you expect for postal codes and, if you’re collecting them, phone numbers.

You may also check yourself to ensure you don’t believe one of the many falsehoods programmers believe about addresses.

I’m not saying implement these patterns verbatim, though you might. What I am suggesting is looking for similar solutions for inspiration. As a bonus, these can be easier to pitch to stakeholders. No one gets fired for copying Apple.

Search your memory banks for previous patterns

You might remember seeing a product solution either as an implementer or a consumer. For example, when I got a job at a financial services company, I had never worked in that industry before, but I paid a credit card online. I can relate to the customer’s expectations, needs, and frustrations.

This is what starts to happen subconsciously more and more as you practice. Let’s look at Klien’s decision-making model again:

1. When you look at a problem, you form expectations of the effect of different solutions based on previous patterns.

2. Also, based on previous patterns, you get a sense of what’s essential and what isn’t.

3. You understand what a reasonable outcome is, which helps you pick your next course of action.

4. You may recognize previous courses of action, which helps you triage and prioritize.

With existing work, you only get to see the outcome. Looking at your previous work, you see both the outcome and the process. Similarly, we can also study others' methods.

Learn patterns from case studies and observing others

One good thing about engineers is that they love to blog. Another way you can improve your expertise is by reading stories of how other people solved problems. Watching videos of people's work is a less explored but powerful way to improve your skills.

I once heard a story about someone who was learning to draw. They read books; they drew dozens of pictures to practice. Then they watched another artist on YouTube, and within minutes, they had a breakthrough:

They weren’t holding the pencil correctly.

None of the books taught him how to hold a pencil. It’s an oft-ignored detail of the drawing process. Watching others in action can teach you some of the ‘hold to hold the pencil’ type of tiny details that can make a big difference in your problem-solving. Some reading I would recommend for some case studies on solving technical problems:

• Creative Selection: Inside Apple's Design Process During the Golden Age of Steve Jobs

• The Mythical Man-Month: Essays on Software Engineering

• Ryan Singer shares a lot about his process on his blog Felt Presence

Pattern identification as background process

You don’t have to look for a particular pattern to notice a potentially useful one. Try to pay more attention to times when a product or a piece of code makes you say, “Wow! That’s quality.” Ask yourself what you like about it. What makes it quality?

As prolific blogger and poster Visakan Veerasamy likes to say, focus on what you want to see more of. The more you pay attention to quality software, the more quality software you’ll build.

3 - Practice

It’s been theory so far: how intuition works and how you can supplement it with heuristics and train it with patterns. But none of this is helpful if you can’t put it into practice. Here are some actionable next steps:

Look through a product-focused lens

If you’re coding every day, you are faced with small decisions about product quality. Everything we create is a product, even if it isn’t customer-facing. Some other ‘products’ of your work

• Your code is a product for other engineers on your team. The UX of code is experienced when other developers have to modify or fix it.

• Bug tickets, pull requests, and code reviews are also products for your teammates.

• Status reports, tech specs, and other documentation about your work are products for managers and stakeholders.

Books are products. Podcasts are products. A cookout you throw for your friends is a product.

Try to shift your perspective from “how it works” to “what it achieves.” Think about how others feel and react when interacting with your work.

Ask yourself questions to hack your brain

When Klein developed the Recognition-primed decision-making model, he realized he could get people to surface some of their intuition into cognitive thought by interviewing them while they were working.

He would ask subjects questions like:

1. What cues did you notice first?

2. In this particular situation, what did you expect to happen next?

3. What are your priorities right now?

4. What courses of action immediately sprang to mind?

Try this exercise on yourself. It can help you examine and better understand your problem-solving process.

Pair with designers & stakeholders

Ask your designers or product owners if there are any meetings where you can be a fly on the wall. You’ll pick up tacit knowledge by watching other people think though and discuss problems. Another opportunity to see how others “hold the pencil.”

Ask questions and provide constructive ideas. Contribute, but don’t interfere. This will give you feedback on your product thinking.

Make microdesign decisions

Rarely does a design or tech spec come through with every edge case and permutation covered. Filling in these gaps is up to the engineer who is implementing them. I call these microdesign decisions.

One model you can use to help identify these is the rules UI Stack. The UI Stack is a concept from founder & designer Scott Hruff. In his model, each interface has 5 “personalities:” Blank, Loading, Partial, Error, and Ideal.

These are common blind spots. For pages representing collections of data, I also include a sixth “full” state. Imagine if your list had 10x the number of entries you would consider normal. What does it look like? Can it load quickly? Does it still function?

Wrapping up

Being more product-focused, in my opinion, leads to a more fulfilling programming career. On average, you’ll build better things, be more proud of your work, and get along better with your designers, managers, and stakeholders. However, where programming is logical and well-defined, “building a better product” is a more obtuse skill and requires a different approach to improvement. The three primary ways we examined were:

1. Heuristics - rules of thumb you can use to help you think differently and make better decisions. I think Heuristics is a smart default — they will serve you well 70% of the time, and when they don’t, that tells you something, too.

2. Patterns - raising your awareness of quality design, seeking it out, and internalizing what makes it quality.

3. Practice - Finding small ways to practice your product thinking in the real world. Questions, comments, and conversations are valuable, even if they don’t impact the final product.

We’ve all used software that felt thoughtless. Irritating software. Software that makes you do something manually that a computer could have done in a microsecond. It might just feel “off,” but you can’t put your finger on why.

Silicon Valley types love to talk about “changing the world.” but that cuts both ways—annoyance scales like value. Careless software makes the world just a little bit worse for everyone who uses it.

You have a responsibility to the people who use what you build.

As a software engineer, you are the last line of defense when it comes to stopping bad software from getting out in the world.

Every little thing you can do to make it better helps.