How Facebook Ships Code (FrameThink)

I’m fascinated by the way Facebook operates.  It’s a very unique environment, not easily replicated (nor would their system work for all companies, even if they tried).  These are notes gathered from talking with many friends at Facebook about how the company develops and release software.

It’s been over six months since I assembled these observations and I’m sure Facebook has continuously evolved its software development practices in the meantime.  So these notes are probably a little bit out-of-date.  It also seems like Facebook’s developer-driven culture is coming under greater public scrutiny.  So I’m feeling more comfortable now about releasing these notes…   HUGE thanks to the many folks who helped put together this view inside of Facebook!

Notes:

  • as of June 2010, the company has nearly 2000 employees, up from roughly 1100 employees 10 months ago.  Nearly doubling staff in under a year!
  • the two largest teams are Engineering and Ops, with roughly 400-500 team members each.  Between the two they make up about 50% of the company.
  • product manager to engineer ratio is roughly 1-to-7 or 1-to-10
  • all engineers go through 4 to 6 week “Boot Camp” training where they learn the Facebook system by fixing bugs and listening to lectures given by more senior/tenured engineers.  estimate 10% of each boot camp’s trainee class don’t make it and are counseled out of the organization.
  • after boot camp, all engineers get access to live DB (comes with standard lecture about “with great power comes great responsibility” and a clear list of “fire-able offenses”, e.g., sharing private user data)
  • any engineer can modify any part of FB’s code base and check-in at-will
  • very engineering driven culture.  ”product managers are essentially useless here.” is a quote from an engineer.  engineers can modify specs mid-process, re-order work projects, and inject new feature ideas anytime.
  • during monthly cross-team meetings, the engineers are the ones who present progress reports.  product marketing and product management attend these meetings, but if they are particularly outspoken, there is actually feedback to the leadership that “product spoke too much at the last meeting.”  they really want engineers to publicly own products and be the main point of contact for the things they built.
  • resourcing for projects is purely voluntary.
    • a PM lobbies group of engineers, tries to get them excited about their ideas.
    • Engineers decide which ones sound interesting to work on.
    • Engineer talks to their manager, says “I’d like to work on these 5 things this week.”
    • Engineering Manager mostly leaves engineers’ preferences alone, may sometimes ask that certain tasks get done first.
    • Engineers handle entire feature themselves — front end javascript, backend database code, and everything in between.  If they want help from a Designer (there are a limited staff of dedicated designers available), they need to get a Designer interested enough in their project to take it on.  Same for Architect help.  But in general, expectation is that engineers will handle everything they need themselves.
  • arguments about whether or not a feature idea is worth doing or not generally get resolved by just spending a week implementing it and then testing it on a sample of users, e.g., 1% of Nevada users.
  • engineers generally want to work on infrastructure, scalability and “hard problems” — that’s where all the prestige is.  can be hard to get engineers excited about working on front-end projects and user interfaces.  this is the opposite of what you find in some consumer businesses where everyone wants to work on stuff that customers touch so you can point to a particular user experience and say “I built that.”  At facebook, the back-end stuff like news feed algorithms, ad-targeting algorithms, memcache optimizations, etc. are the juicy projects that engineers want.
  • commits that affect certain high-priority features (e.g., news feed) get code reviewed before merge.  News Feed is important enough that Zuckerberg reviews any changes to it, but that’s an exceptional case.
  • no QA at all, zero.  engineers responsible for testing, bug fixes, and post-launch maintenance of their own work.  there are some unit-testing and integration-testing frameworks available, but only sporadically used.
  • re: surprise at lack of QA or automated unit tests — “most engineers are capable of writing bug-free code.  it’s just that they don’t have an incentive to do so at most companies.  when there’s a QA department, it’s easy to just throw it over to them to find the errors.”
  • re: surprise at lack of PM influence/control — product managers have a lot of independence and freedom.  The key to being influential is to have really good relationships with engineering managers.  Need to be technical enough not to suggest stupid ideas.  Aside from that, there’s no need to ask for any permission or pass any reviews when establishing roadmaps/backlogs.  ”My product director doesn’t even really know all the things I have on my roadmap.”  There are relatively few PMs, but they all feel like they have responsibility for a really important and personally-interesting area of the company.
  • by default all code commits get packaged into weekly releases (tuesdays)
  • with extra effort, changes can go out same day
  • tuesday code releases require all engineers who committed code in that week’s release candidate to be on-site
  • engineers must be present in a specific IRC channel for “roll call” before the release begins or else suffer a public “shaming”
  • ops team runs code releases by gradually rolling code out
    • facebook has around 60,000 servers
    • there are 9 concentric levels for rolling out new code
    • the smallest level is only 6 servers
    • e.g., new tuesday release is rolled out to 6 servers (level 1), ops team then observes those 6 servers and make sure that they are behaving correctly before rolling forward to the next level.
    • if a release is causing any issues (e.g., throwing errors, etc.) then push is halted.  the engineer who committed the offending changeset is paged to fix the problem.  and then the release starts over again at level 1.
    • so a release may go thru levels repeatedly:  1-2-3-fix. back to 1. 1-2-3-4-5-fix.  back to 1.  1-2-3-4-5-6-7-8-9.
  • ops team is really well-trained, well-respected, and very business-aware.  their server metrics go beyond the usual error logs, load & memory utilization stats — also include user behavior.  E.g., if a new release changes the percentage of users who engage with Facebook features, the ops team will see that in their metrics and may stop a release for that reason so they can investigate.
  • during the release process, ops team uses an IRC-based paging system that can ping individual engineers via Facebook, email, IRC, IM, and SMS if needed to get their attention.  not responding to ops team results in public shaming.
  • once code has rolled out to level 9 and is stable, then done with weekly push.
  • if a feature doesn’t get coded in time for a particular weekly push, it’s not that big a deal (unless there are hard external dependencies) — features will just generally get shipped whenever they’re completed.
  • getting svn-blamed, publicly shamed, or slipping projects too often will result in an engineer getting fired.  ”it’s a very high performance culture”.  people that aren’t productive or aren’t super talented really stick out.  Managers will literally take poor performers aside within 6 months of hiring and say “this just isn’t working out, you’re not a good culture fit”.  this actually applies at every level of the company, even C-level and VP-level hires have been quickly dismissed if they aren’t super productive.

