Sunday, November 26, 2006

The Passion of the Developers

A thousand little decisions go into the creation of a great product. Most are not in the specs or master plans. Instead, they are implemented by testers and programmers. Yet, these are the same people that are traditionally lampooned as geeky and out of touch with the target customers.

What would happen if the developers possessed a deep understanding of their customers needs and desires? Suddenly, those thousand little decisions aren’t introducing random noise into the product. Instead, they are pushing the product forward. A single decision might not make much of a difference, but taken en mass, the momentum generated by enlightened developers can result in a massive reduction in design risk. You’ll develop the right product sooner and with fewer errors.

You can’t unfortunately just say “Dude, I looove my customers” and expect to get results. To harness the power of the passionate developer, you need the following pieces in place:
  • Empowered developers
  • Meaningful customer feedback

Empowered Developers
One philosophy is that we need better specs and those damned monkeys need to implement the specs exactly as designed. Better command and control system and more rigorous process is obviously the trick to success. This tends to generate poor results.

Imagine that you are a highly creative individual whose life is reduced to a series of highly detailed checkboxes that you are told to fill out one after another, day after day. If you deviate, you are punished and ridiculed. The results are gun-shy, non-communicative production workers that rely on obfuscation and deliberate bending of rules in order to express their innate creativity. Many wonder why they got into this dreary business in the first place. Others just give up.

When indentured coders and testers make design decisions, they lack both the experience and the desire to do the right thing for the user. They’ve been trained to take orders from management instead of building up an intimate empathy with their user. In the best of worlds, they implement uninspired versions of the features described in the specs.

In the worst of situation, they labor in secrecy, adding a little bit of their own uninformed creativity back into the product. When confronted with the havoc wreaked by Byzantine architectures and convoluted, unnecessary features, the humanoid production resources are surprisingly defensive. How can you be angry? They were just trying to salvage a small bit of their creative souls.

Such feature creep is not the fault of the individual testers or programmers. It is the fault of the team and management for turning a creative and invigorating process into menial labor where talented creators have no other option but to rebel.

We need a different philosophy based on passionate, educated team members that put the user at the center of their world. Developers gain the power to make their own decisions through their deep understanding of their customers.

Simple beliefs
Empowerment is a word that has been stripped of much of its initial meaning by the hippy liberals of the world, but the concept is rather simple. An empowered person is someone who has the ability to make their own decisions.

Let’s look at some building blocks that need to be in place before you can have empowered developers. You need to believe these are true and the people on the team need to believe that they are true. If these foundational beliefs are weak, it is very likely that you’ll end up falling back on command and control decision making structures in the face of emergencies or pressure.
  • Developers are passionate people: Even technical people burn inside with an inner flame of intense creativity. It can be hidden. It can be misdirected. But you must believe that it exists. The other insight here is that developers are motivated by very human issues. Dream, fears, respect and social hierarchy have a greater impact on productivity than economic incentives or logical rules.
  • Most decision should occur at the edges: Management serves a useful role in maintaining group cohesion. They rarely however, have intimate knowledge of the production issues experienced by individual workers. When developers at the edge with customer empathy are encouraged to solve problems that they happen across, a hundred issues that are invisible to managers start going away. A well functioning team is bursting with these small acts of ‘goodness’. Over the course of a project, the momentum results in an order of magnitude improvement in product quality. The most important outcome of this philosophy is that the people who build a piece of customer work flow hold absolute responsibility for it’s usefulness to the customer. “I’m just doing what I was told to do” is the vilest of attitudes.
  • Encourage learning through failure and feedback: The urge to control production often stems from fear of others making mistakes. “The morons are going to just screw things up!” is a common refrain. If you remove the opportunity for people to make bad decisions, you slide rapidly down the slippery path of command and control. An empowered developer has permission to fail. In fact, rapid, low cost failure is actively encouraged since it is the single best way to learn about how to make the product better.

Customer feedback
Now we have a team of passionate people. They are solving problems at the edges and they have permission to fail. Wonderful! We still, however, are missing the most critical element. We need to build a strong customer feedback mechanisms that encourages the team to create a product that matters.
  • Identify the customer
  • Believe in the customer
  • Get close to the customer
Identify the customer
Identifying your customer is where an amazing number of teams fail. They become focused on a bit of technology and imagine that users will just appear out of the woodwork. The whole process of iterative product design requires an identified customer so that you can know when you are on the right track and when you need to change direction.

