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.

Software Teams, Comedic Improvisation, & Acceptance

Improvisation is an intuitive, coordinated, and spontaneous response to dynamic events. Improvisation is widely used in comedy, music, theater, and dance.

How might the techniques of improvisation be used in software teams?

In Blink, Malcolm Gladwell, author of the best-seller The Tipping Point, examines the structure of spontaneity. Gladwell observes that one of the critical rules of comedic improvisation is that the characters in skit accept everything that happens to them. He refers to this as the rule of steadfast acceptance.

Improvisation and Acceptance

Gladwell illustrates the role of positive acceptance with two improvisational comedy skits using the same comedic actors playing a doctor and a patient. The initial setup for the skit is that the patient’s leg is in pain. The first skit has a funny line, but quickly stalls out:

Patient: I’m having trouble with my leg.
Doctor: I’m afraid I’ll have to amputate.
Patient: You can’t do that, Doctor.
Doctor: Why not?
Patient: Because I’m rather attached to it.
Doctor: (losing heart) Come on, man.
Patient: I’ve got this growth on my arm too, Doctor.

Both actors become frustrated because the improvisation stalls abruptly. Why? Because the doctor offers a suggestion, “I’ll have to amputate”, but the patient rebuffs the suggestion, saying “You can’t do that, Doctor”

The following skit that Gladwell uses is more sustainable because the comedic actors agree beforehand to accept rather than negate any turn of events:

Patient: It’s my leg, Doctor.
Doctor: This looks nasty. I shall have to amputate.
Patient: It’s the one you amputated last time, Doctor.
Doctor: You mean you’ve got a pain in your wooden leg?
Patient: Yes Doctor.
Doctor: You know what this means?
Patient: Not woodworm, Doctor!
Doctor: Yes. We’ll have to remove it before it spreads
(Patient’s chair collapses.)
Doctor: My god! It’s spreading to the furniture!

The first skit peters out to a pre-mature end. The second skit opens up with possibility.

Steadfast Acceptance

How might our software teams apply Steadfast Acceptance to paired programming, architectural decision-making, or iteration planning?

Listen to – and carefully consider – your teammate’s suggestions

Has your suggestion been rebuffed while pairing on a programming task, or while a participant in a decision-making meeting, or while participating in planning an iteration? It’s a mojo-killer. Many people squash ideas with uncanny regularity. It’s destructive.

Should we consider taking our cue from actors trained in comedic improvisation who

accept all offers

to move the skit forward? Should we accept that none of us are truly smart enough to anticipate where our software skits will go?

Unilateralism is the bane of teamwork. I once worked with a talented programmer who consistently countered any suggestion or observation I made. It was baffling. To break the logjam I tried magnanimity. I enthusiastically agreed to his assertions, even when I thought my suggestions, or the ideas of others, had promise. It became poisonously unproductive. I resented his autocracy. I resented his lack of respect for alternatives. It clouded my acceptance of his best ideas.

Comedic improvisation teaches us to

  • Open ourselves to occasionally ego-compromising risks
  • Adapt to the immediacy of change with mindfulness
  • Improve our concentration skills
  • Improve our listening skills
  • Examine our responses to suggestions
  • Recognize that rebuffing suggestions is a mojo-killer
  • Consider steadfast acceptance as a practice (i.e., accept rather than negate a suggestion or a turn of events)

Tweet this Tweet this post