It’ll be super interesting to see how Facebook’s development culture evolves over time — and especially to see if the culture can continue scaling as the company grows into the thousands-of-employees.

What do you think?  Would “developer-driven culture” work at your company?

Follow-up discussion on Reddit: http://www.reddit.com/r/programming/comments/f3u0n/how_facebook_ships_code

Posted by Chris McCoy
 

Creating Web Product Prototypes in HTML (Digital Intent)


HTML prototypes are a great way to test concepts with customers and speed up development. See how Digital Intent's HTML prototyping process works.

As we've discussed before, you always want to test your assumptions, as early in the process as possible when things are easier to change. And when it comes time to see if functionality accurately reflects the product vision, prototypes are an indispensable step in our validation process. While there are dozens of tools available for creating prototypes, we've found HTML offers a number of strategic advantages.

Meet the HTML Prototype

An example of an HTML prototype

See an example of a Digital Intent HTML prototype

An HTML prototype is a quick demonstration of functionality previously outlined in user stories or a functional spec. Usually it is based on wireframes rather than a finished design.

HTML prototypes are primarily designed to assess the functional aspects of a site. By linking between pages, you can simulate critical user flows through the site, visualize different states of a given page, and more.

HTML prototypes provide a more realistic experience.

A prototype that's built in HTML allows the client to experience how the site will flow from screen to screen. Mockups and wireframes can be hacked to allow for linking between documents, but HTML prototypes do this more naturally. There's no software for clients to download or install, and they can review the screens using tools they're already comfortable with.

HTML prototypes also get the client used to discrepancies between one browser and another. Since we advocate progressive enhancement, providing an enhanced experience to browsers that support advanced functionality without sacrificing functionality for older browsers, clients can see visually what we mean much earlier in the process.

HTML prototypes make customer discovery more reliable.

Prototypes help us test concepts in front of customers to see if our execution of the product vision will work. It helps us visualize the flow between screens, and identify usability potholes early.

We've found that HTML prototypes lead to much better feedback, which is particularly useful when doing customer development. Showing a mockup generally leads to consistently positive feedback because the customer is focusing primarily on how it looks. By showing them a visually stripped down HTML prototype, the customer focuses on how it works. This leads to more realistic feedback.

HTML prototypes speed up development time.

We build our HTML prototypes using the same front-end standards that are used during the actual development process. We use the same CSS and Javascript frameworks, the same coding conventions, and the same in-house libraries.

This means that the HTML that is approved during the prototyping process can be used during development with a minimum of changes. Since we adhere to full separation of CSS and HTML, the interface can be applied to the site without the developers needing to scrap the HTML and start over. This has saved us countless hours and made our backend developers very happy.

