What I learned from Edward Tufte

I recently was able to attend Edward Tufte’s seminar on presentations and data graphic design.  This blog post covers the essential elements I took away from the lecture.

On Space vs. Time

When one has a great deal of content to convey to an audience, it cannot be blurted out all at once and in the same spot: it must be spread out over either space or time (or both).  A slide deck spreads out content in time, using the same space over and over. A document or web page shows everything at once, spread out in space. Documents play to human being’s strengths, while slide decks play to their weaknesses.

Humans have a natural ability to visually consume a complex field of data by instantly shifting modes from high-level scanning to detailed inspection and back again.  This makes it possible—and even quite easy—for a person to scan through a long document, identify sections of interest, and dive into that piece for a closer look. The same is true for presenting many hundreds or thousands of data points in a graph; the viewer can rapidly scan the overall structure of the data and zoom in to particular interesting details.  With information arranged with spatial adjacency, it is easy for people to compare and contrast, scan and examine, and learn most efficiently.  This leads to a very high throughput of data transfer from the author to the audience.

Humans, on the other hand, have a limited ability to precisely remember detailed data for any length of time.  They also have a limited attention span: particularly when presented with data which is either confusing or boring to them.  This makes it very difficult for a person to hold the context required to compare data presented sequentially over a series of slides.  The needs of a slide presentation (i.e., a limited space per slide which must be legible at a distance) means that the content is broken into tiny chunks and widely distributed over time as the presenter talks over each point: often re-iterating the content on each slide slowly (relative to the speed of reading).  It is impossible for any individual listener to speed up or slow down the presentation to suit their needs, or to scan ahead to answer a question, or to skip back to revisit an unclear point. This leads to a very low throughput of relevant data transfer from the author to the audience.

It is highly preferable, therefore, that information displays maximize “spatial adjacency” of material with a visually dense presentation with varying levels of headers, “data paragraphs”, and whitespace to allow viewers to readily identify and select from large blocks of content at a single glance.

On Giving Presentations

For presentations of virtually any scale, it is far better to provide a narrative document (i.e., like this one) instead of a slide deck.  The document should be from 2–6 pages long, and include all the information to be discussed integrated into a single flow. Tables of numbers, charts, graphs, pictures, etc. should all be integrated with the narrative description of the subject matter.  In all cases, references should be included to source materials, primary sources, etc. The document should be written to be a permanent record of what was discussed, and therefore should be complete and self-contained.

For the actual presentation, the meeting should begin by handing out copies of the actual document to each attendee.  This is followed by a study hall session long enough for everyone to carefully read the document and make note of any questions, thoughts, or disagreements.  Once everyone is ready, the remainder of the meeting is not spent re-hashing what was just read, but instead is spent in discussion those questions, thoughts, and disagreements each person noted while reading.

The primary advantages of this style of meeting are:

  1. People can read through the document at their own pace, and to serve their own needs.  Sections irrelevant to a certain person can be skimmed, while sections of intense interest can be lingered over carefully.
  2. People can easily jump ahead to see if a question is answered later, or skip back for extra clarity on a point they may have misunderstood.
  3. People read much more quickly and with much greater throughput than can be presented aloud, so meetings can often be shorter.
  4. The document serves as a permanent record of what was presented which everyone can take away with them to refresh their memories later.

On Judging an Information Display

“The purpose of information display is to assist people in reasoning about the content.”

Edward Tufte

When judging an information display (i.e., charts, graphs, tables, etc.), people judge both the quality of the data and the reliability of the presenter.  To establish both, apply these six principles both when making and consuming an information display.

show comparisons, contrasts, and differences

The information display should be deliberately designed to make it easy to compare various data sets or points within each data set.  The author should be thoroughly conversant with the data, and deliberately highlight those points of contrast which are most surprising, interesting, or useful.

show causality, mechanism, explanation, and systematic structure

Information displays should endeavor to show how certain data sets were the cause of other data sets.  In charts, for example, one can use labeled arrows to not only show the direction of causality, but also to describe the mechanism or process by which it happened.  On graphs, this can be a block of text describing some causal connection with an arrow pointing to where this is shown in the data.

show multivariate data (i.e., 3 or more variables)

The real world is complex, and includes a lot of interconnections between different data sets.  Information displays should attempt to draw in as many of these various data sets as possible to show the interconnections between them (see: Minard).

completely integrate words, numbers, images, diagrams, etc.

