“We must figure out a way to un-invent this food system.”
—Mark Bittman is always worth reading on the topic of food, and I loved this op ed, Fixing the Food Problem, in the New York Times in which he makes the case for both a systematic re-imagining of the way in which the food we consume is produced and distributed and our need to be patient while we do so. Reminiscent of Bill Buxton’s Long Nose of Innovation theory, it also reminded me of a conversation with an executive working on trying to innovate healthcare: laying the foundation is important and unflashy, she told me, when I was trying to figure out a story angle to impress both my editors and readers. As she explained, she wouldn’t be able to give me the all-important results or payoff on which I could hang my story of the progress of her work, because she wouldn’t know them herself for a decade or so. So that stopped me.
We’re all too impatient to see the fruits of our labor. This piece reminds us that every step we take is important, not just the ones when we triumphantly cross the line at the end of the journey. (And, of course, the end is never the end, anyway.)
Listen
Notes from listening to the Eric Ries’ lecture at Stanford, for my Entrepreneurial Design class in the MFA Interaction Design program.
The Lean Start up is a vision for how our industry (the start-up industry) can be different.
The Myths vs. the Reality-based Model of Entrepreneurship
Myth 1: The “start-up dollhouse fallacy” - a start-up is not a shrunken company. It isn’t just a miniature version of a traditional company.
What’s a startup? Eric’s definition: A human institution designed to create something new, under conditions of extreme uncertainty.
Fundamentally, entrepreneurship is a management science.
As we test our ideas against reality, we discover there’s value in our (almost invariably) poor initial ideas. But we can only discover these through testing them in reality!
Iterate quickly, which allows us to discover the kernel of value in our ideas quickly, before we run out of money. That’s why we pivot.
Myth 2: The “IQ theory of entrepreneurship” - put together the smartest people, and it would simply succeed! Erm, no. You can get flawless execution, smart product, but be crippled by shadow beliefs.
Shadow beliefs
Shadow beliefs ruin startups by wasting their resources.
1. “We know what customers want.” - In reality, we don’t. We rarely build things for people like us.
2. “We can accurately predict the future.” - It’s even worse if we act concretely about these prediction.
3. “Advancing the plan is progress.” - but we didn’t have a way to measure if the plan is actually any good.
Why talk to customer?
Visionary customers are often smarter, and more visionary than the founders themselves.
The pattern is the Lean Start-up. It has three pillars, which allows Lean Start-ups to move faster.
1. “Commodity technology stack.” - It’s cheaper, but more importantly it is faster. Leveraging existing technology to iterate quickly.
2. “Customer Development.” - Four Steps to the Epiphany, by Steve Blank. Iterating on finding the right problem to solve.
3. “Lean Product Development.” - Iterating on finding solutions.
In almost all high-tech product development, neither the problem nor the solution is well known, and thus cannot be modelled. In these instances, the waterfall methodology of development fails.
Iterating on finding solution e.g. Extreme Programming => Collapse the feedback cycle. e.g. Take an in house customer, sit them next to engineers, and get real fade back. This works is when the problem is known, only the solution is unknown.
Iterative { product && customer } development
But in a start-up environment, even this is not enough. You don’t even know what the nature of the problem is. Who do you site down beside your engineers?
This is where iterative customer development comes int. Tie the iterative customer development process together with iterative product development into a company wide feedback loop. This changes the unit of progress (the unit of feedback) in an interesting way.
The biggest source of waste in a start-up is building something no body wants. (Eric’s e.g. is the technically powerful instant messaging interoperability software in IMVU, built to leverage network effects that wasn’t there.) This kind of waste is not a technical (read: engineering) problem. Start-ups don’t fail because because technology fail, its because they built things people don’t want.
They could have found out ahead of time.
Eric’s suggestion: One cross functional problem team, trying to answer the questions,
“Who is our customer? What problems are they trying to solve?” i.e. Customer development
… and simultaneously have a solution team that’s answering the questions,
“Is the current hypothesis for our product any good?” i.e. Product development
OODA loop
We need to measure every change against this question, “Does this change optimize how quickly we can go through a feedback (i.e. learning) loop.”
A few metrics as possible to get through this feedback loop. This is why continuous deployment is useful.
Why all the trouble to build a continuously deploying system? Because if the change/revert process is easy enough, you can combine it with a system with intelligence and sensors to monitor the business metric. In turn such a system combination could revert clearly stupid changes like making the checkout button invisible.
This is essentially a defence/immune system for your product.
Minimal Viable Product
What’s the best way to get the initial feedback loop going with those visionary early adopters? The worst fate your minimal viable product can suffer is that it gets no feedback. Which is not so bad.
What does that get you? It allows you to ship without spending time on features that perhaps no one cares about. It also allows to start talking to customers about features they think is missing, so you get crucial information about what you should start building.
Five Whys - what’s the root cause?
If you never learn the human problem problem behind the engineering problem. Behind every supposedly technical problem is a human problem.
Eric’s example: A check-in that crashes the server turns out to be a training problem.
You investigate the problem using the five why’s, but you don’t necessarily address the root problem by taking the next five weeks to focus on it. You try to address it in as small a chunk as possible - maybe an hour at a time.
You can then accumulate effort the next time the same root problem is discovered.
Questions Period
We are moving away from technology risks ventures, to market-adoption ventures, and this is where iterative customer development becomes important.
Crafting an institution such that the { process | culture | environment } enables people to consistently make good decisions (on average.) That’s the way to build lasting value.
Pivoting, and testing, prevents us from working really hard and being really clever on the wrong product.
By definition, if you’re a start-up, the only customers who are willing to talk to you at all are early adopters, and they see a vision for your product.
Great entrepreneurs don’t have better ideas, they have better process.
Hello from AIGA Pivot!
If you tweet, follow #aigapivot or me at #aigadec, tweeting for aiga design educators.
At Hugh Dubberly workshop on designing complex systems. Check out their firm’s work: http://www.dubberly.com/concept-maps/creative-process.html
“[Set-top] boxes consumed $3 billion in electricity per year in the United States... That is more power than the state of Maryland uses over 12 months.”
—Atop TV Sets, a Power Drain That Runs Nonstop looks at a recent report from the Natural Resources Defense Council, which described the assorted electrical boxes people have installed on their TVs as “the single largest electricity drain in many American homes.” The article goes on to remind readers that this “always-on” state is not an oversight. Rather it’s entirely by design; the manufacturers catering to their belief that consumers would not tolerate the time it takes to reboot on a daily basis. Alan Meier of the Lawrence Berkeley National Laboratory has the money quote, saying of the industry:
I don’t want to use the word ‘lazy,’ but they have had different priorities, and saving energy is not one of them.
I’d go ahead and use the word lazy, and probably add a few other choice words too. Nonetheless, there’s clearly an interesting opportunity here.
“Design has multiple characteristics. Designers have been good at reframing, good at thinking of things in unusual ways, good at visualizing, and systems thinking. But “design thinking” as it has been marketed implies that design was a mindless activity until 10 years ago; it’s time to reframe the term “design thinking.”
— Patrick Whitney
Extreme Engineer
This guy takes being an engineer to new extremes.
http://webspace.webring.com/people/bm/madsquopper/syspaper.html
I sent this article to my husband and asked what he thought.
He just laughed.
Do you see what I am up against?
Devops, complexity and anti-fragility in IT: An introduction
#SuryaRay #Surya Some time ago, my friend Phil Jaenke and I (and a few others) got into a debate on Twitter. The discussion started as an exploration of the changing nature of software development, operations and change control, and whether they are good or bad for the future of software resiliency. It resulted in a well-articulated post from Phil, arguing that you can’t have resiliency without stability, and vice versa.
However, as I started trying to outline a response, I realized that there was a lot of ground to cover. The core of Phil’s argument comes from his background as a hardware and systems administration expert in traditional IT organizations. And with that in mind, what he articulates in the post is a reasonable way to see the world.
However, cloud computing is changing things greatly for software developers, and these new models don’t take kindly to strict control models. From an application down perspective, Phil’s views are highly suspect, given the immense success of companies like Etsy and Netflix (despite their recent problems) have had with continuous deployment and engineering for resiliency.
Reconciling the two views of the world means exploring three core concepts required to understand why a new IT model is emerging, but not necessarily replacing everything about the old model.
The first of these concepts is devops, which earned its own three-part series from me a few years ago, and has since spawned off its own IT subculture. The short, short version of the devops story is simple: modern applications (especially on webscale, or so-called “big data” apps) require developers and operators to work together to create software that will work consistently at scale. Operations specifications have to be integrated into the application specifications, and automation delivered as part of the deployment.
In this model, development and operations co-develop and very often even cooperate, thus the term devops.
The second concept is one that I spoke about often in 2012: complex adaptive systems. I’ve defined that broad concept in earlier posts, but the stability-resiliency tradeoff is a concept that is derived from the study of complex adaptive systems. Understanding that tradeoff is critical to understanding why software development and operations practices are changing.
The third concept is that of anti-fragility, a term introduced by Nassim Nicholas Taleb in his recent book Anti-fragile: Things That Gain from Disorder. Anti-fragility is the opposite of fragility: as Taleb notes, where a fragile package would be stamped with “do not mishandle,” an anti-fragile package would be stamped “please mishandle.” Anti-fragile things get better with each (non-fatal) failure.
Although there are elements of Taleb’s commentary that I don’t love (the New York Times review linked to above covers the issues pretty well), the core concept of the book is a critical eye-opener for those trying to understand what cloud computing, build automation, configuration management automation and a variety of other technologies are enabling software engineers to do today that were prohibitively expensive even 10 years ago.
So, over the next few weeks, I will try to explore these concepts in greater detail. Along the way, I will endeavor to address Jaenke’s concerns about the ways in which these concepts can be misapplied to some IT activites.
Please join me for this exploration. Use the comments section to push back when you think I am off-base, acknowledge when what I say matches what you have experienced, and, above all, how you think about how your organization and career will change one way or another.
As always, I can be found on Twitter as @jamesurquhart.
_Feature image courtesy of Shutterstock user Sinisa Botas._
What is Social Alchemy?
The design of living systems with social good intent.
A gardener’s intent when she/he cares for plants is to see them grow. Often she wants them to grow a certain way.
The Gardner’s intent caring for the plants is based on his perception of the ecosphere and his own perceived personal identity.
He understands that they are one, she understands the interdependence of all things and designs accordingly.
“It’s time to address the calamity that is Penn Station.”
—Anyone who’s ever had to negotiate rush hour in New York’s busiest transit hub will surely raise a cheer for this statement, in the article, Restore A Gateway To Dignity, by New York Times architecture critic, Michael Kimmelman (who’s really doing a standup job in his newish role.) The station is a monstrosity, a fire hazard, a nightmare of frazzled commuters and colliding wheely bags… and Kimmelman has a suggestion for a new plan. It’s not entirely out of the question, though any significant change is years away. But one can dream, right? (For those in New York, Kimmelman is speaking in the D-Crit speaker series at the School of Visual Arts on February 14th.)Pause for thought
These days, if I were to write code it would be Java or even Haskell, and I would design the heck out of the system using UML, incorporating design patterns. Given half a chance, I’ll specify the operations formally, using OCL; and if you give me total freedom, I’ll specify it in Z (i.e. symbolic logic and set theory) and mathematically prove the design before coding.
Some of the software engineers that I’ve taught absolutely love this approach. They’re the ones who, if their software fails, have to live with the fact that someone has probably died.
Interaction design, not information technology
fastcodesign.comRobert Fabricant on lessons from judging the IxDA awards.
Note to self: Look at the emphasis he places on interaction design as the design of a system through which a user/actor acts. An interactive system is an information space, and the designer through arranging the space makes actions possible.
Technology helps, but interaction design is more about what action your design makes possible. As much fun as the technology may be, it is not and cannot be the focus.
Technology-in-itself is not what customers want. New affordances are.
