CEO’s can be a tough group to design for – after all, it’s their vision with which you are now entrusted. I’ve been fortunate enough throughout my career to work closely with several CEO’s. From fledgling ideas to high-growth companies like TheLadders (where I’m the Director of User Experience), I’ve whiteboarded, wireframed and prototyped my way through a wide array of exciting ideas side by side with the minds who created them. Along the way I’ve picked up a few tips and tricks that can make your next startup design gig that much more successful.

Without further ado:

1. Call their baby ugly – Yes, it’s their idea. Yes, it’s their hope for their future. Yes, it’s their dream. But if it’s a bad idea or the product strategy seems wrong, tell them. If their minimum viable product is, well, not so viable, tell them. If the first designer they teamed up with sold them a sack of hammers, tell them. You’ll be doing them a favor and earning credibility. Telling it like it is makes it clear that you are not placating them simply because they have an idea and a term sheet.
2. Get to know the industry – Whether it’s online dating or concert tickets, the CEO knows the space. They live and breathe it and if you want to understand your audience, build targeted experiences and convince your CEO these solutions will work you must understand the domain. Check out the competition. Read the stats. Understand who the big players are and who just got funded. If you can contextualize your design not just within good interaction design criteria but within your industry, you’ll succeed far more often at promoting your best thoughts.
3. Drop some knowledge (do the kids still say that?) – CEO’s tend to know a lot about a lot of things, including design. However, they’re rarely design experts. This is where you experience can shine. Facing a challenging workflow? Call upon a similar challenge from a previous engagement. Analyze how a successful experience got it right and what you can “borrow” from them. You’re the expert. Show it.
4. Speak their language – It’s critical to understand how your CEO consumes information. Several of the ones I’ve worked with feast on data. If that’s the case for you, embrace it. Gather the data and show how it proves your case. If that’s not available use that to drive home the need for qualitative and quantitative testing. Making grandiose artistic arguments for your design will most likely not resonate with a CEO. Get to the point in a language they understand.
5. Work quickly – This is a startup after all. Spending time pitching and then executing months and months of user research, persona creation, deep user analysis and competitive analyses only delays getting software in front of customers. I’m not suggesting there’s no value in these activities. What I am suggesting is that you execute repeated abbreviated versions of these tasks. Work quickly and get software in front of customers. Get feedback. Fold it into your existing research and iterate again.

These tactics are not unique to designing with CEO’s in a startup environment. They’ll work in many environments but if you’re lucky enough to be working closely with the CEO employ these tactics to maximize your success and the success of the product.

[Jeff]

I just finished reading @37Signals product design/development manifesto, “Getting Real.” I came out on the other side of this read so full of energy — motivated to go back to work in the morning, fire everyone except my favorite developer and product person (I’d do the design, natch) and set out to change the world with a kick-ass product. The no specs, get-it-out-in-the-wild and iterate, evolve and grow into something huge approach was the breath of fresh air I didn’t know I was missing. But then I stopped and paused to reflect on my current (and frankly, the bulk of my career) situation and reconsidered.

Can an organization that is carrying a full complement of employees, roadmaps, operating plans and budgets adopt this lean philosophy wholesale? I don’t think so. There are elements of the approach that can be watered down and used to augment some current behaviors but the kind of cultural shift required by this approach means retro-fitting an existing organization (of a certain size) is not possible.

Here are just three of the areas where I think the “Getting Real” philosophy breaks down with an existing organization:

1. You are NOT your customer — the book states you should build products for yourself — that YOU are your customer. This is simply not true with an existing org. The quantity and variety of folks working with you cannot all be your customers. You MUST interact with your customers to learn the true nature of their problems.

2. Epicenter design — frameworks are very popular in existing companies. The need to define the infrastructure for a system, interface or experience is a priority. These frameworks determine how many other people need to get involved, at what capacity and which systems need to talk to each other. In addition, the feature being developed in all likelihood is going into an existing product. That product has it’s infrastructure components already defined and these constraints are bequeathed to the feature you’re plugging in.

3. Technical and UX debt — in my experience, existing companies never go back and fix “little stuff.” If a feature failed or has a major bug then fixing that becomes a priority. Otherwise, it’s a steady march forward to release more product faster. Going back to tweak a mediocre implementation that still works is not a priority for any product owner. The compromises made during the lean product development lifecycle would simply  be treated as an admission of that compromise in index card form stuck to a debt board no one looks at.

I think the bulk of the advice in “Getting Real” is fantastic — IF you’re the 3-person startup described in it. In that situation you should definitely be producing working product at a very fast pace. In an existing org, however, there are elements of the day-to-day administrivia that you can hope to remove but effecting a wholesale transition to this approach would fail.

[Jeff]