I wasn’t quite sure what to expect (and didn’t do my research about the speaker… Alan Cooper is the author of The Inmates Are Running the Asylum and About Face), but I really wish that I’d invited my collegues to join as Alan’s speech was full of tips and concepts that we’ve been doing at Six Apart… having the process defined is very helpful.

Here’s the video. It’s 40 minutes, but chock full of great insights about success in the digital age.

Best-to-market trumps first-to-market:

• Examples
  • an ergonomic peeler versus a dinky metal peeler
  • some archos jukebox player versus the iPod
  • AltaVista versus Google
    • We knew that Google was going to get better every single day, so the later you tried it the better it was for us, so we were never in a big hurry to get you to use it today because tomorrow it would be better - Serge Brin
  • Apple Newton vs PalmPilot
  • Powells/Virtual Mo’s vs Amazon
  • Java vs C++
  • Converse vs Nike
• Quality brings passionate customer loyalty
• Companies that focus on quality will succeed in the post-industrial world

Why is it that “first to market seems better than best to market”?

• why do we constantly hear “innovate and race to ship the product”?
• innovation is abundant
• innovation = new invention, but has come to mean “success” to most biz people
• innovation ≠ success
• success comes from considered design
• mgmt understands that design brings value but fail to integrate it into the high-tech creation process
• many believe that design is not possible from scratch rather that it comes from racing to ship and then iterating, which is helishly expensive

biz people focus on frirst to market rather than best to market be cause they don’t know how to do “best”

• current business processes are based upon methods that were defined in the industrial age
• contempory mgmt skills are industrial age skills that were developed for managing industrial age organizations
• best to market comes about through craftsmanship

craftsmanship

• ultimate measure of craft is quality
• goal is to get it right, not to get it fast
• craftspeople do it over and over till they get it correct (training, mentoring, etc)
• craftsmanship is a pre-industrial concept only affordanble by the rich
• industrial revolution brought industries of scale and a demise of craft

Software is not an industrial medium

• doesn’t have the economies of scale of industry
• no cost of goods sold
• unlimited supply of bits
• no cost of manufacturing labor
• can’t be served by simi-skilled labor

Programming is not an industrial age activity

• much in common with pre-industrial craft (but has many unique characteristics of “post-industrial craft”)
• programs are made one at a time and each piece is different
• it’s not scaleable, not formulaic - offshoring doesn’t work for pre-industrial craft - can’t drive costs down to get a better quality
• emensly complicated and nuanced and takes years of study
• characterized as not having a lot of innovation

Post industrial Craft

• filled with innovation
• massive interaction between the “moving parts” similar to the moving parts in a jet fighter (sophisticated example of the industrial art)
• no two parts are the same (modularization)
• abstracted notions are presented in abstract notation, patterns of thought inside the heads of people who’s languages we don’t speak.
• brittle environment (bugs)
• invisble, inscrutible, intangible (as are the people who create it)

Programmers are craftsmen

• knowledge workers
• self directed
• respoect competence, not authority
• job satisfaction comes from the quality of their work, not the success of their employer
• often smarter and more highly trained than upper management, which creates conflict

Management is industrial

• command and control
• tracking through cost accounting
• cost reductions through efficiency - craft has little notion of efficiency when goal is quality
• hierarchical delegation of responsibility to technical specialties
  • technical specialties were of minor importance to the strategic goals of the org
  • in sw, building software is not a technical specialty of minor importance, it is the organization
• in industral behavior was a by-product of functionality, where in post-ind functionality is a by-product of behavior
• programmers can’t be managed, only faciliatated (Paul Glen - Leading Geeks)
• mgmt based upon hierarchy, auth, span of control…. doesn’t admit to facilitation
• geeks approach their job as a problem and solution situation

the clash of two cultures

• facilitation is not a problem to be solved, rather it’s a process to undergo
• mgmt & geeks struggle with facilitation because neither are good at it…
• this clash of cultures gives rise to zero sum tactics, internecine fighting for apparently scarce resources.
• time and money are not scarce, though we’re confronted with it daily
  • venture capitalists with billions desparate to invest effectivly
  • google and ipod took plenty of time and came into a mature marketplaces
