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.