Neal Conan: “You had solar panels (on your sailboat) for electricity.”
Matt Rutherford: “I did, but they broke.”
Neal: “They broke?”
Matt: “One by one.”
Neal: “I think you had a Kindle for reading books.”
Matt: “I did. It broke in a storm.”
I like Matt’s story for all that it tells as about our expectations and presumed requirements for a huge project we’ve never done before.
When I started out professionally the teams I worked on created deliverables; mockups, storyboards, sitemaps, taxonomy listings, content maps, wireframes, process flows, clickable prototypes, specification documents, usability testing, amazing looking proposals, Photoshop, timesheets. When I struck out on my own I assumed all of these things were required, so I packed them all with me.
Project after project I saw how each of these tools could bring as much confusion, delay, and tedious re-work as they could clarity. I saw how easy it was to iterate, debate, and perfect them, while losing sight of the project’s purpose and its promised business value. One by one, I stopped promising any specific design planning deliverable – other than a wireframe and a functioning web app. Then I dropped the wireframes. I eliminated all of this design planning documentation in favor of engaged conversations directly with the buyer that culminated in pen-on-paper sketches of how the key functionality should work followed by an estimate on when it’d be available to click-through.
Everything else? So much jetsam.
It’s not that I stopped doing the thinking encapsulated in those deliverables, the thinking became hyper-focused, hyper-prioritized on the core function of the project. If the core function couldn’t actually work nothing else will save it, not the color palette, not the logo, or which order the navigation labels are in. Hell, not even the project management methodology choice will save a project where the unique value proposition is neither.
The tools we actually need to be successful on a regular basis are so basic as to be taken for granted:
– trust in & respect for each other’s abilities
– clear, efficient, constructive communication
– absolute clarity in goals
– complete flexibility in execution
– a comfort with continual iteration
In this day and age, the rest can learned, negotiated, or rolled into the project as needed – whether it’s a project management philosophy, a unique software application, or a greater understanding of the subject matter. Presuming the four tools listed above are present, prior experience in the expected deliverables, vocabulary, or value chain of a specific domain is not only unnecessary but actually be counter-productive. Counter-productive to delivering the compelling innovation the creative team was assembled for.
Throughout its history, Apple – regularly cited as one of the most innovative and creative organizations – regularly dropped components presumed required for all computers; 3.25″ floppy drives, ethernet ports, optical drives, the ability to run arbitrary code.
At the time Google started getting becoming popular, having ads and headlines and other ‘portlets’ surrounding the search box was a presumed requirement for search engines.
Uber, Lyft, AirBnB dropped the presumed requirement that drivers/hosts needed to be licensed by the government.
Telsa, recently surpassed GM in market value, doesn’t have dealerships – a presumed requirement for an automotive brand by many states.
Yes, every one of these organizations is controversial for any number of reasons – but the very first one, the one deep down in their DNA is their bold dismissal of a presumed requirement around their core product.
So, yes I was disheartened when a Director at major employer confessed to me, “We don’t kill projects here.” For it meant a significant part of the organization was not yet boldly willing to separate the presumed requirements from the actual requirements far enough to spot the energizing, clarifying, innovation hidden in-between.
One of your presumed requirements is keeping you from growth. Do you know which one?