When helping someone understand a data set, it is very unhelpful to segregate data based upon its source, format, or media.  Instead, pull all sources of data into the single information display so that they can be compared side-by-side with the other data relevant to the story.  Data labels and other text should be integrated into the data display whenever possible instead of being relegated to sidebars, legends, or other documents.

document the display thoroughly

The reader should be left with no questions about what it is they are seeing or where it came from.  This often requires extensive textual, even narrative, explanations included within and along side the information display. A title, the author’s name, units for all numbers, and links to source data are a minimum.  One may also find it helpful to include a paragraph explaining the principle features of the data set, interesting comparisons to make, or surprising results.

presentations stand or fall based on the quality, relevance, and integrity of the content

Showing the content in the clearest and most accessible fashion should be the only purpose of an information display.  Design for the sake of design should be avoided at all costs. Any extra line, letter, or decoration should be eliminated if it doesn’t serve to help the reader understand the data better.  The data will tell the story better without confusing or distracting embellishment.

✧✧✧

Naturally, this only covers the most essentialized version of what Tufte presents over the course of his full-day lecture. Along with the lecture, you receive his four published works on data display:

I found the lecture both extremely informative, and productive. I came home bursting with ideas on how to improve the data displays of the various projects I was working on, and I’ve been able to put his precepts to good use on a number of occasions since. I highly recommend attending if he comes to a city near you.

The Interview Schedule

This is part 3 of a series on interviewing.  Check here for part 1 on setting up an interviewing team.

✧✧✧

It’s important that every candidate be treated like you’d treat a VIP customer.  Even if you don’t wind up making an offer, they will have a deeper interaction with your company and your staff than the vast majority of the general public, and you want them to go away wishing they’d gotten an offer.  They are going to tell people about their experience with your company, and you want the story they tell to be about how awesome a place it seems to be, rather than how they dodged a bullet by not getting an offer!

There are a long set of interactions which happen prior to a candidate coming in for an interview loop which I’ll talk about in other posts.  Here, I want to focus on the in-house interview.  For that, he first step of that is to make sure the candidate has a full  schedule of their visit.  This should be delivered to them along with all the initial travel arrangements.  Ideally, it should include:

  • an initial meet & greet / tour segment
  • a list of each person they’re going to meet along with their role and email
  • a schedule of when important events are happening throughout the day (e.g., each interview, lunch, happy hour, etc.)

The first part, the meet & greet, serves two important purposes.  First, it’s important to always bear in mind that most people find interviews extremely nerve-wracking.  A short tour of the office, and a chance to chit-chat with a few people helps the candidate unwind a bit.  Second, it gives you a time buffer to absorb any unexpected delays in the candidate’s travels.  Whether it’s traffic, parking, a flat tire, a late subway train… whatever.  It’s easy enough to just cut this period a bit short so the candidate can get started on time, and you can avoid messing up the rest of the day’s schedule.

The second point, giving a list of interviewers, deserves a bit more explanation.  For a mediocre candidate, this information won’t matter.  However, for an exceptional candidate, it’s an opportunity for them to show their enthusiasm and their diligence.  Really exceptional candidates will do some homework on their interviewers, and will often have some interesting question, anecdote, or topic to discuss with each interviewer.  Such candidates will also generally avail themselves of the opportunity to individually follow up with each interviewer to thank them for their time.

Finally, providing a schedule allows the candidate to mentally (and perhaps physically) prepare themselves for the expected duration and expectations for the full day.  I’ve had a number of candidates comment to me over the years at how unexpectedly rigorous / lengthy an interview was.  I’ve also had experiences as a candidate where I wasn’t able to make some other commitment because the full extent of my time commitment wasn’t clear.

✧✧✧

At the end of the day, you want your candidate to walk away thinking well of your company, the people they met, and how they were treated as a guest at your office.  One of the easiest things you can do to ensure that happens is to avoid surprising them, and by giving them a chance to do their homework up front.  And, you’ll be pleasantly surprised by your best candidates when they actually do.

Building a Board & Weekly Progress Reports

In starting out a self-funded company, I didn’t just get a board by virtue of taking on an investor, but I still found that I really wanted a way to get feedback and advice from more experienced people I know and trust.

To that end, I started asking friends and colleagues if they’d be willing to receive a weekly progress report from me, and occasionally field a few questions. Having worked with a number of generous and savvy people, I quickly got about two dozen people on my list.

