business

Go is the founder’s game

Andrew MinerLeave a comment

I’m currently about two months into founding a company, and, on an unrelated note, I just purchased my first really nice Go board (if you’re not familiar, you’ll probably want to read a bit about Go before continuing). It’s a new game to my wife, so I was explaining some of the basic principles to her this evening, and I was forcibly struck with the similarities to founding a company.

Opportunity cost

Each stone you place on the board during a game can only achieve certain objectives. It may limit the an opponent’s liberties (opportunities for advancement), it may offer your more liberties (sometimes more than one), it might strengthen your established positions, or it might conquer new territory. However, each piece you put down means giving up on other options: sometimes forever, if an opponent takes that place on the board. The best moves are those which do several of these at once.

I find this exactly corresponds to thinking about my business. Every hour I spend on one task is taken away from all the other tasks I might have spent time on. As in the game, it’s very easy spend time on things which are valuable, but not valuable enough. To be most successful, I use the Objectives & Key Results system (from Measure What Matters) to scan the board as a whole (i.e., make goals for the upcoming quarter), and my Getting Things Done (GTD) weekly review to zoom into the details (i.e., select projects and next actions) to pick the best moves I can.

Done is better than perfect

In the game, you often find yourself with a formation (a connected sequence of stones) which is in danger (i.e., about to be captured). In order to save that formation, you need to keep adding stones to it until it is out of danger. However, it’s very tempting to keep adding more stones to make it safer and safer, even though it’s no longer in grave danger (just mild peril). In the meantime, opportunity cost catches up with you. It would have been better to make it “safe enough” and then turn your attention to other, more strategically important, moves.

This is a constant struggle as I work though decisions about my business, since my natural tendency is to make everything “perfect”. For each project I undertake, I challenge myself to find the correct state of “doneness” for the current stage of my business: which is nearly always far, far less than “perfect”. I put “perfect” in quotes because, in the context of getting my business off the ground, taking “perfect” to mean “polished to the utmost degree” is the wrong definition. In this context, the real definition should be “polished to the minimal degree necessary to unlock progress on something more important”.

Keep all the balls in the air

The challenge created by the last principle is that you rapidly wind up with many vulnerable formations on the board at once. With each move, you need to consider each formation to see if it’s in danger of getting taken, or has an opening to extend it to capture new territory. In many cases, an opportunity to start an entirely new formation arises unexpectedly, and now you have one more thing to juggle.

Particularly as a solo founder, this is a daily balancing act. I use my GTD project list to constantly remind myself of the many, varied, projects I have on my plate, and update my action lists daily to deliberately choose which are going to get my attention on a particular day. As I do this, I often choose based upon which important priority hasn’t gotten my attention in a while. Taking this time to reflect is particularly important for me as a technical founder because writing code feels so productive, and therefore can easily absorb an out-sized portion of my time. So, I personally need the constant reminder to keep all the balls in the air: especially those more outside my comfort zone.

Mistakes and sunk costs

Go is a game of capturing territory, and sudden reversals are common. You may be working on building up a certain formation, only to find that your opponent has outflanked you, and that formation is suddenly in danger. If you’re not thoughtful and cautious, it’s very tempting to keep playing more and more stones racing to protect that formation, only to lose it anyway in the end.

The uncertain nature of a new venture means this is a constant danger for my business as well. I need to make a dozen key decisions (and loads more little ones) each week. Most of those are made with too little data, too little expertise, and not remotely enough time to acquire either. Unsurprisingly, those decisions are sometimes sub-optimal, and occasionally terribly wrong. The skill I’m constantly striving to hone is to recognize those mistakes as early as possible: often by seeking out and actually listening to hard feedback. Then, if I discover I’m on the wrong course, to swallow my pride and immediately stop throwing more time and money at it.

Recognizing a lost cause

Most games of Go don’t actually get played all the way until all the stones are on the board. At any point, either player can “pass” on their turn if they don’t think there’s anything productive they can do (it is quite possible to decrease your final score by playing too many stones). If the opponent agrees that there’s nothing productive left to do, then they also pass, and the game is over. I’ve sometimes conceded games where I’ve badly misjudged something within 10 minutes of play (a very short game!). The silver lining is that the sooner you recognize a particular game is over, the sooner you can move on to a game where you’ve got better chances.

Launching a new product starts with a huge pile of hypotheses about what customers want, what they’ll pay, how many people actually want it, etc. And, of course, almost no actual data. The goal, then, is to keep testing hypotheses and converting them into real knowledge of your product, your customers, and your business model. In the happy case, you prove your hypotheses correct, and the business thrives. In the not-so-happy case, you keep finding your hypotheses are incorrect, and eventually, you need to admit that this particular product idea doesn’t have a future. If you’re quick enough to do this, then you might have enough time and money left to try again (and, if you’re extremely good at this, even another time or two after that!).

✧✧✧

Of course, many games rely on these principles to some degree or another. And, it’s entirely possible that my current situation makes me see these principles in everything I do. However, I really do think that Go requires these principles so constantly, and to such a stark, obvious degree that it really is the “founder’s game”.

Presentation timing card

Andrew MinerLeave a comment

I recently gave a newly-developed presentation for the first time, and I was concerned that I had too much material to fit everything in. I was going to be giving this presentation at work, and it was supposed to fit in people’s lunch hour, so it was particularly important that I get the timing right. To be sure I got everything to fit, I developed a “presentation timing card” for myself.

To start, I opened a spreadsheet and listed out all the major sections of the presentation. For each one, I went back through my slides for that section and came up with an estimate of how long I thought I’d need to cover each. I wrote that down next to the name of the section.

Next, I used the spreadsheet to sum up all the estimates. No surprise, I was way over the time I actually had. So, I went back through each section, and adjusted the timings to deliberately allocate the number of minutes I actually had across all of them. There was no way to avoid having less time than I thought I’d want to have in each section, but it forced me to make some careful choices about what was really important to cover at what depth.

Now that I had some realistic numbers, I added two more columns to the spreadsheet: the times I should start and stop each section. The first one’s start time was just the beginning of the talk. Each end was just the start time plus the duration I’d assigned. Each subsequent beginning was really just the end of the previous section.

✧✧✧

Having finished with the spreadsheet, I printed it out so that it just about fit on a playing card. When I actually gave the presentation, I propped the card up where I could keep at eye on it as I went along. I was surprised and very pleased with how easy it became to hit the right pace for each section. Even with two exercises for the audience and random questions throughout, I was able to finish each of three presentations of the material a few minutes before the end of the session. I will definitely be using this technique again!

What I learned from Edward Tufte

Andrew MinerLeave a comment

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

Andrew MinerLeave a comment

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

Andrew MinerLeave a comment

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

Andrew MinerLeave a comment

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

Andrew MinerLeave a comment

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

Andrew Miner2 Comments

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

Andrew MinerLeave a comment

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

Andrew MinerLeave a comment

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.