• when you push on a culture, you get wasteful fighing and panic and promotes the idea that we need to race to market due to a scarcity of time.

A culture of wastefulness

• organization bring product to marketplace and…
  • success - they will nurse the product along for their career
  • fail - there was no market for that product and will move to next green field
• there are many green pastures in high tech
• we’re an unreflective profession and we’re loathed to say that it’s our fault. easier to blame lack of market
• quest for magic bullet of innovation, but innovation simply doesn’t get it for you

Why can’t biz peeps work w/ post-ind craftsmen

• mgmt science lacks post-ind tools
• impulse is to reduce cost of programming (as if programmers are assembly line workers) which translates to some kind of economy of scale which can be passed on end users
• there are not economies of scale in software, thus reducing cost of programming is reducing quality of product.
• which reduces desireablity - in ind age peeps are willing to get less because they are paying less and getting more.
• no good mgmt tools for software consturction (the pattering of thoughts of people who don’t think like managers)
• no appropriate tools for accounting - no way to track amount of money comeing in per feature, funtionality, or behavior. ROI can’t be broken down more granularly than total cost and total revenue.
• no good tools for directing or facilitating programmers by managers… thus they find a go between a biz/tech person and hinge the strategic heart of their biz to someone who’s goals may not align with mgmt.
• we now have image of:
  • isolated out of touch management org
  • knowlege workers aimlessly wandering around trying hard to achive goals which may not be aligned to the strategic goals of the org.

Why interaction designers

• understand biz and tech
• research, blueprints, facilitation for programmers
• help programmers be craftsmen, experience joy of craft, and doing it over and over till it’s correct, and not backtrack when time to build it

Assuming the facilitation role

1. Plan
   • detailed written plan based on documented research and believeable user personas.
2. Visibilty
   • plan provides visiblility, show an image to programmer and biz person what “done” is.
   • Give them the only way to track progress of when it’s done.
   • A list of features and a timeline don’t do that.
   • A description of behavior in a narritive form, achieving their goals. Understood and committed to by programmers and biz peeps. Both will have buy in which will give all visibility.

3. Confidence

   • experience of having done it before

4. Frederic Brooks - Mytical Man Month chapter called “Plan to throw one away”

   • not expect to throw one away, plan to build a prototype to answer technical questions (not interaction questions). Build much smaller disposible piece of work to answers in the most efficient method. This is a well known method in the world of craft (work with pine before the burl)

The Dominant Paradigm

1. Requirements
2. Programming - do it all

Emerging Two-Phase Produce Creation

1. Requirements
2. Interaction Design - ask & answer: what are we going to build?
3. Programming - determines how, implement, build, do all at the same time.

Desired Three-Phase Product Creation

1. Requirements
2. Interaction Design - ask & answer: what are we going to build?
3. Design Engineering - How
4. Programming - implement, build, do

-

• Engineers don’t build bridges they determine how, iron workers build bridges.
• In industrial activity the medium of design is paper and math, medium of brige building is iron.
• In sw, the medium of design engineering is code, the production engineering is programming code
• there are diff kinds of code:
  • quick code to answer questions: performance, use of facility.
  • solid code for globalization, error checking, print support, production use, etc
• differnet mindset for each type of programmers

Designers collaborate while they iterate

1. Interaction Desgin - goal: correctness; iterate, collaborate.
2. Desgin Engineering - goal: correctness; iterate, collaborate.
3. Production Engineering (Programming) - goal: efficiency; clear plan, skilled execution.

-

• Because “correctness” has been established, the programmer can achieve their goal of efficiency. The one thing that kills production goal of “efficiencey” is backtracking.
• Goals for each are their craft, just different kinds.
• Design Engineering looks a lot like Agile methods (iterating rapidly, treading lightly). Agile works well for design engineering (determining how something should be built)… but are troubled and problematic for Interaction Design or Production Design
• Production Engineering works better with RUP (rational unified process), where everything is set out on paper before doing it.

How do we do it

• Start small as an example
• enlist programmers & designers
• document your success