The first step is to write down your customer definition. You’ll take into account market data, economics, opportunities that you’ve noticed and a billion practical details. It will feel like a very intellectual pursuit. The next step is to go out and find an actual, breathing human being who represents your customer. Customers are not data points. They are people that you can question, observe and befriend. The customer definition is just a tool that helps you narrow down your search. The real win is when you can get your customer in the room with your developers and they can drink a beer together. PBR FTW.

This isn’t easy. You may not be able to find a single person who represents your typical customer. You may end up with multiple customers that represent different needs. You may find that people on the team had very different ideas of who the customer might be. You’ll likely redefine your customer multiple times once you start talking with your initial customer prospects.

It is okay if it is hard. Don’t give up. Choosing your customer is the single biggest product design decision that you will make over the course of your entire product’s development. My belief is that no project should be green lighted for even minor development unless the team has had extensive conversations with an identified target customer.

Belief in the customer
The user of your product must be worthy of great passion. Remember, we are dealing with passionate developers thrive on living meaningful, creative lives. When the target customer is considered unworthy or boring, the development team will feel little urge to empathize or go the extra mile.

Product development is a service to others. The products we produce make someone’s world a better place. The team must be able to explicitly articulate why it is worth spending years of their precious lives providing the target audience with a new bauble. If you can get everyone on the team to passionately proclaim that they wish to serve the customer, you have built a powerful unifying vision that will carry the team through hard times.

It is worth noting that practically any customer can be worthy of great passion. All customers are people with dreams and passions of their own. They have tricky problems that result in very emotional human costs. An important aspect of connecting the passion of the developers with the passion of the customer is to identify the human, emotional aspects of the customer problem and bring those to the attention of the team.

Get close to the customer
Once you’ve identified your customer, you need to figure out ways of gathering information about them. One of the great Zen mysteries of product design is that in order to successfully serve your customer is that you should never give them what they request. So you can’t just grab a customer of the street and ask him to design your product. An average customer is good at identifying problems, but they are poor at prioritizing, understanding larger patterns and generating elegant solutions. That is your job. Your customer is there to let you know when you get things right and when you get things wrong.

The feedback cycle is pretty straight forward
  • Identify a problem or opportunity
  • Build a valuable solution that fits the available resources constraints.
  • Present the solution to the customer and record their response. Do they realize the value of your solution?
  • Use the data to identify new problems and opportunities. Look at the big picture and start the cycle all over again.
There are a plethora of good techniques available for getting closer to the customer. IDEO has their 51 ideation cards, college design courses teach books worth. They operate at different timescales and give you different types of information. Implement multiple ones and see which ones work the best for your particular customers. Here are some of my favorites:
  • Use your own product: Try to replicate what you see your users doing. Mimic the masters so that you understand their thought process by doing. This builds developer empathy with your customers and is one of quickest feedback cycles around. It also however, can be highly biased.
  • Onsite customers: Make a customer or two part of the development team. You get very rapid feedback and lots of cultural transfer into the team. The downside is that customer objectivity can be polluted by constant contact with the team.
  • Observe customers using your product: Set up usability studies and gather both quantitative and qualitative data. Every team should do this, but it can be expensive and feedback only happens in spurts.
  • Hire psychologists and ethnologists to study your customers: You’ll often gather key insights that would otherwise slip by someone not trained in methodical observation. Making these results actionable often takes additional work.
  • Listen to lead users: Some users are actively solving the same big problems that you are attempting to solve, often years ahead of the market. Find them and learn from their successes and failures.
You are always balancing three different aspects of the customer feedback.
  • Reduce feedback cycle time: The more quickly you can fail, the less effort you can put into each failure and the sooner your can correct your course
  • Improve objectivity of results: It is easy to get biased results. Many of the issues dealing with customer psychology are fuzzy in the best of situations and the developer’s own interpretations often dramatically skew the data.
  • Improve clarity of results: With more data comes more noise. Boiling down the flood of information into actionable, meaningful results that the team can understand is an ongoing activity. Many teams collect customer information, put it in a binder and then never look at it again. If you don’t act upon the customer feedback, it isn’t useful.
There is a substantial cost to all of these activities. You’ll need to change your development practices. Daily builds and regular check-ins help ensure that you always have a product that your can put in front of users. You’ll need to spend money. Bringing in users, ethnologists and usability experts adds to your headcount. This is the cost of doing business.

I’ve laid out two pieces of a successful product design team. The first is empowered passionate developers and the second great user feedback. Without the first, user feedback is either ignored or fails to permeate the multitude of small decisions that go into building the product. Without the second, the team spirals off into wasteful directionless exploration.