Starting from my first week “on the job”, I sent an email to this group roughly¹ once a week detailing how things were going.  This email has three broad sections:

  • A narrative description of the big issue(s) I dealt with that week. This might be describing some engineering issue, a new feature, or how some recent customer interviews went.  If applicable, it contained pictures and/or videos of recent progress.
  • A bullet points list in three sections: what I accomplished, what I’m still working on, and what’s next
  • An evaluation of my own emotional state (optimistic? disheartened? frustrated? elated?) and a brief outline of why and how I got that way.

Including the center section was especially helpful as it forced me to get very clear about past/present/future each week.  It also gave me an impetus to really complete things so I can include them in the accomplishments section, and thereby gives me a sense of accountability.

When I sent these emails out, I almost always got back a few responses which range from actual solutions to issues I was having, to simple words of encouragement (which were still much appreciated!).


¹ except when nothing much had happened, and I was just working through the same plan as the previous week

Gathering early-stage product feedback

Early in the process of figuring out my product, I conducted a series of customer interviews. I started the business to build a product I personally wanted, so I had a pretty good idea about how I would use it, but I really wanted to know whether my experience was common with anyone else.

To that end, I did some brainstorming on the types of people who would be at all likely to use my product (not necessarily just those I was aiming for to start with), and then went through my LinkedIn connections for colleagues who fit into those categories. From an initial list of close to 30 people, I narrowed it down to six people who gave me a very widely diverse group in terms of professional training, day-to-day responsibilities, and industry.

Next, I wrote down a set of questions I wanted to ask each person. The overall structure was to start by asking questions to see if the person felt the pain my product attempts to solve, proceed into questions which try to discover how they solve it today, and finally to find out how well they like that solution.

At this point, I stopped with my questions, and give the pitch for my product. At the time, I didn’t have a live demo or even mock-ups, but I definitely would have used them if I had them. I let the interviewee ask as many questions as they liked, and then proceeded to the next batch of questions:

  • Does my product sound like something they could use?
  • What would be the biggest obstacle to adopting it?
  • What could I do to make adoption as easy as possible?
  • How much would you expect to have to pay for this product?

The information I received from these interviews was highly informative, and while it didn’t change my core vision for my product, it definitely changed a lot of my thinking about the details, and how to get it to my customers.

Sending Cold Emails

This is part 2 of a series on interviewing.  Check here for part 1 on setting up an interviewing team.

✧✧✧

At a rough guess, I get about 4–5 recruiting emails every week.  Sometimes more, sometimes less.  I only bother to even say “no” to perhaps 1 in 100.  The others go straight to the trash: often unread.  For the benefit of all my recruiter friends, I’d like to explain why.

First, I should mention that I’m a software engineer with roughly 20 years experience.  In that time, I’ve worked up and down the technology stack from web to mobile to back-end to dev-ops: you name it.  I’ve also worked for companies from IBM to a freshly-minted startup.  So, I imagine I’ve gotten on a lot of lists.

 

Getting it Wrong

The common thread in the 99% of emails I don’t answer is that they’re really just spam.  They obviously take no time to pitch me on why the job fits my interests, talents, or would be better than the job I currently have.  The worst offenders are the bulk emails which invite me to peruse a “jobs” page and apply.  Slightly less obnoxious are the “we saw your resume and think you’d be a good fit…” emails. However, they all focus on what the company wants: not what I might want.  Fire and forget may be a good tactic for filling some positions, but you’re never going to pull a qualified senior person out of their current company that way.

 

Getting it Right

The tiny fraction of emails I do answer have at least one of the following traits:

  • they come from the hiring manager / founder
  • they clearly demonstrate some specific knowledge about me
  • they clearly tell me why I—me in particular—would enjoy the work
  • they clearly reference that this is a referral from someone I’ve worked with

 

An Example

One email I recall getting recently was from Matt Lott, the co-founder of CodeCombat: a startup which is trying to help kids learn coding by making a (really cool) game out of it.  He nailed nearly every point on my check-list. Here’s the actual text:

Hi Andrew,

Fellow co-founder here. I checked out Crafting Guide – kudos on
building a really cool guide to everything Minecraft-related :). I
also read on your LinkedIn profile that you enjoy mentoring others so
I thought I’d reach out. Our “World of Warcraft”-inspired game teaches
kids how to become programmers; to climb between levels, students
write code to navigate mazes and defeat savage monsters. More than
20,000 teachers currently use CodeCombat, and our investors include
Andreessen Horowitz and YC.

