Author Archive

Measuring emotion

One of the most important responsibilities for managers in tech companies are having regular one-on-ones with their team. The idea is to meet with each member of the team once every week or two, face-to-face, to talk about whatever the team member wants. And the face-to-face part is crucial. Our brains process an immense amount of information during a conversation — eye contact, facial expressions, intonation, body language — everything that’s beyond the content of our words (what an email might convey). This information trains our intuitive reasoning, building understanding and perspective — allowing us to better understand what the other person means when they say something.

Yet there is an entire class of managers in software today that avoid face to face interaction with those they manage: product managers. It’s common for a product manager to be running multiple experiments every week, but how common is it for a product manager to spend face time with multiple customers every week? Why is that?

The vibe I get from our industry today is that product managers believe measurable data and analytical reasoning are king and result in superior decisions. Many even believe with enough effort, they can measure emotion. They see emotions in their analytical world view: as a (difficult) metric to be measured, tested, and improved. This is how we end up associating ideas like Churn (an artifact of your billing data) with an emotion like Frustration (something a human feels). But emotion can’t be measured, it must be felt.


I recently listened to a great Planet Money episode on Spreadsheets! that discusses the history of spreadsheets and how it’s changed the way we make decisions. The episode was inspired after an article written in 1984 about the significance and danger of the advance of spreadsheets:

The spreadsheet is a tool, and it is also a world view — reality by the numbers.

— Steven Levy on A Spreadsheet Way of Knowledge

Many of us don’t use spreadsheets today, but we do use tools that came from spreadsheets and promote the same world view. We compare competing Facebook events by the number of RSVPs hoping to optimize our party enjoyment. We sort by rating on Amazon hoping to optimize our dollar. We scour Yelp and Foursquare to optimize the enjoyment of our meals. And product managers crunch numbers and run experiments to optimize their product decisions.

Take a minute to think about how the spreadsheet has changed your life. How often do you make a decision without researching how to optimize something?

This is not to say we shouldn’t use “spreadsheets” to optimize our decisions. We often do make better decisions through data analysis. Rather, what I think is interesting is just how significant our bias toward analytical reasoning has become. Our hammer is the spreadsheet, and now we’re making everything in product management a nail.


I’ve long been a believer that your environment significantly shapes the type of products you can build. Have nothing in your houses that you do not know to be useful, or believe to be beautiful. When you’re building software, your environment is primarily made up of the tools and processes you use. And when I look at the processes that dominate our industry today — Agile/XP, Lean, Data-Driven — they have a common trait. They assume a lack of emotion — an overriding rationality of our customers.

Think about Agile/XP User Stories. The original purpose of a User Story was to produce an estimate for work. But the unintended consequence is that User Stories have become a popular tool for product managers who believe they are communicating the perspective of customers. Why describe functionality when you can communicate what the customer wants?

An example User Story

But this is reality only by the numbers. I guarantee you that no one wants to purchase a parking pass. Many people want a parking pass, but no one wants to purchase it. This Story is useful as a feature requirement, but in no way does it communicate the perspective of the user. What would happen if we actually tried to communicate the perspective of a user?

Christine just got her second parking ticket this week. She walks up to her car and screams this is fucking bullshit! She admits to herself that she really does need to spend her Apple Watch money on a parking pass. Bullshit! She’s already dreading the lecture from her mother once she gets a copy of this ticket in the mail. But, she has to admit that she’s looking forward to the relief of parking without worrying about tickets. Still. No watch. Blergh.

Can you feel her anger and frustration? How does a User Story communicate this? It doesn’t. It assumes Christine is a golden child, birthed of pure rationality and light who simply does not drive to school without a parking pass.

What advantage does the User Story have if it is not communicating customer perspective? What value do we gain by saying As a student I want to purchase a parking pass so that I can drive to school over something more straightforward like Students can purchase a parking pass. We’ve gotten too analytical with our tools. We’ve bulldozed emotion without realizing what we were doing.

How might you change your design if your tools promoted an emotional understanding of Christine’s perspective? What if immediate purchase included a discount or forgiveness for the ticket itself? You might just end up with happier students and more parking passes sold.


Unfortunately, things get sticky when we leave our numbers behind. We’re not practiced at feeling emotion in a professional environment. We associate emotions with irrationality and poor decisions — something to be avoided. As an organization approaches Dunbar’s number, being vulnerable and feeling emotion becomes less and less safe. Our customers continue to feel and be swayed by emotion just like the rest of us while we’re busy building a world in where we don’t have to feel.