This step also helps us develop unit tests and documentation - we create documentation while creating our prototypes, giving our developers a checklist of unit tests, todos and more. Because the prototypes include multiple states of a screen and the corresponding documentation, developers can effectively use the prototype as their spec.

How to build HTML prototypes

At Digital Intent, we like our HTML prototypes to look nice enough to show users forcustomer development, but simple enough to avoid getting derailed by conversations of aesthetic. Towards that end, the following are some best practices we use to create our prototypes.

  • Use frameworks.

    Using existing frameworks can make the process much easier. We usually use theBlueprint CSS framework to take advantage of their grid-based layout, and we usejQuery to simulate simple interactions like showing/hiding divs, toggling states, showing inline error handling and more.

  • Build and link to as many pages as possible.

    Simulating flows is a huge advantage to using HTML prototypes. And since HTML prototypes are so quick to create, we've found it makes sense to build as many pages as the budget allows. When we use prototypes for customer development, we like to identify as many usability concerns as possible - to see where they click, to see how difficult it is to recover and get back on track, etc.

  • Create a component library.

    Most sites are made up of similar components - search forms, checkout forms, pagination, tabbed navigation, etc. Rather than creating each of those from scratch every time, you can save your team considerable effort by creating and maintaining a reusable library of HTML components.

    Since you are using a CSS framework and have a standard way of styling elements, customizing components for a given layout is a breeze. Assuming you're using a grid-based layout like the one offered in Blueprint, customization can often be a matter of changing the number of columns used by the component.

  • Annotate each page.

    Rather than showing comments or open questions within the prototype, we place them in a tray on the top of the page. This keeps our interface clean for customer development, while still providing clients and internal stakeholders with relevant notes or unresolved issues.

  • Create a dashboard to communicate status and provide a table of contents.

    An example dashboard for our HTML prototypes

    See an example of a Digital Intent HTML prototype

    We place a simple dashboard page at the front of each of our prototypes, showing when it was most recently updated. As we identify screens that need to be included, we add them to the dashboard with a flag to indicate completion status. This helps everyone know where we're at in the process, and if needed allows you to jump to specific pages outside of the normal flow of the site.

HTML prototypes to the rescue.

While we've had success using a number of other tools in the past, we've found the benefits of HTML prototypes far outweigh the downsides. While they are certainly slower than creating a prototype in Powerpoint or Azure, it's not wasted work - since the prototype doubles as the front-end code for the application, it actually saves time. And the upside of getting more valid customer feedback and better communication with clients makes it well worth the effort.

Learn more about how Digital Intent works.

 

Posted by Chris McCoy
 

Design Process at Apple (Pragmatic Marketing)

Apple! Apple! Apple! Magazines can’t possibly be wrong, so Apple is clearly the “Most Admired,” the “Most Innovative," and the “Master at Design.”(1, 2, 3, 4, 5)

Let me tell you, when what you teach and develop every day has the title “Innovation” attached to it, you reach a point where you tire of hearing about Apple. Without question, nearly everyone believes the equation Apple = Innovation is a fundamental truth—akin to the second law of thermodynamics, Boyle’s Law, or Moore’s Law.

But ask these same people if they understand exactly how Apple comes up with their ideas and what approach the company uses to develop blockbuster products—whether it is a fluky phenomenon or based on a repeatable set of governing principles—and you mostly get a dumbfounded stare. This response is what frustrates me most, because people worship what they don’t understand.

I’ve been meaning to write this article for some time, but finally sat down and put pixel to screen after coming across a description of "Michael Lopp’s (a Senior Engineering Manager at Apple) discussion of how Apple does design. The discussion happened during a panel—including John Gruber (yes, for you Apple heads, that “Daring Fireball guy)—titled "Blood, Sweat, and Fear: Great Design Hurts, which was presented at SXSW Interactive on March 8, 2008. I scoured the Internet to find an audio or video recording, so I could garner these pearls of wisdom straight from the developers’ mouths. But no search engine I know could locate said files. If someone reads this and happens to have such a recording, please, please share!


Insights On Innovation

Without the recorded details, here is a collection of insights that various attendees created from their notes of the discussion—along with my own thoughts about what this portends for people who aspire to be like Apple. My intention is to synthesize these comments into a single representation of what Lopp and Gruber actually said.

Helen Walters at BusinessWeek.com summarized Lopp’s panel with five key points:

