A Strategy for New Products

In prepping my strategic stew, how will I stir in

  • Abductive Reasoning, 
  • Thin-Slicing, 
  • Minimum Viable Product, and
  • Launch Early & Iterate

to realize a new-fangled software product?

Abductive reasoning, thin-slicing, minimum viable product, and launch early & iterate are bite-sized concepts in the Bobutusian Stew I have been slow-cooking in my crock pot while I invent a software product.

Abductive Reasoning

I learned about Abduction and abductive reasoning….um…yesterday, so pardon any misconceptions attributable to Beginner’s Mind.

Abduction is a method of inference that precedes induction and deduction. Abduction produces a hypothesis. As such, it makes sense for me to think of abductive reasoning as

Hunches that spawn rapidly testable hypotheses.

As a bicameral thinker, one product development approach that resonates is to

Start creatively fuzzy (intuitive), then bring down the big hammer of test and verification to pound on your hunches.

Abductive reasoning starts ever-so innocently when we ponder a cloud of seemingly unrelated facts, then an inexplicable inner-voice tips us off that they might be related.

Justin McMurray from Made By Many has an provocative post about Agile Strategy that has generated a flurry of commentary on his blog. Justin espouses testing hypotheses over research and deduction. He says

Develop or invent hypotheses to test immediately. It’s about prototyping for opportunities, propositions and strategic themes rather than deep diving into deducing a singular ‘right’ direction.

Justin’s phrase “rather than deep diving into deducing a singular ‘right’ direction” gets to the heart of my serial rant about the direction component in the velocity Agilists track so fervently (e.g., Scrum’s Achilles Heel & Where Scratch Meets Itch).

Thin Slicing

Psychologists have postulated that humans are capable of discerning complex patterns based on very narrow time-boxes of experience.

Malcolm Gladwell, author of Blink and other best-selling books, might consider my hunches to be a bi-product of Thin Slicing. Gladwell says we make split-second conclusions based on patterns we discern within a blink of an eye.

I don’t know how willing I am to trust my split-second conclusions. I am, however, inclined to trust first impressions and hunches enough to warrant further examination (hypothesis testing).

Minimum Viable Product

Minimum Viable Product is a product development strategy popularized by Eric Ries and written about in Eric’s blog Startup Lessons Learned. The post Minimum Viable Product: a Guide lays out MVP from A to Z.

Definition:

The minimum viable product is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.
~ Eric Ries

The salient phrase in Eric’s definition is validated learning about customers. What can we do to learn as we go without loosing our customers?

Launch Early & Iterate

In my post Launch Early & Learn, I gushed about Google’s mantra of Launch Early & Iterate.

I cite the product development stories of Google News and Google Wave as examples of allowing customers to help guide the direction of a software product, rather than the whims and wild-assed guesses of a customer proxy (like Scrum’s Product Owner).

Google approach, in a nutshell, is to release a product, collect feedback, and prioritize upcoming iterations based on that feedback.

Who would argue with success?  Of course, most of us don’t enjoy Google’s organizational advantages. That said, not everything requires a grip full of ‘chedda — there’s usually a poor man’s approach to everything.

Summary – The Bay Leaf

I started to conclude by invoking the metaphor of weaving a red thread from these loosely coupled concepts, then I realized I would be mixing metaphors in my stew…as in

Waiter! There’s a red thread in my stew!

So where is the bay leaf in this slow-cooked stew?

My spouse says finding a bay leaf in one’s stew is good luck. I am a proponent of luck of any flavor. In particular, I embrace Dumb Luck which I define as those emergent things that always seem to materialize (while you’re working balls-to-the-wall) that you decide to incorporate into your scheme because it makes sense.

In Team Decisions & Commander’s Intent, I quoted heavyweight boxer Mike Tyson

Everyone has a plan ’till they get punched in the mouth.
~ Mike Tyson

I am developing my software product plan-free. That isn’t to say I don’t have some hard-baked simple mantras. For example, my Commander’s Intent is two-fold

  1. Has this enrolled new users?
  2. Has this retained loyal users?

The two simple mantras of my Commander’s Intent are imprinted in my subconscious. Simple right?