The single biggest barrier to creating a team of developers that are passionate about their customers is the core cultural beliefs of the people already on your team. Chances are good that they rose to where they are today by mastering a traditional command and control style system. They’ve been personally rewarded throughout the years by checking off the check list or writing checklist for others. They got a big fat raise for staying late and adding those 12 new features from the spec. When the product fails, they are told, “We should have added those 6 more features that got cut because developers were so slow.” The weak ones leave and the ones that are great at silently adding questionable features are promoted and promoted again. They are trained, their egos are invested. After five to 10 years of this, an experienced developer builds up an unshakable, unquestioned belief in command and control style development that only falters when they finally die off.

A thousand little successes do not start with a mandated policy. They begin to gain momentum when the role models within the company start acting upon the beliefs in concrete ways. This is where most process change breaks down. People say one thing, but revert back to habitual behavior when the going gets tough. They still believe, deep down, that the old method of command and control is less risky than trusting a team driven by passion and customer feedback.

Only when people on the team have personally experienced success using the new techniques and they’ve adopted new beliefs as a core of their personal philosophy will momentum sweep through the entire team. Several items need to be in place:
  • The right people: You need a core group of people willing to believe in both developers and customers. These folks are rare since the current system isn’t focused on producing them. If you find one, hire him or her immediately. The culture they bring to the team is worth as much as their skills alone.
  • The right situation: Often people need to be in the middle of a failing project before they will consider that there might be alternatives.
  • Time: Smart, strong people do not give up their culture overnight. After years of steady and obvious success, they’ll start to shift. Start with a like-minded core and grow it slowly.
Very few companies have all these items align. I was chatting with one insanely successful game company that follows many of these methods. They’ve given talks on their process. They’ve partnered with other companies and attempted to teach their process. Each time it fails. Imagine a company that consistently releases highly profitable AAA titles merrily giving you their secret formula. Would you take it?

Yet no one does. It would require companies giving up their most fundamental beliefs about how software is designed and built. They would need to give control to the lowest people in the organization, embrace a constant stream of failure and put customers, not their creative urges, at the center of the design process. That, my friend, is scary. Product success is cool, but a shot a being Top Monkey in the current ineffective system is much more attractive.

Why are we in this business again? Where is our urge to build great and wonderful things that serve the world? It seems a shame to let tradition, habit and hierarchy get in the way.

Lately I’ve been contemplating a nuclear bomb of a statistic. 80% of software features are either never used or used very rarely by customers. Anyone who does software development should be staring at that number in shock. 80% of your sweat and tears has little to no customer value. In most cases, customers would be just as happy if you were to give them 1/5th of the existing product and make that little sliver work better. How much time and resources could you save if you only delivered the right features?

This in turn has gotten me thinking about the common software development practices, the ones that fixate on execution risk instead of design risk. What we build is just as important as the fact that we can crap out a product by Christmas.

Passionate developers that empathize and listen to feedback from customers form the foundation of an efficient team for one central reason: They are very good at reducing the risk of building the wrong product.
  • Team members more readily identify areas of design risk that require iteration with customers.
  • Any big design mistakes are caught early through customer feedback.
  • Small decisions are made more rapidly with fewer errors.
You aren’t going to save 80% of your development time since all this iterating does chew up a serious effort. But you may save 50% or 60% of the budget. More importantly, you may end up releasing a product that is of value to someone that you care deeply about.

