Posts in DeveloperTown
Researching an Idea

The following is an excerpt from an email I sent to DeveloperTown in September 2016. 

As most of you know, we hear a relatively large number of ideas for products and businesses. This week I thought I'd share my process for how I do research for an idea, and maybe share some examples from the past.

Each of us who hear pitches have our own process, but most of us run a quick checklist of questions (no particular order):

  • Is there an obvious market for this product? How big might that market be?

  • How would/could it make money?

  • What are the complexities of a product like this?

  • Is it technically feasible?

  • Is this a zero to one product (aka the iPod - your entire music library in your pocket)? Or a derivative product (aka Uber for lumberjacks)?

  • How would you have to market or sell this product?

  • Can this product "work" with a small number of users or data - like what you'd see when first launching?

  • Are there eventual network effects for a product like this?

  • What might it cost to develop this kind of product?

But by far, one of the most important questions is:

  • Is there anyone already doing this?

And the answer to that drives a couple more important questions:

  • If someone is already doing it, how have they performed?

  • If someone isn't doing it, has anyone tried it in the past?

  • If someone isn't doing it now, who would they be displacing in the market even if they aren't a technology competitor? (Think Uber vs. taxi companies and municipalities.)

Researching competitors and finding traction

There are a number of ways to do research on competitors. Google is an obvious place to start. And you may be surprised how many ideas pitched to us fail the basic Google test. But let's assume you've done a couple of obvious searches and not turned up a competitor. Where would you go next? Here's a short list of places I often search...

I use these the most:  

These can sometimes be useful or have hidden gems. This is the list if you need to go deep:

Or, sometimes you have to check specific accelerator portfolios. I like checking http://500.co/startups/, http://yclist.com/, and http://www.techstars.com/companies/.

If you find a hint of a company that might have been a competitor in the past, but is now defunct, the Wayback Machine is a great place to do some research on them: https://archive.org/web/ Another great place for dead startups (with some details around the failure) is Autopsy: http://autopsy.io/ (I only wish they had more companies listed.)

