Tag Archives: strategy

Subject To Change

I recently finished reading Subject To Change: Creating Great Products & Services for an Uncertain World, and I can recommend this book to anyone who wants, for example, to build software that resonates with its users.

Here are a list of thoughts and quotes this read produced:

  • Empathy is an understanding of a person or group’s subjective experience by sharing that experience vicariously that can be developed and cultivated through practice (i.e. it’s not innate). Using your sense of empathy can help you focus on the experience you want to deliver in a manner that is effective for those who will engage with it. Don’t confuse customer briefings with developing customer-focused empathy; there’s more to it!
  • Experience accounts for motivations, expectations, perceptions, abilities, flow, and culture.
  • Parity isn’t a strategy; neither is being the best.
  • Don’t craft the story of a product in isolation form the actual creation of that product.
  • Human life is complex–embrace this reality; don’t ignore it. Capture complexity with qualitative research (e.g. conduct interviews to elicit stories about experiences). Differentiate process (i.e. the how and why) from outcomes (i.e. the what, where, and when).
  • Sometimes experience strategy isn’t about hiding complexity as much as it’s about managing it (e.g. distribute complexity across a system so as not to overwhelm at any particular point). That is, the overall experience should never become too complex. There needs to be coordination among the experiences touch points, allowing each to fully exhibit its strengths.
  • “You have to recognize that a system will degrade, and make it such that such entropy doesn’t shatter the entire experience. The true success of experience design isn’t how well it works when everything is operating as planned, but how well it works when things start going wrong.” For example, provide meaningful seams into which people can insert themselves (i.e. leave an impression).
  • Great experience is difficult to plan for, and almost impossible to specify.
  • Good experiences require systematic coordination with the customer in mind (i.e. a focus on qualitative customer insights).
  • “Design is a way of approaching problem solving, decision making, and strategy planning that can yield better outcomes.”
  • “[Design-centric organizations] peer into the needs and desires of their customers, identify patterns of behavior, refine ideas that tap into those behaviors, then push into the unknown–or at least the uncertain.” -Roger Martin
  • “You can’t build a design competency overnight; it requires difficult changes in process, skills, and perhaps most importantly, culture.”
  • In my development organization we deploy a risk-driven iterative development process, with phases we call inception, elaboration, construction and transition. I’d liked the book’s description of “the fuzzy front end,” which I would liken to inception (e.g. “anticipation exceeds insight”).
  • “Good ideas need to fail early and often so you can arrive sooner at a great one.” Process won’t turn mundane ideas into stars–nor will great effort (strong execution). Therefore, avoid premature execution of an idea. For example, presuppose multiple solutions and suggest alternatives based on partial data. Define constraints that drive great solutions (e.g. think like a newbie, leverage empathy (that you’re developing, right? ;-) ).
  • “Strategy should bring clarity to an organization; it should be a signpost for showing people where you, as their leader, are taking them–and what they need to do to get there…. People need to have a visceral understanding–an image in their minds–of why you’ve chosen a certain strategy and what you’re attempting to create with it…. Because it’s pictorial, design describes the world in a way that’s not open to many interpretations.” -Tim Brown

On Monday, I noted 11 years with EMC (via its acquisition of Documentum). I can certainly say that “change happens” in the content management space and my own career.

My first engineering responsibilities were centered around the Documentum Desktop (aka Desktop Client) offering–client/server architecture implemented as a mixture of C++ and VB. Then I was called on to drive the first major release of WDK, a web-based application implemented in Java, JSP, HTML and XML. Next stop: creating an integration bridge between Documentum and authoring environments like Office, Adobe and XML editors (i.e. Application Connectors), which was specified as an N-tier architecture implemented as a mixture of C# (on the desktop) and Java (on the middle tier. Currently I’m focused on providing a rich set of services (i.e. local Java APIs, WSDL-based web services and RESTful web services) that drive a diverse set of applications, each with its own presentation layer technology decisions (e.g. Flash/Flex, ExtJS/DWR, etc.).

And “tomorrow” this will all be subject to change once again… :-)