The Silver Bullet — How a User-Centered Culture Can Solve All Your Product Development Problems

The Silver Bullet

As a leader of engineering teams, I always found myself struggling with the same set of failure patterns:

The software was delivered late.

The product didn’t resemble the original vision.

The product didn’t resonate with our customers the way we expected it to.

The product managers can never specify the requirements in specific enough detail for my engineers to get everything right.

The product managers and my engineers don’t seem to speak the same language.

I’ve had to change this product so many times that I’m overloaded with bugs and technical debt.

My engineers feel like “cogs in a machine”.

My engineers don’t know how to judge relative priority between tasks.

My engineers don’t really know why we’re doing what were doing, or what makes certain features so important.

It took me years of reflection to understand that all of these issues stem from a single root cause: We were treating software development like an assembly line, instead of a creative, collaborative process. My engineers were thinking about the tasks, not the product. They weren’t connected to our customers or the mission of the company. When we introduced a User-Centered Culture, where every person in the development process is engaged with and has empathy for the users, all of these major problems went away.

What is a User-Centered Culture?

User-Centered Design is a product development methodology that puts the user at the center of the development process, and creates tight feedback loops with them at every step along the way. This requires every person in the development process, including designers, developers, and QA, to engage with the users in a collaborative process of development. I will not cover the details of User-Centered Design in this article. That is a story for another time (I’ll come back and link to that article when it’s published). What I’m focusing on today is creating a User-Centered Culture.

Let me paint you a picture. I’m an engineer sitting in my “Dev Cave”. It’s dark. My desk is covered in action figures and light sabers. I’ve got three monitors with Matrix style terminals scattered about the screens. I hear a knock on my door..

Product Manager: “Hey Eric?”
Me: *Sigh. Groan.* “What’s up?”
Product Manager: “Hey, so you released this new screen and I asked you to make it blue, but you made it light blue. Our users actually like royal blue. It fits into the color palette of all their other favorite brands.”
Me: *Exorcist eye-roll.* “You didn’t specify which blue. I made it light blue. That’s still blue. Why should I care what shade of blue it is? It works the same way. Why are you bothering me with this when I have 25 other tasks to do this week?”

Chaos to Clarity
The Dev Cave. Abandon all hope ye who enter here.

This is a terrible example, but it illustrates some critical issues:

  • The product manager didn’t clearly specify, in fine enough detail, how the product should look.
  • The product manager had to interrupt the developer’s flow state to nitpick about an issue.
  • The engineer isn’t equipped to make an intuitive decision, so they either make the wrong decision, or they have to ask about every minor detail before they can act.
  • The engineer doesn’t understand why the customers feel the way they do about a certain feature or design choice.
  • The engineer doesn’t have a good sense for the customers preferences, culture, or way of life.
  • The engineer can’t make a judgement of relative priority between tasks.
  • They are disengaged from the rest of the company, so they only see the world through their own myopic view.
  • The engineer had to go back and change something that was already done, introducing waste, and a potential for bugs.

So how do I adopt this culture?

The first thing you need to do is break the mindset that the developers should just be left alone. They are the craftsmen and women who are carving the product vision into reality. The product goes directly from their hands to your customers’, but it feels like they do so over an immense divide. Your engineers need to create a real-world relationship with your customers that is full of empathy. When they hand the product to your users, they should do so lovingly, as a carpenter would their best work.

Hire for fit, not skills

Anyone can code. You can teach coding. Your people need to be bought into the mission from day one. If they don’t share your values, they’re just not going to work out. If you’re building a wellness app, but your candidate doesn’t care about wellness, they just won’t be inspired to solve the great problem you’re trying to solve. They won’t stick around when the going gets tough either. The front line of defense is to hire people who believe in your mission, and then figure out how to fill their skill gaps.

Managers Motivate, Leaders Inspire