All of those above sites can also provide traction information, but I also like Startup Tracker (https://startuptracker.io/) which has a fairly nice Chrome Extension. It's not super helpful in helping you find competitors, but once you've found a company you want to research, it's great at providing a summary of where they are at.

A quick example

Here's a fairly solid recent example from Jacob Cloran. I asked for his help in researching an app idea that I knew wasn't great, but the person who had the idea has some serious credibility. So while I suspected that Jacob would end up killing it with his research, I wanted the prospect to have a great experience with us. I wanted him to see that we took him seriously, and that we did our homework.

Here's the idea:

<removed from the blog post version - sorry> 

Here's a summary of Jacob's findings (using some of the above resources, and some of his own):

<removed from the blog post version - sorry> 

Killer right? On multiple levels. Great research, and killed the idea (for now). The entrepreneur has gone off to do more research. I hope he comes back in a few months with his next idea - because I definitely want to work with him.

Outsourcing some of the hard work (Fancy Hands)

Sometimes this kind of research is easy to handoff to a transactional service. There are a lot of them, but I'm a fan of asking Fancy Hands (https://www.fancyhands.com/) to do research for me. I've had them do research similar to what Jacob did above. It wasn't nearly as comprehensive. But for a "fast" low-cost search, it can be a nice place to start. A better way to use a service like Fancy Hands is to give them a spreadsheet of companies and ask them to fill in the blanks around traction data. Or you can ask them to hunt down a specific detail across a number of companies (like pricing).

Here's an example from about a year ago where I asked them to help me run down competitor pricing:

<removed from the blog post version - sorry> 

Pro-tip: If you want to get really fancy (see what I did there?), you can ask them to take a data dump like that and try to turn it into a chart of some sort. That kinda of chart can look awesome in a deck or business plan.

What does traction look like?

Once you've found a competitor (or twenty), how can you tell if they matter? Here are some things I typically look for:

  • Funding - Have they raised capital? How much? When?

  • Users - How many page views do they get? How many app downloads? How many reviews?

  • Marketing - I've seen Briggs (and Eggleston before him) produce killer reports and data around SEO rankings, AdWords traffic, referral traffic, and ad networks.

  • Social - Do they have followers? How many? Are they still active?

  • PR - Are they ever in the news? How often? When was the last big PR push? Where did they get traction (local, national, niche, etc)?

  • Pricing - What do they charge? If it's free, is it obvious how they make money?

It's hard to put hard and fast rules around how much traction is "too much" to compete with. But I feel like you know it when you see it.  :)

Have a great weekend,

Mike

 

DeveloperTown, ToolsMichael KellyComment
Billable Expectations: 40 / 168 / 1,800

The following is an excerpt from an email I sent to DeveloperTown in April 2016. 

Let's start this discussion with some magic numbers. Most professional services firms run off of the same set of assumptions when it comes to billable resources.

Keep in mind, we're talking about billable hours. There are billable hours (we can charge out clients for that time) and there are non-billable hours (personal development, time off, team meetings, time spent moving houses, lunch with me even though it feels like work, etc). And some weeks, you don't always have line-of-sight on 40 billable hours. Ignore that complication for this discussion. This all assumes there's 40 billable hours of work available for you to do.  :)

40 billable hours in a week

The most basic magic number is the 40 hour work week. This one likely doesn't need much description for where it comes from. It's eight billable hours in a day, five billable days a week. If we were a staff aug firm like Anchor Point, the expectation would be 40 billable hours minimum - no exceptions. On the other side of that, we know of several consulting firms that do fixed monthly fees for their people where they bill out a "full time" resource with a 36 billable hours per week assumption. That four hours of slack provides a placeholder for company meetings, personal development, etc.

Here at DT we've been historically silent on defining a hard rule around 40 billable hours. We've always said that should be the target, but that you're mileage may vary based on the project, overall workload, etc. As a general rule, if you bill between 36 and 40 hours in a week, you're likely going to be okay. Over the long run, the expectation is that you should be averaging 40 billable hours a week - assuming you have productive work to do. If you don't have client work to do, escalate to your manager or to an engagement manager for any projects you're on.

What does a perfect week look like? It might look like this...

You should see a solid chunk of billable hours (north of 36 hrs), and a couple of line items related to the company or your team.

168 billable hours in a month

Most consulting companies estimate that there are 168 billable hours in a month for each billable person. There's some fuzzy math to get to that number. But most reasonable measures will get you to something close to that. A quick example:

  • 40 hrs per week x 52 weeks = 2,080 hrs in a year

  • now divide by 12 months to get 173 hrs per month

  • now give someone two weeks off (so [40x50]/12), and you get 167ish  

This is the first time you see an expectation of utilization come into play. Quick reminder: utilization is the percentage of billable hours for a person in a given period of time. While we ignore an expectation of utilization in the weekly number, 168 has an expectation of 97% utilization. Here you see the first baked in assumptions around time off, sick time, and slack.

This number can be a nice number to look at to see trends. In any given week someone might be sick, have something odd happen on a project, etc. However, when you zoom out and look at a month, you can see the trends. For example, last month no full time employee of DT logged less than 172 hours for the month. (Yea! Go DT!) However, there were only 10 people with more than 168 billable hours.

Again... not necessarily an issue. This isn't a hard and fast rule - it's just a heuristic. Some roles (like mine) aren't expected to be full time billable. Some people were between projects for a week or so. It's a useful number to watch at a macro level.

1,800 billable hours in a year

Most consulting firms estimate around a 90% utilization annually. That's around 1,872 hours annually, or about five weeks non-billable. Notice I didn't say five weeks of vacation. That might be the reason. It might also be that people are between projects or we assign people to non-billable work (like our very own DT website). It also includes holidays.

We're actually a bit more conservative here at DT. Given the nature of our projects, we've recognized that we actually tend to average more like an 86% utilization. Obviously we'd like to raise that up a bit over time, but it means we're averaging around 1,800 billable hours per year for each billable person. It's a great number to track at the firm level. And this means that there's a bunch of time "budgeted" for vacations, holidays, team events, people getting sick, and bench time between projects.  

 

DeveloperTownMichael Kelly Comments