Framing Product Development

Language helps us to frame problems and challenges.

George Lakoff introduced me to how language frames arguments in the political sphere.

Today I attended the DevJam simulcast of the Startup Lessons Learned conference. This global meetup was the brain child of Eric Ries. Eric coined the concept of Minimum Viable Product and is the cheerleader of the lean-startup movement.

Minimum Product

Now I have heard of

  • Minimum Viable Product;
  • Minimum Desirable Product; and
  • Minimum Feasible Product.

It seems all the Minimum Product ideas are hypothesis-driven approaches to product development. That is, with a product hypothesis, or hypotheses, one builds as much as needed to test the product hypotheses.

One of the take-aways I got from Startup Lessons Learned is there are several ways to linguistically frame software product development. Viable, Desirable, and Feasible are Framing words – they frame how we think of our product development.

Andrew Chen, a conference panelist, introduced me to Minimum Desirable Product. Minimum Desirable Product is the simplest experience necessary to prove a high-value, satisfying product experience.

Andrew adds Minimum Feasible Product to the mix, then distinguishes differences between Viable, Desirable, and Feasible.

Viable think business
Desirable think user experience
Feasible think engineering

Desirable hits my sweet spot.

Viable, while helpful, has a air of life support about it. Feasible, also helpful, has a hint of the analysis-paralysis syndrome.

Desirable Resonates

Desirable resonates because it implies an emotional reaction. Emotions spark viral movements. Startups, like viral movements, are predicated on reaching a Gladwellian Tipping Point.

The inventor’s challenge is to change minds & behavior.

In Switch, Chip and Dan Heath argue for appealing to The Elephants and The Riders. The emotional side of change is The Elephant. The rational side of change is The Rider. They say,

“The Elephant’s hunger for instant gratification is the opposite of the Rider’s strength, which is the ability to think long-term, to plan, to think beyond the moment.”

Our software products need desirability at their core. They must inspire and appeal to emotions – to satisfy The Elephants in us, but then, over time, they must also provide lasting value – to satisfy The Riders in us.

Start with the goal of desirable. Desirable gets us into the game.

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.


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.

Quality’s Okay, But Who’s Paying the Freight?

One of my favorite truisms used to be
good software ain’t cheap and cheap software ain’t good
It’s a parallel phrase that seems to ring true. I appreciate a catchy chiasmus as much as anyone, but now this aphorism seems like a marble in a rock stack.
Lets face it, sometimes cheap software is good. How often do we balance expeditiousness with quality?
Demand for our software services is throttled by the people who buy the products. It is almost always our charge to strike a balance between cost and quality constraints. Dogmatic pursuit of quality might be persceived as gold-plating. The economic reality is

selling software is a prerequisite for being paid to build software
Two observations about expeditiousness and software quality are:
  1. Often teams are faced with a simple choice: more features or higher quality (e.g., refactoring, paying down technical debt, bug fixes).
  2. Often that choice of more features or higher quality is determined by whether your product is a greenfield start-up or you’re supporting an established, public-facing product.
Start-up Product
In the context of a greenfield project or a start-up product, I have been introduced to the concept of Minimum Viable Product or MVP.
In Minimum Viable Product: a guide, Eric Ries explains that an MVP is made to elicit feedback. He defines it as

a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort ~Eric Ries

Kent Beck discusses Eric’s approach in Approching a Minimum Viable Product where he uses MVP to address critical product assumptions, and to illuminate the unknowns, for his new product Tattlebird.
Presumably some degree of quality is sacrificed to get answers. The value of expeditious answers supercedes quality issues like user experience or reskinning a user interface.
Established Product

On the established, public-facing product front, Anna Forss wrote about establishing the notion of business value for bug fixes to the sales organization of her customer (cf. what value does bug fixing have for sales?).
Anna poses Fred Reichheld’s The Ultimate Question
How likely is it that you would recommend product X to a friend or a colleague?
In the context of an established, public-facing product, she suggests that
…bugs create more detractors than features create promoters ~Anna Forss
In this content,
Value = Promoters – Detracters

Higher quality (user experience improvements and bug fixes) provides real value; in some cases more than new features. Sometimes error-free operation and usuability trumps new features.
If there’s no need to walk the goldfish, use a fishbowl. ~Bobtuse
Given the context (startup or established), I understand the need to balance expedience and quality. As long we are focused on who’s paying the freight and that their goals jibe with our mode of operation.