So far, we’ve built a popular single-player game, and we have many
cool challenges on the horizon – like building real-time multiplayer
mechanics and revamping our graphics engine. With your experience, I
thought you’d be interested in leading these initiatives.

If you’re interested in helping kids learn, I’d love to chat. How
about a phone call or coffee next week?

Matt Lott
CTO, CodeCombat

First, this is clearly coming from the hiring manager / co-founder.  This means that someone who has many other responsibilities thinks there’s a good enough chance that we’d want to work together that it’s worth his time to contact me in person.

Second, Matt clearly did his homework here.  He obviously read my LinkedIn profile carefully; he noted that we’re both co-founders, and that I mention enjoying teaching.  He also found the gaming-related hobby site I made, and he obviously spent some time figuring out what it is all about.

Third, while a big chunk of the email is clearly pretty general-purpose, he starts by calling out the why my specific interests—teaching & gaming—would lead me to being interested in working on their product—which is all about teaching through gaming.  Then, he gracefully transitions from the more personalized part to the less personalized part.

In fact, the only point he didn’t hit was mentioning this as a referral, but hey… sometimes that’s just not the case.  Still, 3 out of 4 is better than 99.99% of recruiting emails I get.

And, for the record, while I didn’t accept Matt’s offer for coffee, we did have a very nice email exchange.  Of greater importance, though, is that if I heard back from him under different circumstances, I’d be happy to renew the acquaintance.

✧✧✧

I don’t need to tell anyone that there’s a lot more open headcount for senior people than there are actual people willing to join your company.  I also don’t need to tell anyone that, in general, we are well-paid, and have our choice of jobs.  Naturally, that implies that everything in recruiting is backwards compared to other more junior positions.

If I could make every recruiter understand one thing about recruiting senior-level professionals, it would be: you are in sales.  I’m a prospect, and you’re pitching a product to me.  You need to learn enough about me to understand what will motivate me to buy, and then sell it to me.  You’ve got one email to convince me that you’ve made an effort to pitch me on something that I actually want.  Don’t blow it on cheap form letters or junk mail.

Conducting an Interview Loop—Part 1: Setting up the Team

I’ve worked at a pretty diverse range of companies from the massive (IBM, Microsoft) to the merely large (Amazon, Groupon), to the small (Boom, Pelago), to the positively tiny (Kima Labs, Redwood Labs).  In every place I’ve worked, interviews are conducted according to the same general pattern, but with a lot of differences in the details.  This series will explore what I think are the best practices I’ve seen across all those different places.

✧✧✧

Even before a candidate has been identified, the hiring manager should have prepared the team for the potential interview loop(s).  The first step is to actually have a team.  That is, a dedicated group of people for interviewing all the people coming in for a certain position.   This has several advantages:

  • the team can form a “group memory” of all the candidate who have interviewed
  • the team can coordinate on “focus areas” and even individual questions
  • the team will get to know each other’s questions, and therefore save time in debriefing about the candidates

I’d like to talk more about assigning “focus areas”.  Each member of the team should be assigned a couple of very specific areas to focus on.  For example, in the case of hiring a software engineer, one person might be asked to look at algorithms, another object-oriented design, and yet another front-end development skills.  In additional to technical areas, people are generally also asked to investigate some cultural value of the company’s.  For example, at Boom, we value people who like to make things in their spare time, so we might have someone assigned specifically to dig into that a little bit.

Once assigned an area(s) to focus on, each interviewer should plan out what questions they want to ask in order to learn the most possible about that area.  Here it works best to develop questions in two different ways: a simulation of actual job skills, and asking the candidate to relate a story.

Simulating actual job skills works best for technical areas of focus, and the best questions are those which are closest to the real task involved.  So, in the case of assessing programming skills, I’ll always make sure to have a computer on hand, and a set of real development tools installed and ready to go.  Finally, I’ll have made up a question which is a simplified version of some actual challenge I’ve had to solve at work.  The goal is to come up with a question which, as nearly as possible, uses the tools and skills the candidate will actually have to demonstrate at work every day.

