Product development lessons from Porsche 911

Porsche has been selling the 911 since early 1960’s. Iterating on it. Improving it. All this while they’ve had a dedicated and loyal fan base. Why does the 911 have such loyal followers? Why is it important to ask this question? I think there’re lessons from Porsche 911 that can be applied to other products, including those made up of 1’s and 0’s. Porsche 911 I asked “Why do Porsche 911’s have such ardent fans?” on Quora, watched some documentaries, read up about the car, reflected on it, and here’s what I’ve learned.

  1. The cult: Buying the product should make the user part of a cult or community. The enthusiasm from those in the cult already will rub onto the new members, keep them engaged, and increase the mystique of the product for those not in the cult. It also provides a medium for the users to help each other and some to emerge as experts. It attaches social currency to expertise about your product thereby attaching more value to knowledge about your product.Porsche Spyder Racing # 130
  2. Design: The product should value the design and aesthetics very highly. The design should be iconic. Porsche 911
  3. Unique: The product should have a unique quirk that fundamentally influences the design and makes it more interesting. The rear-engine design of the 911 gives the car some unique characteristics that influence the handling of the car.
  4. Feelings: Focus on how the product makes the users “feel”. You’d often hear people saying that they feel “one with the car”. The growl of the engine, combined with near-instant torque and acceleration, and precise handling of the car lead to grown men giggling like toddlers after changing gears. Feelings trump utility. We’re humans after all.
  5. Story: The product should have a heritage, a history, a story. You’ve got to be selling the product because you believe in something. That something has to be more than just about money. Users must feel that the engineering in the product originates from something deep and not a shallow monetary desire. The 911 can trace its roots to the Porsche 64 that was assembled from the parts of a VW Beetle because Professor Dr. Ferdinand Porsche wanted a light sports car."Story Road"
  6. Iterate carefully: Don’t deviate from the design too much once you’ve found what users love. A design language that doesn’t change a lot with every new version goes into making the design iconic.
  7. Influence: Have influential users to spread the word. The pricing of the product is a meta-filter for the kind of market/users who would buy the product.
  8. Awards: Ferociously participate in competitions and win awards. Not only will this influence the engineering of the product in good ways, it also goes into making the users feel that they own a special product. The owners must feel pride in owning the product. Porsche 911 Rallycar
  9. Pricing: The total package the product has to offer has to be worth the price. A Quora response put it very aptly that you can get a car with more acceleration, better braking, more speed, more reliability, etc. – but not one that does well in all these attributes at the same time as much as the Porsche 911 does.
  10. Exclusivity: Exclusivity is important. Don’t mass produce and dilute the brand and product. Use pricing or limited production runs to get exclusivity.
  11. Variants: Have multiple product variants at different pricing tiers. Do provide the insane perf variants to those who can afford it and thus maintain the iconic image of the product.
  12. Basics: All of this is useless if the product doesn’t get the basics right. The product should be powerful, reliable, well engineered, and among the best in class.

Overall, look at the product from the angle of – what would cause kids to dream of owning this product? What would cause them to put posters about the company and your product on their bedroom walls? What would cause them to dream of working at your company one day?

Finally, some caveats:

  1. These ideas are more applicable to consumer products than enterprise products. The purchase decisions in enterprises are driven differently than in consumers. Though a 911-like finesse in a product that provides the typical bells-and-whistles of enterprise products is an interesting way to differentiate.
  2. These ideas are harder to apply in tough markets where the cheapest price may be more valued than anything else. One can start in such a market. In fact that’s how Porsche started making sports cars in post WW-II Germany.

What do you think? What can we learn from Porsche 911 and apply to new product development? Is there any other product that you think has interesting lessons for software engineering?


Types of software

There are 3 broad categories of software:

  1. Software that entertains – think games
  2. Software that solves a problem – think Word/Excel
  3. Software that impacts humanity

The last category is especially interesting. But what do I mean?

Let me explain.

Consider Facebook. Which category does it fall under?

Category 1? Is it used mostly for entertainment? That’s probably true for how a large set of people use it. But Facebook played a significant role in the revolution in Egypt and in Tunisia and Yemen. Facebook and Twitter were used by people in these countries to coordinate protests and bring about change. That’s real impact.

Here’s another example: Facebook is being used by an anonymous group of volunteers to clean streets in India. They call themselves “The Ugly Indian”. They post before-after pictures after accomplishing a project and share it on Facebook and that encourages others to get involved too. That’s real impact.

We should be working on software that has the potential to transcend into the domain of software that impacts humanity. There’s money in making software that entertains, and there’s money in solving problems with software. But real impact, that is, the kind of impact that changes the direction in which humanity is going happens when the software helps large sets of people achieve what they aspire to achieve, work with each other, and have a realistic shot at their dreams.

That’s the kind of software we should dream of building.


Managing dependencies, when “present” sucks but “future” isn’t ready yet

Here I talk about a pattern in software engineering that I have seen occur in many projects, and suggest a methodology for handling it.


  • Dependency on an external component or service exists.
  • Current version of the external component is being phased out / not being maintained / aging.
  • Next version of the external component or its replacement isn’t ready yet.


  • Should we take a dependency on the aging component that is available, or wait for its replacement to become available? We see some potential throw-away work in using the aging component and want to avoid it as much as possible. Starting to use the replacement of the external component right away even though it isn’t ready yet exposes us to instability related issues that we would like to avoid.


  • Data-model and API contract abstraction: Identify the data-model and contract that captures our requirements from the external component. Capture it in code using one or more interfaces. Introduce concrete classes that act as brokers talking to the external component.
  • DI for easy switching in code: Use a dependency-injection framework to allow a different implementation of the interface(s) implemented by the external component’s broker to be plugged in without having to change code all over the place.
  • Tests to catch regressions: Have a rich suite of tests that capture our expectations from the implementation of the interface(s). This will help identify and contain the breakage after we actually move to the new component.
  • Data to support the migration decision: Use logging to capture data that would later help support the argument for moving to the new system when it is ready. What are the reasons we want to move to the new system? Capture relevant data that would help support the decision.
  • Data migration: Plan to migrate the data from the old component to the new component, if it is stateful.
  • Staged roll-out: Roll out the new component in stages if possible. This would help contain the impact of breakage should issues be discovered after producitionzing the new component.
  • Run in parallel: Run old and new components in parallel for a while handling the same requests until the new component is proved stable in production. Should the new component need to be rolled back, having the new component and the old component in the same state would save the effort of migrating data from the new component back to the old component.
  • Avoid surprises from the replacement: Track the progress of the team building the new component that’s meant to replace the new component. Are they on track? Delayed?
  • Avoid surprises for your customers/stake-holders: Have a timeline identified up-front, based on the road-map of the external component, that identifies when we would take a hard look at moving to the replacement and make a go/no-go decision. If no-go, then the timeline should call out when would we look at the replacement again.
  • C&C: Capture and communicate your plan so others know that you have a plan.