Simplicity allows people to act
~Dan & Chip Heath, from Analysis of Paralysis

In the heat of slinging code, I expect hypotheses to emerge that fall somewhere within the purview of my Commander’s and that will be readily testable in the next release.

My intent is put my intuition to work within a simple framework. I want to

  • use abductive reasoning to spawn hypotheses,
  • rapidly test these hypotheses in production code, and, 
  • validate learning about my customers.

Integrating Interaction Design Into Agile Projects

Thanks to advocates in Agile community, many software developers have gotten proficient at delivery. Perhaps now it is time to examine what we’re delivering.

Better questions and attentive listening might avert those occasions where we do an outstanding job of delivering the wrong thing.

Discovery & Delivery

At last week’s last week’s CodeFreeze 2010 on the University of Minnesota campus (my alma mater), speakers David Hussman and Jeff Patton were wearing t-shirts that said Discovery & Delivery.

The authorized theme of CodeFreeze was Redesigning Agility. The unauthorized theme might well have been as David and Jeff’s t-shirts said — Discovery & Delivery.

How do we integrate Interaction Design into our Agile projects?

Looking retrospectively beneath the vaulted glass and wood ceilings of Memorial Hall, where CodeFreeze was hosted, one might conclude that the Agile community deserves kudos for improving our ability to deliver software. One also might conclude that we have yet to make significant progress integrating interaction design and usability into the Agile cookbook.

Interaction design and usability considerations will continue to play a significant role in whether people are satisfied using our products. We had better jump on the design band-wagon, or at least appropriate all the most forward-thinking interactive designers as our own.

Jeff Patton posed the following question to the CodeFreeze audience

If you evaluated the quality of your process based on customer satisfaction, what would that process look like?

Jeff’s question helped solidify an approach I have been considering for months. Three influences on my thinking are:

  1. Google’s slogan of Launch Early and Iterate (see my post Launch Early and Learn);
  2. Eric Ries‘ concept for startups of a Minimum Viable Product; and
  3. At CodeFreeze, watching Alan Cooper talk about Interaction Design and watching David Hussman and Jeff Patton talk about Discovery (e.g., Story Mapping).

I have concocted a recipe for a discovery & delivery process that I am eager to share and to take for a test drive.

User-Driven Rapid Prototyping

Lets call it User-Driven Rapid Prototyping. As the name implies, the approach involves rapid prototyping. It is also user driven because the people who use the application help the software team prioritize the backlog.  The challenge and proposed approach are a follows:

Challenge Integrating Interactive Design into Agile projects
Proposed
Approach
Iterative Cycles of

  • N weeks discovery and 
  • N weeks coding & delivery

The diagram below shows what the iterative cycles of User-Driven Rapid Prototyping might look like

Where

  • The hand palming the spiral is a Discovery or Re-Discovery Iteration
  • The subsequent handless spirals are Delivery Iterations
  • Discovery iterations, after iteration zero, are called Re-Discovery
  • Odd iterations are for coding and delivery, while Even iterations are for discovery (interactive research and design).
The software team consists of developers and interaction designers working hand-in-hand. Since the backlog will be now driven by the people using your software, the over-worked and frequently clueless Product Owner we’re familiar with from Scrum, becomes redundant.

Iteration zero –  Iteration zero is a discovery iteration. The goal is to learn as much as is reasonably possible about the community for which you are developing the product. Iteration zero might include chartering, creating personae, and story mapping. Also it might include any of the groundwork you typically lay before iterating in earnest.

Iteration 1 (and Odd Iterations) – Iteration 1 is the first coding and delivery iteration. Iteration 1 might only include some user feedback screens, or a polling mechanism to enable the people using your application to help the team prioritize features, to call out usability snafus, and to bring to light potential design problems. In general, odd-numbered coding/delivery iterations are for adding new features and releasing a deployable prototype. During coding iterations, developers are coding while the interaction designers are working to stay ahead of the coding/delivery curve with ongoing user research and design deliverables.
Iteration 2 (and Even Iterations) – Iteration 2 is the first re-discovery iteration. The re-discovery iteration is a chance for the interaction designers to account for any feedback, then implement course corrections as needed. During this time, developers work with interaction designers to address the feedback, to re-factor code as needed, and to plan the next delivery.

