“There are myriad great ideas, but great execution is a rarity.” --Everyone
If you’ve ever tried to start a company, you’ve heard a thousand variations on this admonition--because it’s true. While you might secretly harbor the notion that your idea matters a lot more than the herd supposes, you also know that great ideas inevitably die without great execution.
For company leaders, there are a plethora of resources that describe best practices in hiring, raising cash, and culture building. For product-focused leaders, it’s easy to educate yourself on the characteristics of gorgeous design, smart UI, high-performing technology, and piercing data analysis. And yet, while we know plenty about what great products look like, there is a relative dearth of accessible resources about how great products actually get built.
This series of articles is about great execution in the product development process. I’m trying to shed light on the question: How do people make products that people love?
I will outline both a philosophy of product development process--which I hope applies across a broad range of industries and organizational sizes--and details about how one can apply this philosophy in a small- to medium-size Internet company.
Theory and practice--they both matter. Without a strong theoretical framework, even the best processes will bend and break under the weight of scaling, changes in strategy, shifting team composition, and so on. Further, a strong theory of product development processes will infuse the work of making products with the energy and perspective needed to delight your customers again and again over time. And of course, theory without practice is, well, the stuff of epic execution failures.
At the center of my philosophy of product development is the idea that your task as a product leader is to ensure that every single person on your team is constantly unblocked, or completely empowered to do breathtakingly great work in alignment with your company’s goals. This happens--and wonderful things get created--when your team is driven by radical curiosity and a relentless orientation towards perpetual learning and improvement.
The processes described here have been crafted and refined over years, primarily through my experience building HowAboutWe.com. HowAboutWe is the only company in the world focused on helping people fall in love and stay in love. As co-CEO, I am responsible for making top-notch products; I lead our design, engineering, and data teams.
It’s no mistake that I’ve become slightly maniacal about process. We created HowAboutWe utterly from scratch; we had zero directly applicable background or training. To succeed we had to learn quickly and never make the same error twice. So, we put processes in place designed to facilitate constant learning and iteration. Indeed, we constructed processes that themselves improved through their very use. So far so good: Every new thing we’ve built has been better than the last thing we built.
The processes I will describe here solve many of the thousands of micro-problems that arise as you’re rapidly building something in a highly competitive environment, and reflect hundreds of conversations I’ve had with expert makers from many industries. But they’re also somewhat homegrown, like most good things. In a sense, I’m just trying to put into writing how a bunch of smart people in a loft in Brooklyn are trying to help people everywhere “fall in love and stay in love.”
Before diving into the nitty-gritty details of how great products are built--roadmapping, dev sprints, design flow, and data feedback loops--I’m going to outline 10 principles of product development process.
- Processes are the circulatory system of a company.
Great processes bring rich blood to every aspect of product-making and company-making; they enrich everyone’s creativity, strategic thinking, productivity, and motivation. Great processes help to ensure smart, wasteless action; they not only support every single person in your company to excel, but also create a radical collaborative effect that exponentially multiplies the power of your team.
Conversely, bad processes yield bad blood: deoxygenated, nonimmune, sluggish. So you must--and this imperative is the central thrust of this series--become f%@$ing amazing at process. Your product and company’s life depends on it.
- Curiosity is what gets things done.
The staple of most product teams is: GET THINGS DONE! HIT DEADLINES! SHIP ON SCHEDULE! Don’t get me wrong; I believe very strongly in getting things done on time and in working your ass off. But I also believe that the most effective source of effective productivity is actually curiosity--the insatiable drive to learn. If you build your product development process around this core human drive you’ll discover that curiosity unleashed is a lion, not a sheep. Curiosity is the exponential rocket fuel that makes great product teams hum.
- You are a scientist running experiments.
Stop thinking about yourself as a businessman or product guy/gal or designer or whatever you think of yourself as. You are a scientist. Your essential methodology is the scientific method: Hypothesize. Build. Learn. Iterate. Repeat. This is curiosity, manifest.
Every single person in your company should feel that they are traversing an upward spiral of effectiveness in which everything they build--whether the immediate outcome is positive or negative--is a success because it will yield the smartest possible next move.
You are all scientists and your creed is: If we don't learn, we die. If we learn, we thrive and others benefit.
- Processes are also products.
Start thinking of your processes as the most important product you are building. Approach their creation accordingly: develop them collaboratively; assess them relentlessly; iterate tirelessly; repeat.
Building great products is difficult. Likewise for great processes. Good process thinking is not a skill with which most people are naturally endowed. You should cultivate in yourself an allergic reaction to bad processes; try to experience them as the weird form of modern industrial abuse that they are. (I’m not joking.) And then fix them. Inertia says no one else will.
- Great processes constantly evolve.
There is no such thing as a universally perfect process. Anyone who says so is a narcissist or a fool.
You need to transparently evolve your processes along with (or one step ahead of) your context. This is particularly critical in a shifting context (e.g., when your company is doubling in size every six months).
The most painless and effective way to evolve your processes over time is to build into them structures that ensure perpetual improvement. A process that doesn't evolve will become rigid and sallow. A process that grows of its own accord will inspire trust and generate ever-increasing velocity.
- Pick smart tools.
A lance is good for some things and a dagger is good for others; you shouldn’t have just one weapon. Find the best tools for your tasks and master those. Build the tools you need that don’t exist and master those, too.
- Make your processes invisible.
Given the choice between more or less process, I clearly sit on the “more is better” side, but this doesn’t mean wasting time or being anal or getting trapped in bureaucratic tomfoolery. Smart processes should be nearly invisible. They should be built into people’s natural workflows. They should be as asynchronous as possible; you should walk around with an implicit fear of bad meetings. Great processes shouldn’t yield maniacal attention to detail when detail isn’t what’s needed. Great processes should result in rapid, effective decision-making. They should generate consensus but not waste time doing so.
“More process” means more attention to what matters and less to what doesn’t.
- Don’t forget the human part.
Processes are most obviously comprised of the concrete systems that give structure to our workflows. But they are equally about more subtle behaviors like how you approach listening, the attitude with which you hold the helm, the way you empower individuals to become their best, the trust you inspire in people that anything broken will get fixed, etc.
In this series I’ll be focused almost entirely on concrete systems. But I urge you not to forget this second, more human aspect of great product development processes. Great things get made when people are inspired, and inspiration needs tending, like a bonsai.
- It’s worth the effort.
The stupendous energy it takes to make your processes whirr is completely worth it. Great processes will improve every aspect of your work, from low-debt code and breakthrough design to palpably high morale and tactical agility. Your team will become happier, smarter, and more productive. And, most importantly, your product will more effectively serve the people using it.
So take it upon yourself to make sure everyone knows what they need to do, has what they need to do this, and understands why doing it will help the company achieve deep, inspiring goals.
- Stop fearing failure.
Fear of failure is the enemy of growth and ingenuity. Growth requires doing things whose outcome cannot be predicted, and learning requires failing. Show me a successful man or woman who isn’t riding into the sunset on the horse of failure.
But the prospect of failure is very scary for most people. There are a hundred psychological and socio-cultural reasons for this. So, my point here isn’t about your emotional state, though I urge you to convince yourself that the future will always be better than the present! Instead, my point is that your actions as a product leader should never be guided by fear of failure.
Build process that let failure be an acceptable--even celebrated--source of fuel for your next victory. Fail fast and fail effectively and the future will feel full of hope--hope which will be validated as time passes.
The rest of this series consists of granular descriptions of product development processes. At times this may seem overwhelmingly detailed. I’ve chosen this approach because the efficacy is in the details. Anyone running a product team has to solve the myriad micro-problems that the details I describe are designed to solve. I know that this will alienate/bore some readers, but I’m writing this series with pragmatism in mind, and with the hope that the people who attempt to implement these systems will benefit.
This series will cover four core topics:
- Design Flow
- Engineering Flow
- Data Flow
Since Engineering Flow is a biggie, we’ll tackle it in several parts. In total, the series consists of seven parts. You can navigate between them below.
The processes described here are just one way of doing things. In a year the product development processes at HowAboutWe will almost certainly have evolved significantly. And there are certainly other ways of working that are equally (and very possibly more) effective--check out the list of titles at the end of the first part of this series for further reading compiled by the editorial team at Fast Co. I look forward to reading the comments!
If you have specific, directed feedback on this series--particularly suggestions on ways to improve my process thinking or my writing--then I’d really like to hear from you. You can email me at firstname.lastname@example.org.
I consider myself and HowAboutWe part of a community of people who are trying to make the Internet a beautiful place; and so my hope is that this series of articles inspires you to love and respect process--and to make your processes elegant, ever-evolving, and radically productive.
Click here to read the next article in this series: Value-Driven Product Development: Using Value Propositions To Build A Rigorous Product Roadmap
Part 2: Value-Driven Product Development: Using Value Propositions To Build A Rigorous Product Roadmap
[Photo by Opensourceway on Flickr]