Asking a candidate to tell a story (i.e., Behavioral Interviews) work very well in cases where a skill is hard to demonstrate on the spot, or when trying to understand a candidate’s culture fit.  In this style of questioning, you ask the candidate to tell a story about a time when… you fill the blank.  These are often things like: you had to deal with a difficult customer, you missed a deadline, you were forced to be innovative, etc.  These can also be much more specific.  For example, I might ask a software engineering candidate to tell me a story about when they had to fix a particularly nasty bug in a piece of code they weren’t already familiar with.

It’s extremely helpful for each member of the interview team to use the same questions for each candidate for a particular position.  This allows them to:

  • get better at asking the question in a clear way
  • get a sense of what good and bad answers look like
  • figure out what guidance works to help a candidate if they get “stuck”
  • be able to compare answers directly between individual candidates

This also allows the other members of the interview team to plan their own questions to avoid any possible overlap: especially when multiple people share the same areas of focus.

✧✧✧

At this point, you’ve got your team together, and you’re ready to start talking with candidates.  In future posts, I’ll talk the best practices I’ve seen around getting candidates to show up, what to do before they arrive, how to conduct the loop, etc.

Choosing a product name

I started my company with a reasonably clear idea in mind of what product I wanted to build. The hard part was deciding what to call it. After doing a lot of reading and receiving a lot of advice, I decided the general criteria I needed to satisfy was:

  1. Relates a clear idea of what the product is about
  2. Is easy to pronounce correctly from just the written form
  3. Is reasonably easy to tell people how to spell it
  4. Has a domain name available

My next step was to generate a list of candidate product names. To start, I listed all the words I could think of which related to my product, and to ask other people to do the same. Here’s a small sample of that list: metrics, metric, graph, graphic, graphics, graphing, tinker, savant, guru, sage, insight, insights, workbench, toolbox

As you can see, the words generally grouped around certain themes, or were variations on the same word. Then, I started putting together combinations of words to form potential product names. At the same time, I started looking for available domain names to match. For each name, I looked for variants using the .com and .io top level domains (TLD), and with the words either run together or separated by dashes. Here’s a small sample of that list:

  • Metrics Workbench (all domains available)
  • Metrics Savant (all domains available)
  • Metrics Toolbox (metricstoolbox.com taken)
  • Graphic Insights (only dashed versions available)
  • Graphic Guru (all available, plus: “graphing.guru”)
  • Tinker Graphics (all available, plus: “tinker.graphics”)

As I was working through the process, I found that a dozen or so new TLDs had been added to the usual set, and so I started looking at names which used them (e.g., “Tinker Graphics” uses the .graphics TLD).

I then shopped these around with my friends, family and colleagues by asking these questions:

  1. What are your three favorites?
  2. For each favorite, which domain name do you prefer?
  3. Do any of these create a strong positive or negative association? With what?
  4. Do any of these spark better ideas?

Unfortunately, I found that none of my candidates did very well with my test group, but I got a lot of good feedback:

  • Don’t use dashes in your domain name (for SEO reasons)
  • Don’t use the new non-standard TLDs (e.g., .graphics)
  • Older non-standard TLDs were okay (e.g., .co or .io)
  • Try to find a single-word product name, even if you have to mis-spell it.
  • Suggestions of new words or themes to add to my mix of candidate words
  • Positive and negative associations (e.g., that words sounds cliched, that sounds like a porn site, etc.)

On my next round, I tried inventing single-word product names which sounded vaguely like real words, but weren’t. It was while brainstorming names with a CEO friend when I came up with “Graffer”, and we were both so immediately struck with the appropriateness of it for my product that I knew I’d found it.

Forming a legal entity (part 6): Open a checking account

After the long wait to get back my incorporation papers, the first thing I did was to open a checking account.  The most important reason this was first was that I’d been told many times that it’s crucial to keep the company’s finances completely separate from my personal finances.  This is one of the cornerstones of making the company a separate legal entity, and is crucial for the limited liability of an S-Corp to hold up in court.

A second reason to do this first was that, as a founder, I needed to “buy” the company, and the company needed a place to put the cash.  To make a long story short, when you create a company, you file with the state to create a new, completely independent, legal entity.  This entity is created with some number of shares of stock which it owns.  As the founder, and in order to become the owner, you must buy those shares from the company.  This, of course, is what gives the company its initial operating cash, and the company needs a place to park those funds (legal entities not having mattresses).

The final reason I started by creating a bank account is the obvious one: they’re pretty handy for paying bills.  I knew I wanted to buy some stuff for the business (e.g., a laptop, some office supplies, etc.), and I knew I wanted to sign up for various services (e.g., email, web hosting, etc.).  To do so, I needed a debit/credit card which would be accepted for these various online and offline transactions.

