Well-designed How to Use Empathy to Create Products People Love

Companies exist on a spectrum… You need to come to terms with the type of organization you want to be, and one isn't better than the other. But the people need to be onboard with the kind of company you are, because otherwise you are swimming upstream.

It’s not about making your idea happen. It's about helping the best idea happen.

Before you begin development efforts, help your engineering team understand what determines the success of a given effort. What behavior will you track? How will you track that behavior? And what goals do you have for that metric to indicate if it's working as desired?

You can short-circuit endless debates over features, functions, and design details by making things. The thing can be a diagram, a sketch, or a high-level fidelity design artifact. When you make a thing, an idea becomes real.

Why code that doesn't function properly should be fixed is obvious. It's not always evident why poorly aligned images are worth fixing, particularly with limited development resources. You need to explain how consistency, visual acuity, and polish have an impact on trust, and how trust is critical to the product's success.

Joe takes the average of this number across all users, adjusted for how long the user has been a member of the site, and tracks it in aggregate. He then has a single figure indicating the global wellness of his community of users. If the product is helping people feel more in control of their bodies, that number should go up over time.

They aren't bringing me simple solutions that are on the early side of complexity; they bring me simple solutions that are the results of late nights of analysis.

Good product managers are not overly dramatic about their successes or failures. They say, "OK, we did that, it worked, it didn't work." There's a fine line of acknowledging that things didn't work and not dwelling on and defending the choices you made, so you don't look as bad as you really look. Just accept it and move on.

That's what good product managers do. They find opportunities and marshal the resources necessary to make them successful.

Try the A-B-C-Q approach to variation. This is the idea of creating several expected variants, changing minor details (A leads to B, B leads to C), and then creating a wild or surprising jump (Q).

Don't worry about being exciting. Instead, ask a lot of questions. Be interested, not interesting.

You need to give people discrete options, instead of infinite options. Restraint is important as a product manager.

Ponder the calendar idea, the group idea, the magazines, and the devices, and think about why these are so effective in the analogous situation. Then steal the ideas liberally and repurpose them in the new context… analogy is at the core of all human thinking and is the connective tissue that helps us make sense of the world around us.

As a designer, I ask myself: “What features can I take away and still achieve my goal? What is the minimal amount of animation or movement that can expose a personality in my product? How can I make my product distinct using only a minimal number of aesthetic elements?"

I remember a story about how successful products come from everyone on the team knowing what you are doing and why you are doing it. You could ask a random engineer how the feature fits into the larger story.

That's part of why I've retreated to this idea of trying to understand traits rather than functions, because the structure of these organizations doesn't look the same at all.

The more things you have experienced, the broader your palette of extra knowledge, the more you can build upon and refine interpretations in order to arrive at unique and useful insights.

Each statement is presented as a fact, but each is actually an inference. Each statement may be factually wrong, so using insights will introduce risk into your process, but this risk has its reward. Insights are the source of innovation: insights are gold.

Some [products] get big as people store more data in them; this is called progressive commitment. You put more data in the system and you become more and more committed to the system over time. It gets harder and harder to leave that service. Evernote or Dropbox are great examples.

You can get ahead, however, by presuming that a competitor will introduce a new product into the market. In this scenario, imagine that your product loses miserably to that new product.

Some diagrams are presentation artifacts, used to rationalize your ideas to other people. Think of these, instead, as working artifacts. The purpose in creating them is to help you consider and establish strategy. Counterintuitively, once the artifacts have been made, they lose their value because they've already accomplished their goal: of informing your broad trajectory.

“Anything that will be a billion dollar industry in 10 years is already 10 years old. If you study history, almost no one invented anything."

Thank goodness we left behind the notion that in the world of technology, you're supposed to do stuff in a scalable way. We tried that, in the early days, and failed miserably. Scaling is the wrong approach when looking for product-market fit. You have no scale to solve for when you are starting something. So why optimize for that?

The best way to learn about product development, to learn the difference between design and product management, is to start something and do everything yourself. You'll intimately understand the tensions between the creative side and the 'ship it side. At some point, you have to converge, stop ideating, and get to the point where you can produce it, ship it, code it, and