Designers engage in “designing with your hands” which involves making multiple, low-resolution prototypes quickly
~Tim Brown, CEO of IDEO

There is no one-size-fits-all software process. There are conditions that are likely more amenable to the approach proposed here. Greenfield software projects and startup projects might be most suitable. For example, in the evolution of a startup, an ever-improving prototype might be used to attract rounds of investment to fuel continued development phases.

Wouldn’t it be a kick if the picture below could just as easily be the people using your software as the people crafting it?

More…

  • Tim Brown urges designers to think big in this video on Design Thinking.
  • In Usage-Centered User Stories & Story Mapping Part 1 and Part 2, I explain what post-Agilists like Jeff Patton and David Hussman, have been telling the Agile community how we might help teams enrich poorly conceived user stories and how we might better use our iteration zero time for product discovery. That is, how discovery might be improved.

Launch Early and Learn

Launch early and iterate is a rule-of-thumb perfected by Google and practiced by wildly successful companies like Facebook. Among agilists, the notion of iterating is a given.

I am adopting a new-found mantra of

Launch early and learn

I credit Marissa Mayer. She is Google’s first female engineer, Money’s #21 in 40 under 40, and Glamour’s Woman of the Year 2009.

Marissa gave a compelling talk to Stanford students on Google heuristics and innovation. I recommend viewing Marissa Mayer at Stanford University for 49 minutes of insight into the thought repository of an unusually smart company. Marissa gives her Top 9 slogans, joking that presenting a Top 9 is marginally more innovative than a Top 10.

I’d been brain-casting how to create a UX-Driven-Development (UDD) platform for software, when Marissa’s Stanford talk introduced me to the Google slogan

Launch Early and Iterate

In front of a slide declaring innovation not instant perfection, she shared personal narratives about the early – some would say premature – launches of Google News and Google Video. I have already mused that Google Wave is an immature product (see The Missing Link in Google Wave – UI For Primates).

Five days removed from my Missing Link in Google Wave post, I finally understand the Google modus operandi.

True Confessions – Google News

The Google News team was nearing their targeted first release. Six engineers respectfully disagreed over which feature they had time to include in their debut release. Three engineers vehemently supported Search-by-Date. Three engineers passionately supported Search-by-Location. Deadlocked.

Google made the decision to polish up existing functionality and not add new functionality. They released Google News without Search-by-Date or Search-by-Location! Shortly after the roll-out, they were bombarded with emails

How come I can’t Search-by-Date?

Email requests were running about 100 to 1 for Search-by-Date over Search-by-Location. Guess which feature had top priority for the next iteration?

The preview of Google Wave occurred while the ink on the Wave federation spec and the Wave API was not only still wet, but still being pushed around the page.

When I attended the Google Wave hackathon last June, Google engineers had finally stabilized their Wave Server the night before the public arrived to start banging on it. That’s early.

Google Mail was in beta for so long for a reason. It is a way of working that keeps development cooperatively linked to the community. This lends itself to critical adaptations and unforeseen customization.

Whether your mantra is launch early and iterate, or launch early and learn,

Mistakes seed improvement

in software product development.

That mistakes seed improvement is particularly true, and conspicuous, if your team is geared to

Turn feedback into function

within an iterative cycle, or two.

Further Reading

  • Agile Release Strategies – A wiki initiated by by Niklas Bjørnerstedt and Johannes Brodwall. The premise of the wiki is that a software product unable to release to production at least once every three months is problematic. That is, the longer the release cycle, the bigger the risk of partial or complete failure. Wiki includes principles and patterns. The wiki helps a Product Owner determine a Minimal Releasable Product.
  • Facebook encourages developers to push code quickly. Code pushes are never delayed and are applied directly to parts of the infrastructure. The strategy is to smoke out issues, and their impact, as soon as possible. (See Extreme Agility at Facebook).
For Italophiles…
English Italian
Release often and learn Rilascia spesso e apprendi
Release often and iterate Rilascia spesso e ripetutamente