How to choose?

It turns out that business accounts, unlike many personal accounts, cost more, and come with many fewer benefits. After doing a bunch of research, I found banks generally varied by:

  • Quality of online banking access
  • Amount of annual fees
  • Minimum balance required (particularly to waive the annual fees)
  • Convenient branch locations
  • Extra services available (e.g., notary, support during acquisition, etc)

I think all the banks I looked at had an annual fee which could be waived if you kept enough money in your account (the particular amounts, of course, varied).  The banks varied considerably in the level of online banking support (from extensive to none) based mostly on the size of the bank (i.e. the local credit unions generally don’t have great websites, whereas national banks generally do).

I went with Bank of America (BoA), but there were a bunch of others which were close seconds (Comerica and Sillicon Valley Bank, in particular).  I liked BoA because its minimum balance to avoid fees was relatively low, it has good web banking (though online bill pay costs extra), and there’s a convenient branch location near my office.

Forming a legal entity (part 5): Filing incorporation papers

CAVEAT: I am not a lawyer, and I got legal advice before making any of the choices described in this post. If you are making similar choices, you should definitely should do the same.

Filing incorporation papers was a big moment.  It was when all the dreaming, planning, and preparations became for real.  It also involved a lot of reading, learning, and making decisions which would be with me for a while, and could be expensive to unravel if done badly.  However, before it could happen, there were a few questions I had to answer.

The most immediate was what kind of legal entity to create.  While there are a ton of options, the ones which were on the table for me were: a C-corp (a traditional corporation), an S-Corp (essentially, a C-corp which jointly files taxes with the owner/s), an LLC (a roll-your-own legal entity for small business), or a Sole Proprietorship (a formality with little or no legal protection for your assets).

In my case, I knew that I didn’t plan to hire employees soon, nor did I expect to raise money soon.  Therefore, the tax benefits of an S-Corp made it more attractive than a C-Corp.  There was also the fact that I could “upgrade” from an S-Corp to a C-Corp by filing a simple, single form in case something changed with made a C-Corp more desirable.

I didn’t choose an LLC because, according to my lawyer, their open-ended nature makes them more complicated for investors/acquirers, and there weren’t any substantial benefits for me over an S-Corp.  I also didn’t choose a Sole Proprietorship because I wanted more legal separation between my assets and the company’s assets than that offers.

I also needed to decide which state to incorporate in.  Surprisingly, there’s really nothing preventing you from incorporating in whatever state you want.  The reasons to choose one or the other basically come down to how expensive it is, and, most importantly, what laws that state has regulating businesses.  The most popular state for tech-startups, because of its business-friendly laws, is Delaware.  However, incorporating out of state has a number of extra costs associated with it, and it’s always possible to re-incorporate in another state should be it become necessary (e.g., if an acquirer doesn’t like something about how your company is set up).

So, I decided to just stick with California (where I lived at the time) to avoid the extra expenses.  Since I’d be primarily operating in CA, I’d have to file for a business license there anyway, and, for what I expected from my business, it didn’t make enough difference to warrant the extra expense of officially incorporating out of state.

There were a bunch of other little things, and perhaps I’ll write about them in the future, but they were all incidental and easily resolved once those two big questions were settled.

Forming a legal entity (part 4): Registering a domain name

Fortunately, I’ve worked as a sys-admin at several past jobs, and so have gotten pretty familiar with setting up domain names and such. In any case, it’s very easy. Go to your favorite domain registrar (I use Hover, and type your desired name into the big search box. They’ll tell you whether you can have that domain.

Unfortunately, chances are, unless you have chosen a deliberately mis-spelled name for your company (cough tumblr cough), you’ll find that your first choice is probably taken. In fact, I was in exactly this situation. My company was named “Redwood Labs”, and I found I faced a few different choices:

  1. Rename the company to something available (redwoodsoftwareco.com)
  2. Use a common abbreviation (redwlabs.com)
  3. Use a hyphen between words (redwood-labs.com)
  4. Choose a different top-level-domain (redwoodlabs.co)

Of these, I choose #3, redwood-labs.com. In my case, I knew my product name would be something else, and that I was going to register a different domain name for that. Therefore, it was less important to get a short, simple, easy-to-pronounce domain name. As I’ll talk about later, it was much more involved to find a domain name for the product itself.