The assembly-line culture evaluates engineers by units of productivity, or velocity. The User-Centered Culture evaluates engineers by how many love-letters or five-star reviews they get. You can motivate people by providing cash incentives for high productivity. You can inspire people by sharing heartfelt stories about how their work directly improved someone’s lives. Create a set of goals and incentives that drive them to make your product better for the users and further the cause.

Encourage Product Thinking

This means ensuring that every person at the company understands the big picture, and how they fit into it. It is shifting perspectives from the ground level to the bird’s eye, so that they can see how everything fits together into the Grand Design. Product thinking causes your team to understand that they are the machine, not the cog. We do this by constantly engaging them in the purpose and vision of the company, and taking the time to help them understand how the work they do fits into the big picture. We encourage our people to think about solutions instead of tasks, experiences instead of features, and people instead of users.

Create Empathy

Make your users human. Collect pictures, video, and testimonials to share with your engineers so that they have a human face to connect with their work. Connect your engineers and your customers in the real world. Host client appreciation events, conferences, or intimate focus groups so that your engineers have a chance to make a connection with your users. If your engineers have a real person they can connect with, to whom they will be directly delivering the product to, they will develop empathy. Empathy will allow them to make intuitive decisions about what the users will and won’t like. It will allow your engineers to be a part of the creative process, rather than just building whatever widget comes down the assembly line.

Establish Rituals

Host a team-building event every month, and take the time to share user feedback as a part of the celebration. Share the kudos and inspiring user stories where the product made a meaningful impact in their lives. Also share the failures and address how you let your customers down, with a commitment to try harder. Give awards to employees who championed a customer success. These are just a few examples of ritual celebrations that inspire and connect everyone to the purpose.


I am a big fan of the mood board in graphic design. It is a collage of every cultural and personal reference that can be discovered about the user. It’s the products they use, the music they listen to, the clothes they wear, the language they speak, the food they eat, the homes they live in, the places they work, the cities they travel. It is a collection of images, words, colors, fonts, and any other visual element that can convey the user’s perspective.

Chaos to Clarity

Graphic designers use this to choose a color palette, fonts, or design elements from other products your customers love. I appropriated this and started impersonating our users. I would play their favorite music in the office. I would decorate the office the way our users would decorate theirs. I gave up my favorite products and started using those that my users love. I tried to immerse myself and my team in the environment that our users do every day.

At first it was awkward, but over time it just became normal. This began to influence our product. For example, we use Spotify, but our users use Apple Music. After we adopted their favorite music app as our own, the details of our interface started to take on some of the Apple Music feel. The shapes, colors, terminology, and navigation elements all started to fit within the mood that our customers preferred. Now our engineers knew what the color blue meant.


We invested in creating a User-Centered Culture, and the results were transformative.

The product became a high-fidelity realization of the vision. It just felt right.

It had nuance in every aspect of function and design that fit seamlessly into our customers’ lives.

We reduced our requirements churn, rework, bugs, and technical debt.

Our product managers could focus on the big, game-changing innovations, instead of nitpicking on the fine details.

The engineers intuitively knew the right answer to many questions without asking.

Our customer service ratings and NPS scores went up, because our users had fewer issues and trusted that we really cared about their success.

Our user base grew as our reputation improved and we started seeing an organic left as users excitedly told their friends try our product.

Our product managers felt comfortable and welcome when they walked into the developers office to try to figure out how to solve the users’ problem together. No more groans and eye-rolls.

We better retain our staff, and were able to attract better talent.

We had easier access to funds, because the investors could see our passion and solid reputation.

All of this happened because we turned the assembly-line into a circle. The engineers were as deeply connected to the users as were the visionaries.

When I say the User-Centered Culture solves all your problems, I mean it.

All. Your. Fucking. Problems!

When we disconnect engineers from the users, we’ve broken the circle. The people responsible for building the product become as far away as anyone in the company from the users they serve. Let’s shed this great developer myth, connect our engineers with the purpose and the people they serve, and reconnect the circle.