Home » Design

The Capital Efficiency of Design

16. March 2009 by Thad Scheer 0 Comments
SPHERE OF INFLUENCE, INC. – software studios and services

Thad Scheer

 

The Capital Efficiency of Design

 

I don’t spend much time with VCs or investment bankers, but it’s evident from even my narrow contact that “Capital Efficiency” is today’s investment buzzword. Capital Efficiency is investspeak for running a tight ship, doing more with less, watching the burn rate; or, more technically, the ratio of average output to average expense. 
 
It is sad that VC’s only care about Capital Efficiency when there is a scarcity of capital…but that’s a topic for another blog. 
 
I guess in this climate it’s proper to ask: If you build software (or something with software in it) what approach offers the best capital efficiency?
 
I’ll claim that excellent capital efficiency can be had by applying Design Thinking to software. The goal is to launch on a fixed schedule something that people will buy, and that you sell at a profit with the least capital invested.  Mixing Design Thinking with Agile is the way to go.
 
Let’s limit the discussion to the following choices of approach:
 
Choice #1: Product design using traditional requirements-based systems engineering.
 
Choice #2: Product design using Agile’s show me don’t tell me approach.
 
Choice #3: Product design with capital-D design as a first class citizen.
 
The following analysis applies IF there are humans using or interfacing with the finished software. If software is strictly “black box”, i.e. hardware drivers, electro-mechanical control, etc. then there is a different analysis and conclusion.
                
Choice #1 typically produces a likable result not until Version 3.0 of a product.  Technology innovation on these projects can be high, but overall product experience usually stinks at Version 1.0. Dev-to-launch timetables often slip schedule and cost 100% or more. Despite the formal reviews, stage gates, and top-down control, projects driven by requirements are poorly fit to the world they deploy in.  A Version 2.0 release usually addresses feature gaps and repairs bugs. Version 3.0 releases can make customers and users happy, if the product lasts that long.  This is low capital efficiency, typical of (and I hate to say) government projects.
 
Choice #2 almost never rolls a gutter ball, but isn’t conducive to high-impact innovation, likeability, or cohesiveness.  Agile, the way most practitioners use it, is the shortest path to mediocrity in terms of product design and innovation.  Given that half of all products are below average, that ratio doesn’t change with Agile.  The show me don’t tell me approach produces a lot of two-steps forward, one step back churn.  The good news is that Agile projects can hit a fixed schedule and launch “something” on time.  Not the best capital efficiency, but marginally better than Choice #1.
 
Choice #3 is all about having excellent Product Experience (Px) out of the box, focusing on innovation and differentiation.  It consumes schedule, but only by consolidating what otherwise would have been spread out during multiple iterations or version increments.  This is the high capital efficiency choice and the path people take when they must “launch to win”.
 
Remember, capital efficiency isn’t just about cost cutting; it’s about improving the utilization of capital. Cutting costs against a fixed output improves capital efficiency.  Increasing output against a fixed cost also improves capital efficiency.  Doing both is the Holy Grail. By applying Design Thinking techniques to software we significantly cut the expense of design iteration and reduce the number of coarse iterations, thus cutting input costs. It also radically improves the cohesiveness and acceptability of the finished product, thus improving output [radically].
 
What’s different about Choice #3, Design Driven projects?
 
Design, at this level, is all about the “fuzzy front end”, focusing on differentiators and product innovation people will respond to.  What features? What experience? What innovation?  What aesthetics?  Projects start with intense font-end ethnography (i.e. special type of field research). This is not a poll or focus group of customers; but a systematic approach to discovering something new about customers that nobody has exploited before.  Agile might embed a customer on a project, but Designers go to the field and embed with customers.  Ethnographic research feeds a formal process of creative agitation and design, where the goal is to stimulate creative collisions and innovate at a product level. This isn’t just putting working software in front of customers and asking them what to change, this is about inspiring and driving innovation.  Designers will make a product “cohesive”, meaning the elements will be crafted to work together in a complimentary and consistent way.  Finally, this feeds either a traditional system engineering process or, as we prefer, an Agile process for additional design and assembly.
 
It doesn’t matter how well your product is made, or how well managed your project is (as Theresa pointed out), if your result is unlikeable, un-innovative, or the wrong thing…you have extremely low “capital efficiency”.
Comments are closed