It’s time we revisited our tools with a focus on promoting emotional understanding. Our customers deserve it. And frankly, we’ve been fucking up their lives with our lack of empathy. I don’t have the complete answer, but I do have some suggestions.

  • Jobs to be Done
    JTBD is my favorite software design tool of the past five years. But my favorite part is that it forces you to acknowledge the emotional aspect of why people use or don’t use your product.

  • Regular one-on-ones with customers
    Spend time with your customers where it’s all about them — without survey questions or a predefined conversation structure. You might even make a new friend.

  • Customer stories
    One thing Chrissie did while she was creating GitHub’s User Research department was to include stories of individual customers in all of our UXR studies. In the midst of data spanning thousands of customers and millions of records, there’d be a story about Alice’s feelings. This is what Alice thinks Pull Requests are. This is how she explains them with a crayon and a piece of paper. Stories about individuals carry tremendous power over our emotions. Think about how we are drawn to the characters in novels and TV shows.

  • Use all of your product
    Do you pay for your own product? Do you register for a new account on a regular basis? Do you use every screen, even if you don’t have a reason to? How often do you modify your account settings? You might be surprised at how much better you understand those snarky tweets if you set aside time to use your product for tasks you have no need to accomplish.

  • Train your intuition
    Don’t be bullied into the world view that every decision must be proven with data. Fed by enough meaningful experience, our intuitive reasoning is extremely powerful. Train your intuition, and learn how to communicate intuitive reasoning.


If we want to build better products, we must learn to include emotional understanding into our product decisions without resorting to analytical reasoning. Emotions must be felt.


Measuring emotion

One of the most important responsibilities for managers in tech companies are having regular one-on-ones with their team. The idea is to meet with each member of the team once every week or two, face-to-face, to talk about whatever the team member wants. And the face-to-face part is crucial. Our brains process an immense amount of information during a conversation — eye contact, facial expressions, intonation, body language — everything that’s beyond the content of our words (what an email might convey). This information trains our intuitive reasoning, building understanding and perspective — allowing us to better understand what the other person means when they say something.

Yet there is an entire class of managers in software today that avoid face to face interaction with those they manage: product managers. It’s common for a product manager to be running multiple experiments every week, but how common is it for a product manager to spend face time with multiple customers every week? Why is that?

The vibe I get from our industry today is that product managers believe measurable data and analytical reasoning are king and result in superior decisions. Many even believe with enough effort, they can measure emotion. They see emotions in their analytical world view: as a (difficult) metric to be measured, tested, and improved. This is how we end up associating ideas like Churn (an artifact of your billing data) with an emotion like Frustration (something a human feels). But emotion can’t be measured, it must be felt.


I recently listened to a great Planet Money episode on Spreadsheets! that discusses the history of spreadsheets and how it’s changed the way we make decisions. The episode was inspired after an article written in 1984 about the significance and danger of the advance of spreadsheets:

The spreadsheet is a tool, and it is also a world view — reality by the numbers.

— Steven Levy on A Spreadsheet Way of Knowledge

Many of us don’t use spreadsheets today, but we do use tools that came from spreadsheets and promote the same world view. We compare competing Facebook events by the number of RSVPs hoping to optimize our party enjoyment. We sort by rating on Amazon hoping to optimize our dollar. We scour Yelp and Foursquare to optimize the enjoyment of our meals. And product managers crunch numbers and run experiments to optimize their product decisions.

Take a minute to think about how the spreadsheet has changed your life. How often do you make a decision without researching how to optimize something?

This is not to say we shouldn’t use “spreadsheets” to optimize our decisions. We often do make better decisions through data analysis. Rather, what I think is interesting is just how significant our bias toward analytical reasoning has become. Our hammer is the spreadsheet, and now we’re making everything in product management a nail.


I’ve long been a believer that your environment significantly shapes the type of products you can build. Have nothing in your houses that you do not know to be useful, or believe to be beautiful. When you’re building software, your environment is primarily made up of the tools and processes you use. And when I look at the processes that dominate our industry today — Agile/XP, Lean, Data-Driven — they have a common trait. They assume a lack of emotion — an overriding rationality of our customers.

Think about Agile/XP User Stories. The original purpose of a User Story was to produce an estimate for work. But the unintended consequence is that User Stories have become a popular tool for product managers who believe they are communicating the perspective of customers. Why describe functionality when you can communicate what the customer wants?

An example User Story

