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.

Definable & Measurable Software Value

In the race between How Fast? and How Valuable?

• the former might be an ingredient of the latter, but 
• the former should never win at the expense of the latter.

Remember

We can get to crap-shack in a hurry.

I want to be meticulous about the meaning of value. It's not easy, but the challenge should inspire.

Value differs with every project. A pattern of define and measure is necessary.

Define and Measure

On every software team I have been on, we ignored the objectively measurable for the sake of expedience, then married How Valuable?with wild-assed guesses -- our guesses, or those of the business.

I am ready for this to stop.

The challenge is marrying How Valuable? with verifiable data. An example of what I mean would be to equip our teams to address and react to concrete questions like

• What's our retention rate following the new feature?
• How many new users did we enroll?
• How many units did we sell?
• Did our community react favorably to the change?
• What are 3 pain points for our user community?
• What are 3 beefs our user community has with our software?
• Has the volume of help desk calls changed?

Whenever questions like these are asked, the follow-up is How much do we care?

The Next Project

So, I'm thinking about my next project. Here's my to-do list so far:

1. Lobby for a discussion of what's valuable
2. Continually challenge team members about what's valuable
3. Sustain a living definition of what's valuable
4. Find ongoing means to measure and demonstrate value
5. Be a rat terrier on the heals of lazy, unclear, or incomplete value definitions
6. Be a rat terrier on the heals of value definitions that can't be verified
7. Push to collect data to verify the iterative addition of value
8. Prepare to react to feedback from data collection
9. Limit back-patting in retrospectives simply because stories were completed
10. Limit back-patting in retrospectives if incremental value cannot be proved
11. Challenge "Product Owners" or "The Business" when notions, laziness, or any lack of commitment toward proving value prevails

Scrum's Achilles Heel & Where Scratch Meets Itch

Anders Storm, Head of Development and IT at Tekis AB, posted a cogent reminder of all that's good about Scrum (see Anders' post Why I Like Scrum! on his blog Product Development).

Scrumbaya (like Kumbaya)

Anders and I share many of the same likes about Scrum. Scrum was my first step into Agile (thanks Markus). I started a jaded curmudgeon (my apologies Markus), but my Scrum-mates revolutionized my thinking. I am grateful to the pioneers of Scrum.

I like Scrum for its humanity, accountability, explicit trust in programmers, and inherent fairness.

Needs Improvement

I have one criticism of Scrum, but it’s a big one…

The Achilles Heel of Scrum is the Product Owner. The Product Owner is a serious flaw in the approach. In my experience, Product Owners operate on notions about what’s most valuable (what’s a high priority), rather than on verifiable data.

The Scrum community applauds itself for its transparent burn-down charts and their inherent "velocity" when what they’re actually transparent about is speed (e.g., because the direction component is sorely missing).

It bears repeating that

It doesn't matter how fast we deliver, if we deliver junk.

Verifiable Value

Scrum must evolve beyond the concept of a limited user proxy, like Product Owner, then figure out ways to better understand, measure, and verify the user experience.

In almost all cases I can think of,

the people actually using our software is where the scratch meets the itch. 

Our goal, as always, is to produce incremental value. But in this case, it comes via verifiable value (direction) and not just speed.

I am looking for ways to get to Verifiable Value and to limit Seat-of-the-Pants Guesses.

More

• People in the agile space who are in the forefront of understanding “direction” and “discovery” and “user experience”, rather than simply iteration speed are Alan Cooper, Jeff Patton, and David Hussman.
• My post Software Value Verification.

The Notorious B.O.B.

Remember Microsoft Bob?

You know, Microsoft's non-technical desktop interface for Windows 3.1 easy enough for a chimp to use after a smoke break?


Kids and curious onlookers are riveted at the sight of a smoking monkey. But later, after the monkey extinguishes his Camel and saunters up to his Bob-powered word processor to tap out

It was a dark and stormy night

the crowd goes ape-shit.

Bobtoriousities

• Bob won 7th Place in PC World Magazine's list of The 25 Worst Tech Products of All Time.
• Bob won 1st Place in the Top 5 Worst Products of the Decade made by CNET.com.

It's not all bad for Bob. The Microsoft Bob project was managed for a time by Melinda French, who later became Melinda Gates - which is a silver lining of sorts.

There are many note-worthy Bobs in history. There is English poet and dramatist The Bard of Avon, also known as Bobspeare. There's American rapper, and former honorary mayor of Brooklyn The Notorious B.O.B. And, would explorers Lewis & Clark ever have found the west coast without their loyal Shoshone companion Bobajawea?

Bobalicious Legacy

I have a soft spot for Bob.

Remember that yellow dog - Microsoft Bob's Rover? Rover is still found in Windows XP search. And today, I have two golden retrievers. Huh?

Bob's mugshot is now found in Windows Live Messenger as an ever-studious Smiley. Face it, Bob's face has become an icon.

The font Comic Sans was created for Bob circa 1994. Now Comic Sans is one of the most famous fonts in existence.

Failure usually has a flip-side.