One of the questions I got asked a few times after last week’s post on recruiting was What are the consistent things you find in product designers you hire? In no particular order, here are some traits I care about and what I see in folks we wind up making offers to:
Great designers show the messy bits.
They show it because they know that’s what real design looks like and, honestly, the end result is so much less interesting than the path to get there. As designers, we’re natural storytellers and should look for the narratives in our own work. Awesome designers will show sketches that are full of crossed-out ideas, arrows to bits of UI with text asking “wtf?” They will tell you unabashedly how they started down one road and pivoted either based on data, new information or stakeholder feedback. They’ll talk about flows they were absolutely sure about, only to have them batted down by user research. Anytime a designer shows me a straight line from point A to point B, I think about how zero projects of mine have ever been so straightforward.
They own their work all the way.
This means the UX, the visual design, the front-end code and, hell, as much of the product as they can get their hands on. If they can’t code yet? They can’t stand it and want to learn. I’m not looking for specialists, I’m looking for generalists. I’m looking for people who will never say that’s not my job. I’m looking for designers who aren’t content with just throwing some work over a wall to their engineering team. They’d rather pair with their engineering partners, pitch in on the product strategy with their PM and help set up user testing sessions with their user researcher. They are participants and owners throughout the entire product development process.
They think about the design team as a whole.
Like our product, our company is always growing, shifting and changing. As our design team expands, having designers who care about process and culture will become even more important. Are the weekly critiques getting too bogged down? Our designers will let us know and bring some ideas (and we’ll address it). Are two teams doing intersecting work, but not aligning? Our team will reach out to each other and start forming connective tissue between the projects. Is someone stuck and needing some help? I want to hire people who will hop in a room and whiteboard for an hour to help out. I’m always blown away by the generosity of our design team. They give their time, their energy and their ideas to help make each other successful. That is a precious part of our culture and one we want to grow.
Solid work, low ego.
Their work is great. They rock user flows, iterate like crazy, have taste and know their way around a codebase. But despite all of that amazingness, they are not afraid of being wrong. It actually strikes them as impossible that they might be right on the first or second or even third try. They poke holes in their own work and graciously accept and genuinely consider peer feedback. They are unafraid of quantitative or qualitative data proving that their assumptions are wrong. In fact, they expect that and embrace those disciplines as part of the design process. They aren’t concerned with admitting I’m not sure, because it just means they’re not omnipotent. They judge their own work by how it’s used and not by how much time they put in. They don’t make portfolio pieces, they make useful stuff that, hopefully, changes people’s lives.
Admittedly, there’s not a lot in here about designy things like attention to detail, skills in a graphics editor, nor even user empathy. Honestly, if you’re applying to be a designer, those things should be a given. These are the differentiating details that span beyond being good at design. These are the details that go into building a solid, functional and scalable team. Details that, if we skimp on them, will make our jobs much harder and adversely affect the health of our product over the long term.
Want to help us build and scale an incredible design team? We’re hiring Senior Product Designers. Send me some stuff. :)
More by Cap →
Many new online-to-offline entrepreneurs have asked me about my experience founding Exec. “Uber for X” businesses seem to be the startup of the day – it probably helps that on the face they are less technically complex and more accessible to aspiring less-technical founders.
Exec (subsequently changed to “Exec Errands”) started off as us trying to fill my own personal desire for a part-time personal assistant / errand runner. I had enough random tasks that I wanted done and was willing to pay for, but didn’t have enough to pay someone full time. I tried hiring a shared assistant, but it was hard to get her to run same day errands on late notice. I tried Taskrabbit and Craigslist, but the bidding and selection process was too high friction to use for smaller, every day tasks. Eventually, we came up with the first version of Exec, which we described as “Uber meets Taskrabbit”, where anyone from the web or their iPhone could call an assistant who would immediately start running their errand.
On the backend, we had recruited a bunch of people looking for extra work to install our worker app and wait around for jobs. When someone put a job into the system, it would be offered to each errand runner in turn based on their proximity. When a job was accepted, the errand runner would get in touch with the customer, and start running the job. Early customers put in a wide variety of jobs, including dog walking, grocery pickups, temporary office work, and more.
Eventually, we dropped Exec Errands and turned Exec into a pure book-online house cleaning business, which was acquired by Handybook in January. Here are some of the lessons I learned in the early days of Exec Errands about online-to-offline businesses:
Unit economics matter a lot more than in pure software businesses. With Justin.tv, when we wanted to generate more revenue, we would look hard and figure out yet undiscovered places to shove another ad unit. Actual COGs (bandwidth and servers) were only ~30% of our gross revenue – most of our expenses were software engineers working on improving the product. With Exec Errands, we paid out 80% of the $25 / hour that we billed for errand runner time on job. That means that all marginal customer acquisition, customer service, and recruiting sufficient supply of errand runners had to be paid for out of that remaining 20%. Paying for mistakes (workers messing up a job) or customer refunds quickly ate up any profits.
Turnover of errand runners was very high. Most competent people are not looking for part-time work. The exception to this are people looking for supplemental income, but those people have full time jobs which conflicted with our high demand periods: mid-morning of the work week, Monday - Friday. Hiring new errand runners was expensive, and it was difficult to get them to stick around when we couldn’t guarantee work – the average utilization (time on the job / time available) was only 50%. Additionally, most of our errand workers wanted to work during normal work days, meaning there was an undersupply on weekends.
Demand was very spiky. It turns out that $20 / hour does not provide enough economic incentive in San Francisco to dictate when our errand runners had to be available, leading to large supply gaps at times of spiky demand. Without some form of Uber-like surge pricing, it was impossible to ensure that we had consistent availability.
Customer acquisition was hard. Lyft and Uber are viral online-to-offline businesses, because many of the times you call a ride you take it with others (who subsequently think it’s an incredible experience and download the app). Exec Errands was a not nearly as viral (and cleaning not at all), because you could use those services without ever telling anyone.
Customer activation was hard. Only about 10% of people who signed up for Exec Errands activated (put in at least one job request). When they heard about Exec, people thought it sounded like a cool idea, but rarely did they have an errand waiting in their back pocket that they hadn’t yet run – making it hard for them to try us immediately. This led to reduced activation rates and high customer acquisition costs (since fewer signups turned into actual customers).
We shouldn’t have run jobs ourselves. In the early days, if a job request came in and there were no Execs available to run them (as was often the case due to spiky demand), we sent someone from the office to run the jobs ourselves. We called that eating our own dog food and giving ourselves a sense of what could be improved about the product for both errand runners and customers. Unfortunately, this gave us a false sense that the quality of service for our customers was better than it was, as the average competence of our employees was higher than our average recruitable errand runners.
Verticalize. Ironically, Exec was very similar to Justin.tv in this way: the product got a lot better when we started focusing on a specific vertical, and surprisingly, grew much faster. With Justin.tv, we discovered that a small number of users were very passionate about gaming, and thus we started working on Twitch, a community based around watching gaming video, which seemed like a very small niche to us at first. Now, Twitch has 45 million monthly viewers, and is many times the size of Justin.tv. I failed to learn the lesson the first time around, and started Exec Errands as a general errand running site that you could put any job into, from shopping to cleaning to getting your car washed. When you do many things, it is hard to do any one thing well, and Exec Errands turned out to be a merely adequate tool for many jobs, but not an exceptional one. When we started focusing only on cleaning, we were able to vet workers against a smaller skill set, provide specific tools, and streamline the interface to make purchasing more intuitive and simpler (and thus increase conversions), resulting in much better growth.
As a programmer entrepreneur whose previous businesses were purely online, those are some of the things I wished I had known when first starting work on Exec Errands. Hopefully this is useful for you.
More by Justin →