But this is reality only by the numbers. I guarantee you that no one wants to purchase a parking pass. Many people want a parking pass, but no one wants to purchase it. This Story is useful as a feature requirement, but in no way does it communicate the perspective of the user. What would happen if we actually tried to communicate the perspective of a user?

Christine just got her second parking ticket this week. She walks up to her car and screams this is fucking bullshit! She admits to herself that she really does need to spend her Apple Watch money on a parking pass. Bullshit! She’s already dreading the lecture from her mother once she gets a copy of this ticket in the mail. But, she has to admit that she’s looking forward to the relief of parking without worrying about tickets. Still. No watch. Blergh.

Can you feel her anger and frustration? How does a User Story communicate this? It doesn’t. It assumes Christine is a golden child, birthed of pure rationality and light who simply does not drive to school without a parking pass.

What advantage does the User Story have if it is not communicating customer perspective? What value do we gain by saying As a student I want to purchase a parking pass so that I can drive to school over something more straightforward like Students can purchase a parking pass. We’ve gotten too analytical with our tools. We’ve bulldozed emotion without realizing what we were doing.

How might you change your design if your tools promoted an emotional understanding of Christine’s perspective? What if immediate purchase included a discount or forgiveness for the ticket itself? You might just end up with happier students and more parking passes sold.


Unfortunately, things get sticky when we leave our numbers behind. We’re not practiced at feeling emotion in a professional environment. We associate emotions with irrationality and poor decisions — something to be avoided. As an organization approaches Dunbar’s number, being vulnerable and feeling emotion becomes less and less safe. Our customers continue to feel and be swayed by emotion just like the rest of us while we’re busy building a world in where we don’t have to feel.

It’s time we revisited our tools with a focus on promoting emotional understanding. Our customers deserve it. And frankly, we’ve been fucking up their lives with our lack of empathy. I don’t have the complete answer, but I do have some suggestions.

  • Jobs to be Done
    JTBD is my favorite software design tool of the past five years. But my favorite part is that it forces you to acknowledge the emotional aspect of why people use or don’t use your product.

  • Regular one-on-ones with customers
    Spend time with your customers where it’s all about them — without survey questions or a predefined conversation structure. You might even make a new friend.

  • Customer stories
    One thing Chrissie did while she was creating GitHub’s User Research department was to include stories of individual customers in all of our UXR studies. In the midst of data spanning thousands of customers and millions of records, there’d be a story about Alice’s feelings. This is what Alice thinks Pull Requests are. This is how she explains them with a crayon and a piece of paper. Stories about individuals carry tremendous power over our emotions. Think about how we are drawn to the characters in novels and TV shows.

  • Use all of your product
    Do you pay for your own product? Do you register for a new account on a regular basis? Do you use every screen, even if you don’t have a reason to? How often do you modify your account settings? You might be surprised at how much better you understand those snarky tweets if you set aside time to use your product for tasks you have no need to accomplish.

  • Train your intuition
    Don’t be bullied into the world view that every decision must be proven with data. Fed by enough meaningful experience, our intuitive reasoning is extremely powerful. Train your intuition, and learn how to communicate intuitive reasoning.


If we want to build better products, we must learn to include emotional understanding into our product decisions without resorting to analytical reasoning. Emotions must be felt.


Pixels don’t care

I’m short.

When I was 20, I decided to try and make some extra money building websites for people to pay for my tuition. My work was good. It wasn’t phenomenal, but it was good. It was impossible for me to get work. Everything would be great until I met with a potential client. At which point they told me they’d rather hire a professional.

What they meant is that I looked too young. I didn’t really realize this was the problem until people started screwing me out of money. “You’re just a kid and you’ll get over it� I believe was the phrase my last client used to fuck me over.

Humans are really good at prejudice and intolerance.


The internet was a much different place eight years ago. Facebook wasn’t open to the public. Twitter didn’t exist. Google did not require legal names. I was just kneath who had a blog at warpspire.com. I didn’t have a picture and no one knew my age.

And the internet loved my work. I still remember the first day my blog was featured on CSSVault — it was one of the most exciting things to ever happen to me. How awesome was it that my work was highlighted as one of the best in the world? (CSSVault was quite a different beast 8 years ago too).

A few days later I received an email from the Art Director of a local agency asking to come in and meet their team. And so it was that I was interviewing for a job to work on sites for the likes of Apple, Disney, HP, and RIM. Pretty fucking crazy. It felt good — it felt like validation that my work was worth paying for.

I remember the last question asked of me at the interview, because it was possibly the most terrifying professional moment of my life. To paraphrase:

You have no formal eduction, no experience with any big clients, what makes you think you could possibly be good enough to work here?

Through a stroke of luck, a moment of wit came upon me and I replied with the only thing my brain could grasp on:

I have no idea. I didn’t even know I was interviewing, Kris sent me an email asking me to come in today because he thought my work was good. Is it?

I never really got an answer. But I did get the job. Because my work was good. But I was given a much lower salary than my co-workers. For every hour I worked, the agency billed my time out at a 2,083% markup. To the client (who couldn’t see my height), my time was worth over 20x the amount I was worth to the agency.

Looking back, I can’t help but think this was discrimination. For age, for height, for whatever you will. I had no lower education than my peers, equal or better skills, and did work of the highest quality.

The physical world is harsh. I’m by all means a member of the privileged class in America by race, gender, and sexual orientation — yet a few inches of vertical height is all it took to diminish the value of my work.

At least they paid me.


About the same time, I started to get into Ruby on Rails. I wasn’t really the most brilliant programmer or designer, but I could get stuff done. I was invited to hang out in the #caboose IRC channel. There aren’t any avatars in IRC. No faces. No names. Just usernames and words.

I ended up making a lot of friends through caboose. Friends I still have today. Friends I’ve worked with, friends I haven’t worked with. Friends who never saw my face or knew my age for almost half a decade. It just wasn’t important.

We were working on code, on Photoshop documents — pixels. The pixels didn’t care what we looked like. Over time we grew to respect each other. Not because of how handsome we were, but because of the things we built.

In a strange sense, it was a bit of a utopian work environment. How could the internet know you were gay? 80 years old? Hispanic? Transgender? Karl Rove? It just didn’t matter. Respect was earned through actions and the words you actually said (hard to squeeze rumor out of publicly logged chat).

It took me until early 2009 for me to realize the real value of this network. I was miserable at my job and I sent a long-winded email to court3nay inquiring about working with ENTP. ENTP was a half-product, half-consulting agency at this point comprised almost solely of caboosers. All of whom had never met me or ever heard my voice. About 30 seconds later I got a response:

Hey Kyle,

That’s pretty fuckin awesome, if you’ll pardon my french.

We’re just heading out to breakfast, I mean, an important company meeting, but I’ll get back to you today.

Courtenay & Rick

And then a follow up:

OK, I’ve talked it over with everyone (unanimous— “kyle? awesome!”)
I think you’ll fit into our team perfectly.

No in person interview. No phone calls. No technical test. They were confident enough in my pixels to give me what equated to my dream job at that point in my life.

Really fucking crazy.


This industry we work in is magical. For the first time in human history, it’s possible to be represented (almost) solely through the merits of your work. Build something magical, push it up to GitHub under a pseudonym, and you could become one of the most sought after programmers in the world.

That’s really fucking awesome.

There’s plenty of prejudice and intolerance in our world — and in our industry. But never forget that pixels don’t care.


Pixels don’t care

I’m short.

When I was 20, I decided to try and make some extra money building websites for people to pay for my tuition. My work was good. It wasn’t phenomenal, but it was good. It was impossible for me to get work. Everything would be great until I met with a potential client. At which point they told me they’d rather hire a professional.

What they meant is that I looked too young. I didn’t really realize this was the problem until people started screwing me out of money. “You’re just a kid and you’ll get over it� I believe was the phrase my last client used to fuck me over.

Humans are really good at prejudice and intolerance.


The internet was a much different place eight years ago. Facebook wasn’t open to the public. Twitter didn’t exist. Google did not require legal names. I was just kneath who had a blog at warpspire.com. I didn’t have a picture and no one knew my age.

And the internet loved my work. I still remember the first day my blog was featured on CSSVault — it was one of the most exciting things to ever happen to me. How awesome was it that my work was highlighted as one of the best in the world? (CSSVault was quite a different beast 8 years ago too).

A few days later I received an email from the Art Director of a local agency asking to come in and meet their team. And so it was that I was interviewing for a job to work on sites for the likes of Apple, Disney, HP, and RIM. Pretty fucking crazy. It felt good — it felt like validation that my work was worth paying for.

I remember the last question asked of me at the interview, because it was possibly the most terrifying professional moment of my life. To paraphrase:

You have no formal eduction, no experience with any big clients, what makes you think you could possibly be good enough to work here?

Through a stroke of luck, a moment of wit came upon me and I replied with the only thing my brain could grasp on:

I have no idea. I didn’t even know I was interviewing, Kris sent me an email asking me to come in today because he thought my work was good. Is it?

I never really got an answer. But I did get the job. Because my work was good. But I was given a much lower salary than my co-workers. For every hour I worked, the agency billed my time out at a 2,083% markup. To the client (who couldn’t see my height), my time was worth over 20x the amount I was worth to the agency.

Looking back, I can’t help but think this was discrimination. For age, for height, for whatever you will. I had no lower education than my peers, equal or better skills, and did work of the highest quality.

The physical world is harsh. I’m by all means a member of the privileged class in America by race, gender, and sexual orientation — yet a few inches of vertical height is all it took to diminish the value of my work.

At least they paid me.


About the same time, I started to get into Ruby on Rails. I wasn’t really the most brilliant programmer or designer, but I could get stuff done. I was invited to hang out in the #caboose IRC channel. There aren’t any avatars in IRC. No faces. No names. Just usernames and words.

I ended up making a lot of friends through caboose. Friends I still have today. Friends I’ve worked with, friends I haven’t worked with. Friends who never saw my face or knew my age for almost half a decade. It just wasn’t important.

We were working on code, on Photoshop documents — pixels. The pixels didn’t care what we looked like. Over time we grew to respect each other. Not because of how handsome we were, but because of the things we built.

In a strange sense, it was a bit of a utopian work environment. How could the internet know you were gay? 80 years old? Hispanic? Transgender? Karl Rove? It just didn’t matter. Respect was earned through actions and the words you actually said (hard to squeeze rumor out of publicly logged chat).

It took me until early 2009 for me to realize the real value of this network. I was miserable at my job and I sent a long-winded email to court3nay inquiring about working with ENTP. ENTP was a half-product, half-consulting agency at this point comprised almost solely of caboosers. All of whom had never met me or ever heard my voice. About 30 seconds later I got a response:

Hey Kyle,

That’s pretty fuckin awesome, if you’ll pardon my french.

We’re just heading out to breakfast, I mean, an important company meeting, but I’ll get back to you today.

Courtenay & Rick

And then a follow up:

OK, I’ve talked it over with everyone (unanimous— “kyle? awesome!”)
I think you’ll fit into our team perfectly.

No in person interview. No phone calls. No technical test. They were confident enough in my pixels to give me what equated to my dream job at that point in my life.

Really fucking crazy.


This industry we work in is magical. For the first time in human history, it’s possible to be represented (almost) solely through the merits of your work. Build something magical, push it up to GitHub under a pseudonym, and you could become one of the most sought after programmers in the world.

That’s really fucking awesome.

There’s plenty of prejudice and intolerance in our world — and in our industry. But never forget that pixels don’t care.


Patent reasoning

Software patents are incredibly difficult to enforce.

As software becomes more complex, patents become more difficult to decipher. Only expert software engineers can truly understand the intended meaning of modern software patents.

As the total number of software patents increase over time, legislation and litigation of software patents become more complex. Only expert lawyers can successfully litigate patents.

Very few expert lawyers are also expert software engineers.

Big Software vs small software

It’s generally understood that the benefit of software patents is to ensure mutually assured destruction amongst competitors. If a competitor sues you over a patent, you countersue with your own patents.

The majority of software companies are small compared to Big Software — companies like IBM, Google, and Apple. Small software competes directly with Big Software.

In a race for patents, it is impossible for a small software company to catch up to the breadth of patents of a Big Software company. Big Software have large patent portfolios and can continue to create patents at the same (or faster) rate than small software.

It is not feasible for a small software company to generate a more effective patent portfolio than a Big Software company.

Patent trolls

Patent portfolios are known to be ineffective against patent trolls. Patent trolls are small companies or individuals who own very few unused patents (often one) and sue companies hoping for a large payout.

Mutually assured destruction does not apply since the individual has nothing to lose.

Lawyers

Lawyers make a lot of money off patents.

They make money advising companies on patents. They make money creating them. They make money legislating them. They make money litigating them. Lawyers win on both sides during patent disputes.

It costs software companies time and money to create and manage patents. Time and money not spent on products.

There isn’t a single downside to patents from a lawyer’s perspective. They create a dependency system that benefits lawyers.

An obvious conclusion

I’ve yet to see a single argument that software patents benefit small software companies in any way.

The US Patent Office is holding a series of round table discussions about software patents. I encourage you to participate.


  •   
  • Copyright © 1996-2010 BlogmyQuery - BMQ. All rights reserved.
    iDream theme by Templates Next | Powered by WordPress