Passionately yours,


  1. Excellent post, as usual. Have you been reading Signal vs Noise, Creating Passionate Users, and Joel on Software or something? Because your points echo theirs (SVN: less software, CPU: care about your users, Joel: 80% statistic) almost perfectly.

  2. Outstanding again.

    I can do passion, but the cynicism and anger get to me. There does come a point though, where we just need to stop kidding ourselves.

  3. Great article.

    A question though. How does this reasoning apply when your customer is actually a publisher? Most of the ideas of the article imply grabbing an understanding of the game player, but in many cases the player is not your customer: The publisher is, and their priorities tend to be very different from those of the player.

    I suspect that many developers have the problem that they think that gamers and consumers are their customer, when in fact the people that pay their wages are the publishers they sign the deal with, and this causes a lot of disharmony.

  4. Some publishers are very serious about including user feedback in the QA process, especially in the casual "space", so if you partner with such progressive publishers and make it clear that user feedback is a major factor in your design decisions, then the disharmony should be minimized, or even made into harmony.

    I was lucky to network with someone who had come out of the traditional software industry and then spend almost a year building his own tiny games on his own design perogative, he's make many of the crucial design choices on our current project. The problem is, how do you empower artists working for an outsource firm? I've tried to do this explicitedly, and I've gotten good character design results from it, but I fear there is a potential dissonance between me-as-client, me-as-boss, and on-site-supervisor-as-boss. I suspect thats an issue for a lot of producers at various scales, any thoughts to a solution?

  5. Joel Spolsky mentions this in his interviewing and hiring guide.

    He says one should hire the smartest employees they can and let them make decisions themselves because they are smart. A team like this will outperform a team with a really smart manager and a bunch of code-monkeys.

  6. Joel Spolsky mentions this in his interviewing and hiring guide.

    He says is that you want to hire the smartest employees you can and let them make decisions themselves because they are smart. A team like this will outperform a team with a really smart manager and a bunch of code-monkeys.

  7. "Rapid, low cost failure since 2000!"

  8. I could see teams trying to adopt this type of process, but getting to a point where the people who gather, analyze, filter and prioritize the "customer feedback" become the command & control leaders of yore. Of course it could be argued that you should have your best people doing that job, but if that were the case, you wouldn't really need to switch processes anyway.

    Or am I just being pessimistic?

  9. The 80/20 statistic is misleading, because it assumes your customers are homogenous. In reality, each customer uses a different 20% of your features, so implementing only 20% of your software would actually leave most of your customers cold, because they'd find that it didn't have that one obscure key feature that they really need. Didn't Joel go into this?

    As for the rest of the article, I'd suspect the best way to implement this is by starting a brand new company that doesn't HAVE a culture yet, and making sure that respect for the lowest levels is ingrained from the start. In a larger company, the variant of this is to spin off a small company (or team) to implement this, and then let it spread.

  10. The 80/20 rule is a tricky one, especially if you end up doing the following:

    - Fail to identify your customer segments. If you assume your customers are a homogeneous blob and you cut features that a subsegment uses, then customer will get irritable.
    - Fail to measure customer value: Some features are rarely used, but critical when they are. Setting up styles in Word is a one time task that will almost never show up on a usage frequency survey. However, for the users that use this feature, it is critical. You need to look deeper than frequency data.

    If you look into these obscure features, you'll end up finding some that A) serve a segment of customers that you aren't targeting. B) that have low utility.

    The process of identifying these is more important than releasing a 'light' version. Instead it helps you understand the core value of the product so you can put the majority of your resources building on your unique value proposition instead of siphoning resources into less valuable activities.

    take care

  11. Long article. The premise reminds me of a story. The names have been changed

    A friend of mine, Bob, went to work for a game company solely because he loved their first game, Zahir 1. (He didn't have previous game industry experience, though he was an experienced programmer.) He was working on Zahir 2.

    Zahir 1 was an RTS. One of the mechanics in it was that you could bring an army toward an opponent's city. When you did that, a small army of militia would automatically emerge from the enemy city and automatically fight you.

    This was a nice mechanic, but every Zahir 1 multiplayer veteran (including Bob) knew of an exploit: you could bring in a small "feinting" force on one side of the city and draw out the militia; then you could send another small force in on the other side to attack the city directly. When the city was attacked enough, it converted to your side; and so did the militiamen. This meant that you could take over a city using a force which was actually much too weak to defeat the militia; which defeated the point of having militia to begin with.

    Again, this had been a long-standing exploit in Zahir 1. But it was never fixed in all of the patches for the game; the designers argued about it but never agreed on a best way to fix it, though they tried to mitigate it in a patch. So the community just agreed upon a rule to ban anyone who played this way.

    When Zahir 2 was being developed, the developers began arguing again. The consensus was still that there was no real fix for this tactic. But Bob pointed out what he had often said when he was a mere Zahir 1 player: "Why not just have the militia not swap sides? Either the attacking army will have to deal with them after all, or else the militia will defeat them and then attack the town and retake it."

    The designers dismissed this as ludicrously simplistic, and not in keeping with the logic of the game fiction (and, of course, because it was a design idea that came from a mere programmer). They ignored him and continued their debate with no real decision.

    And when it came time for Bob to implement the militia code in Zahir 2, Bob implemented the initial code so that the militia never swapped sides. "Why does it work this way?" the designers asked when they first played with the build. "Well, we'll fix it later", they said.

    Needless to say, it still worked that way in the final game... because it worked perfectly. And the hardcore Zahir 1 fans were effusively thankful to the designers for so fixing the problem with Zahir 1 so elegantly in Zahir 2.

  12. I like the message. I have been in software prod mgmt for 17 yrs and have seen this play out many times. One of the challenges is that as your product grows, it requires more people to build, market, sell and support. Then, the number of external data points increase to the point of not being able to have developer to customer contact.

  13. As someone who feels that I was recently crushed and removed from my job for refusing to hide my creativity and desire to change process behind a wall of 80hr weeks and "just do it" attitude, I found solice in your essay.