Apple thinks good design is a present. Lopp kicked off the session by discussing, of all things, the story of the obsessive design of the new Mentos box. You know Mentos, right? Remember the really odd packaging (paper rolls like Spree candy) promoted by some of the most bizarre ads on TV? It’s the candy that nobody I know eats; they just use it to create cola geysers.

Have you looked recently at the new packaging Mentos comes in? Lopp says the new box is a clean example of obsessive design, because the cardboard top locks open and then closes with a click. There’s an actual latch on the box, and it actually works. It’s not just a square box, but one that serves a function and works. I bought a box just so I could examine it more closely. It’s an ingenious design of subtle simplicity that works so well even shaking it upside down does not pop the box open.

According to Gruber, the build-up of anticipation leading to the opening of the present that Apple offers is an important—if not the most important—aspect of the enjoyment people derive from Apple’s products. This is because the world divides into two camps:

  1. There are those who open their presents before Christmas morning.
  2. There are those who wait. They set their presents under the tree and, like a child, agonize over the enormous anticipation of what will be in the box when they open it on Christmas morning.

Apple designs for #2. No other mass-consumer products company puts as much attention to detail into the fit and finish of the box—let alone the out-of-box experience. If you’re an Apple enthusiast, you can capture the Christmas morning experience more than once a year with every stop you make at the local Apple store.

Apple “wraps great ideas inside great ideas,” and the whole experience is linked as the present concept traces concentric circles from the core outward. Apple’s OS X operating system is the present waiting inside its sleek, beautiful hardware; its hardware is the present, artfully unveiled from inside the gorgeous box; the box is the present, waiting for your sticky little hands inside its museum-like Apple stores. And the bow tying it all together? Jobs’ dramatic keynote speeches, where the Christmas morning fervor is fanned on a grand stage by one of the business world’s most capable hype men.

Pixel-perfect mockups are critical. This is hard work and requires an enormous amount of time, but is necessary to give the complete feeling for the entire product. For those who aren’t familiar with the term, pixel perfect means the designers of a piece of Apple software create an exact image—down to the very pixel (the basic unit of composition on a computer or television display) —for every single interface screen and feature.

There is no “Lorem Ipsum” used as filler for content, either. At least one of the senior managers refuses to look at any mockups that contain such “Greek” filler. Doing this detailed mockup removes all ambiguity—everyone knows and can see and critique how the final product looks. It also means you will not encounter interpretative changes by the designer or engineer after the review, as they are filling in the content—something I have seen happen time and time again. Ultimately, it means no one can feign surprise when they see the real thing.

10 to 3 to 1. Take the pixel-perfect approach and pile on top of it the requirement that Apple designers expect to design 10 different mockups of any new feature under consideration. And these are not just crappy mockups; they all represent different, but really good, implementations that are faithful to the product specifications.

Then, by using specified criteria, they narrow these 10 ideas down to three options, which the team spends months further developing…until they finally narrow down to the one final concept that truly represents their best work for production.

This approach is intended to offer enormous latitude for creativity that breaks past restrictions. But it also means they inherently plan to throw away 90% of the work they do. I don’t know many organizations for which this would be an acceptable ratio. Your CFO would probably declare, “All I see is money going down the drain.” This is a major reason why I say you can’t innovate like Apple.

Paired design meetings. Every week, the teams of engineers and designers get together for two complementary meetings.

Brainstorm meeting—leave your hang-ups at the door and go crazy in developing various approaches to solving particular problems or enhancing existing designs. This meeting involves free thinking with absolutely no rules.

Production meeting—the absolute opposite of the brainstorm meeting, where the aim is to put structure around the crazy ideas and define the how to, why, and when.

These two meetings continue throughout the development of any application. If you have heard stories of Jobs discarding finished concepts at the very last minute, you understand why the team operates in this manner. It’s part of their corporate DNA of grueling perfection. But the balance does shift away from free thinking and more toward a production mindset as the application progresses—even while they keep the door open for creative thought at the latest stages.

Pony meetings. These meetings are scheduled every two weeks with the internal clients to educate the decision-makers on the design directions being explored and influence their perception of what the final product should be.
They’re called “pony” meetings because they correspond to Lopp’s description of the experience of senior managers dispensing their wisdom and wants to the development team when discussing the early specifications for the product.

“I want WYSIWIG…


I want it to support major browsers…


I want it to reflect the spirit of our company.”

[What???] In other words, I want a pony. Who doesn’t want a pony? A pony is gorgeous! Anyone who has been through this experience can tell you that these people are describing what they think they want. Lopp cops to reality in explaining that, since they sign the checks, you cannot simply ignore these senior managers. But you do have to manage their expectations and help align their vision with the team’s.

