Every Situation Is Different When It Involves People

»» Sign up for the next #DesignInTech briefing.

Takeaway notes from this article with annotations.

“Every company is very different. It’s important to keep in mind that not everything that works in one business will work in another.” —Steve Huffman (Reddit)

Every person is different. Every situation is different. Yes, there are similarities. But we live in a complex, chaotic world. So it’s always going to be unpredictable and different. The “one big idea” you takeaway from that HBR post that’s nailed your entirely managerial view for the rest of life is probably only good for 1 or 2 times in your life. At best.

“The other thing we did that was very valuable was talking to people on other platforms. If they deliberately chose not to use your product and chose another, then they have a specific opinion about why they didn’t choose your platform, so you know what to work on.” —Emmett Shear (Twitch)

To think of your competition as an opportunity to learn about the people who use the product, versus the competitive aspects of the product, is wise.

“There are a lot of corners you can cut when you’re building your MVP, but lack of data can haunt you. Think very carefully about what the minimum viable data is.” —Steve Huffman (Reddit)

Invest early and plant seeds of understanding that you can come back to and analyze in the future (I blog for that reason 🙂 ). If you don’t plant those seeds early enough, you won’t be able to learn anything after you’ve already been running at light speed. And then by that time, you’ll fail because you don’t have even a rudimentary GPS to tell you where you are in the galaxy.

“I don’t want to argue about it if we can just test it. If it’s not in my top three things to worry about for the day, then there’s not reason to bother. This, however, is easier if you have more resources.” —Steve Huffman (Reddit)

If we had all the time in the world, we’d analyze things really well. But we don’t if we’re fighting against time. But if we don’t observe basic hygiene around having the ability to test our assumptions and break our own biases, then we just end up in bias debt.

“If you find yourself in the situation of ‘oh I’m going to go talk to my users to validate my product idea,’ then you’ve gone horribly off the rails. You do it the other way around. You don’t talk to your users to validate your product idea; you talk to them to get your product idea.

If you haven’t talked to users and you haven’t looked at data, you don’t get to have an opinion about what your building.

Once everyone has actually looked at the data and actually talked to users it’s pretty rare to find a disagreement. I find it better if you just have one person in charge. You can argue your opinion but having someone in charge helps you move faster. Decision making is far too slow in a startup.” ——Emmett Shear (Twitch)

Users aren’t the kind of data-objects that we might think of as “to be surveyed” — they’re a valuable partner in the process of improving a product. When they’re partners, then they’re on the team. We want them on the team. And in many cases, they’re more important to have on your team than your actual team members themselves.

“The goal of talking to users is not to get them to tell you what features to build. Users are really bad at that. They have no idea what features to build. The goal of talking to users is to get to understand them really well.” —Emmett Shear (Twitch)

These days I think of how to understand people’s emotional states in relation to the other people they are with (versus their emotional reaction to the actual system itself). By being social animals, we care what the other person thinks.

The best product ideas are the ones that your users are doing anyways, and you just grease it a little bit.” —Steve Huffman (Reddit)

We tend to focus on our weaknesses with an engineering mindset (because failure can be life threatening), but when it comes to great experiences, we need to design for our successes.

Image note: From my People Counter hack in 2005