The meetings achieve this purpose and give a sense of control to senior management, so that they have visibility into the process and can influence the direction. Again, the purpose of this is to save the team from pursuing a line of direction that ultimately gets tossed because one of the decision makers wasn’t on board.

Now, if you want to get the quick summary of what we just discussed, I highly recommend reading Mike Rohde’s SXSW Interactive 2008 Sketchnotes. He took highly illustrated notes of the Lopp/Gruber panel. Content for this write-up also came from: Scott Fiddelke, Dylan at The Email Wars, Jared Christensen, David at BFG, and Tom Kershaw.


What else does Apple do differently?

If you read the various interviews that Jobs and Jonathan Ive (Senior Vice President, Industrial Design at Apple) have given over the last few years, you’ll find a few specific trends:

1. Apple does not do market research. This is straight from Jobs’ mouth: We do no market research. They scoff at the notion of target markets, and they don’t conduct focus groups. Why? Because everything Apple designs is based on Jobs’ and his team’s perceptions of what they think is cool. He elaborates:

Said another way, Jobs hires really smart people, and he lets them loose—but on a leash, since he overlooks it all with an extremely demanding eye. If you’re seeing visions of the “Great Eye” from J.R.R. Tolkien’s books, then you probably wouldn’t be too far off. Here’s the way their simple process works:

Start with a gut sense of an opportunity, and the conversations start rolling.

What do we hate?

A: Our cell phones.

What do we have the technology to make?

A: A cell phone with a Mac inside.

What would we like to own?

A: An iPhone, what else?

But Jobs also explained that in this specific conversation, there were big debates across the organization about whether or not they could and should do it. Ultimately, he looked around and said, “Let’s do it.”

I think it’s clear they also benefit from the inauspicious “leak” to the market. By that I mean this overly tight-lipped organization occasionally leaks early ideas to the market to see what kind of response they might generate. Again, what other company benefits from having thousands of adoring designers come up with beautifully rendered concepts of what they think the next great product should look like?

2. Apple has a very small team who designs their major products. Look at Ive and his team of a dozen to 20 designers who are the brains behind the genius products that Apple has delivered to the market since the iMac back in 1998. New product development is not farmed out across the organization, but instead is creatively driven by this select group of world-class designers.

Jobs himself has delegated away many of his day-to-day operational responsibilities to enable himself to focus half of his week on the high- and very low-level development efforts for specific products.

3. Apple owns their entire system. They are completely independent of reliance on anyone else to provide inputs to the design and development of their products. They own the OS, they own the software, and they own the hardware. No other consumer electronics organization can easily do what Apple does because they own all of the technology and control the intimate interactions that ultimately become the total user experience. There is no other way to ensure such a seamless experience—a single executive calls the final shots for every single component.

4. Apple focuses on a select group of products. Apple acts like a small boutique and develops beautiful, artistic products in a manner that makes it very difficult to scale up to broad and extensive product lines. Part of this is due to the level of attention to detail provided by their small teams of designers and engineers. To think that a multi-billion dollar company only has 30 major products is astounding, because their neighbors at that level of revenues have thousands of products in hundreds of different SKUs.

As Jobs explains, this is the focus that enables them to bring such an extensive level of attention to excellence. But it is also an inherently risky enterprise, because they are limited in what new product areas they can invest in if one fails.

5. Apple has a maniacal focus on perfection. They say Jobs had the marble for the floor at the New York Apple store shipped to California first so he could examine the veins. He also complained about the chamfer radius on the plastic case of an early prototype of the Macintosh. You had better believe, given the 10 to 3 to 1 approach for design, that every shadow, every pixel is scrutinized. It’s in their DNA.

They are willing to spend the money to make sure everything is perfect, because that is their mission.


So is it possible for you to innovate like Apple?

So given all this, what is a company to do if they want to innovate like Apple? First, forget about it unless you are willing to invest significantly and heavily to establish a culture of innovation like Apple’s. Because it’s not just about copying Apple’s approach and procedures. The vast majority of executives who say, “I want to be just like Apple,” have no idea what it really takes to achieve that level of success. What they’re saying is they want to be adored by their customers, they want to launch sexy products that cause the press to fall all over themselves, and they want to experience incredible financial growth. But they generally want to do it on the cheap.

To succeed at innovation as Apple has, you need the following:

You need a leader who prioritizes new product innovation. The CEO needs to be someone who looks out to the horizon and consistently sets a vision of innovation for the organization that he or she is willing to support completely with people, funds, and time. Further, that leader needs to be fluent in the language of your customer and the markets in which you compete. If the CEO cannot be this person, then he or she needs to be willing to trust that role to a senior executive and give that person the authority and latitude to effectively oversee the new product development process.

You need to focus. A cohesive vision describes the storyline for your products and services. That storyline needs to state decisively what is in bounds and what is out-of-bounds over an 18-month to 3-year period. Everyone in the development process who matters must be in lockstep with this vision, which means you need to have open lines of communication that are regularly and consistently managed.

This storyline or strategic vision needs to be revised according to market changes and the evolution of your new product pipeline. It helps that Apple tends to approach their products with a systemic frame of mind, looking to develop the “total solution” rather than just loosely joined components.

Obviously, the other focus is to make a profit, since that is what supports the continued efforts to design the next great product. And, when every one of the major products is a moon shot, they have to work to ensure it meets exacting standards—to do everything they can to ensure success.

You need to know your customer and your market. Jobs and team can get away with not doing market research, identifying target markets, or going out and talking with customers because of the markets they play in and the cult-like customers who adore them. Most technology companies also believe they can get away with this—and most technology companies get it wrong.

Quick, identify 10 different pieces of technology that truly meet your needs and that don’t bug you due to a major flaw you either have to live with or compensate for in some fashion. Could you come up with more than five? I didn’t think so.

We’re drowning in a sea of technological crap, because every product that is released to the market is a result of multiple compromises based on decisions made by the product manager, the engineering manager, the marketing manager, the sales manager, and everyone else who has skin in the game as they prepare the offering to meet what they think are the target customer’s needs.

The reason Jobs and Ive get it right is because they design sexy products with elegant and simple interfaces—for themselves. And they count on their hip gaggle of early adopters to see it the same way. Once the snowball starts rolling, it’s all momentum from there.

Apple doesn’t sell functional products; they sell fashionable pieces of functional art. That present you’re unwrapping is all about emotional connection. And Jobs knows his marketplace better than anyone else.

Because you’re not Apple and you are likely not selling a similar set of products, you must do research to understand the customer. And, while I’m sure Jobs says he doesn’t do research, it’s pretty clear that his team goes out to thoroughly study behaviors and interests of those they think will be their early adopters. Call it talking to friends and family; but, honestly, you know that these guys live by immersing themselves in the hip culture of music, video, mobile, and computing.

The point is not to go ask your customers what they want. If you ask that question in the formative stages, then you’re doing it wrong. The point is to go immerse yourself in their environment and ask lots of “why” questions until you have thoroughly explored the ins and outs of their decision making, needs, wants, and problems. At that point, you should be able to break their needs and the opportunities down into a few simple statements of truth.

As Alan Cooper says, how can you help an end user achieve the goal if you don’t know what it is? You have to build a persona or model that accurately describes the objectives of your consumers and the problems they face with the existing solutions. The real benefit, as I saw in my years working at InstallShield and Macrovision, is that unless you put a face and expectations on that consumer, then disagreements about features or product positioning or design come down to who can pull the greatest political will—rather than who has the cleanest interpretation of the consumer’s need.

You need the right people, and you need to reward them.

The designers at Apple are paid 50% more than their counterparts at other organizations. These designers aren’t working at Apple simply because they’re paid more. They stay at Apple because of the amazing things they get to do there. Rewards are about salary and benefits, but they are also about recognition and being able to do satisfying work that challenges the mind and allows the creative muscles to stretch. Part of this also comes down to ensuring your teams are passionate about innovation and dedicated to the focus of the organization. As Jobs says, he looks for people who are crazy about Apple. So you need to look closely at the people you are hiring and whether you have the right team in the first place.

Alain Breillatt is a product manager with more than 14 years of experience in bringing new products and services to market. His previous professional lives have carried him through medical device R&D, consumer credit, IT management, software product management, and new product consulting at companies including Baxter, Sears, InstallShield, Macrovision, and Kuczmarski & Associates. As a consultant he has generated new product portfolios for Fortune 500 and smaller organizations and developed course materials on innovation for the MBA and Executive Education programs at Northwestern University’s Kellogg School of Management.

Alain is a Director of Product Management for The Nielsen Company’s syndicated consumer research solutions. Contact Alain at abreillatt@gmail.com or catch his latest insights at http://pictureimperfect.net

Posted by Chris McCoy