Vision

Vision — 1 Comment
17
Aug 11

Our MVP For SEATS

As a part of our Baltimore work weekend, we put together what we are considering to be our MVP for SEATS. It’s been a tough process; for some reason, it seems like it’s easier to add things to the pot rather than take them away.

One of my personal hardships with running lean while creating SEATS is my desire to add features to the product. I know that there are some really spiffy things we could add into the product (leveraging location from the phone to alert a recruiter about a job seeker is nearby who matches one of their open positions or leveraging Google Maps to give an applicant an estimate of what their commute would be like so they can make a rational decision about a job, a plugin for WordPress — just for three quick examples). But as neat as those features might be, the MVP is the Minimum Viable Product, not the Mondo Viable Product. And so, off to kill our babies we go.

Here’s what we believe to be the MVP for SEATS:

  1. Post A Job: Posting an opening has to be one of the first steps any workflow surrounding recruiting.
  2. Apply For A Job: Following the ability to post an opening, the system must support people applying to fill that opening
  3. Review Process: While each individual company will differ, all companies will review a given application to see if it is a good fit.
    • Schedule Interview(s): Most companies will schedule one or more interviews (in person, over Skype, on the phone, etc.) as part of the review procedure. This process needs to be managed — find an internal person to do the interview, schedule both the applicant and that internal person, collect feedback, etc.
  4. Search: In all of the conversations I have had with recruiters, the ability to search through their database of resumes looms large in their choice of ATS.
    • Resumes and/or Candidates: A recruiter needs to be able to search through his/her collected resumes
    • Job Postings: An applicant needs to be able to find a job they want to pursue
  5. Accepting Payment: We are doing a freemium model, so we may be able to slip this for a bit, but sooner or later we’ll need to collect payment for our services
  6. Administrivia: This is our catch-all grouping for the small stuff you need to be able to do in order to get the job done, rather than the actual job itself. Things like:
    • Changing your mailing address
    • Adding a new phone number
    • And so on

    However, some of the items in the Administrivia pile are actually non-trivial: For example, granting access to a group of job posting to a set of recruiters so everyone can work as a team to fill positions.

If you’re reading this list and thinking something like, “Wait! What about _______!?!”, bear in mind this is Minimum Viable Product, not the final product. We’re going to release before we’ve added every feature because we want to work with customers to make sure we’re on the right path, rather than building some grand edifice that no one wants. With that in mind, please let us know if there’s some feature that you’re dying to have in an ATS.

TwitterFacebookLinkedInXINGViadeoRedditDiggEmailShare
Vision — Comments Off
26
Apr 11

Our Vision For An ATS

If you are a recruiter and/or sourcer, you almost certainly like people. While there are always exceptions, you are talking with people all day long. You talk with the hiring manager to ensure to make sure they are getting what they need; you talk to candidates to make sure you have a good fit; sometimes, it must seem like you talk to anyone and everyone.

In very real terms, recruiting is much like matchmaking. Person A wants to work; person B needs the same work to be done. Wonderful things happen when you find the right person A & B.

Fun

Just speaking personally, it’s fun to meet new people. And it’s fun to help people when I can (the good karma is just a bonus to boot). What’s a better way to help someone else than to connect them with a good job that fits both them and the company?

And when it comes right down to it, you already have enough work in our jobs (those TPS reports aren’t going to fill themselves out, you know). You have to get your work done. The fun of helping people shouldn’t be work; it should be simple and easy.

Simple & Easy

One of the key development mantras for our company is simple and easy. In my opinion, things roughly go like this:

  1. You are already doing your job
  2. While you do your job, you are already using some sort of tool to help make your job easier (pencil & paper, Excel, some other ATS)
  3. Any new tool that you’re considering to replace the one you are already using has to be as easy to use — if not easier — or you are probably better off staying with the one you are already using, unless there is some significant leap in capabilities provided by the new tool that you cannot get otherwise (part and parcel of some of the design principles of software development).

Therefore, the primary design goal for our ATS must be as simple and easy to use as possible. We do plan on adding some very spiffy tools to the recruiter’s arsenal, but only where the implementation of the tool can be made to work within our simple and easy approach.

TwitterFacebookLinkedInXINGViadeoRedditDiggEmailShare
Resumes / Vision — 1 Comment
18
Mar 11

Our Second Pivot

Since Mike has moved on and Scott and I have been looking for a replacement, we have also been closely evaluating our current business and technical model. At this time, we no longer believe it to be feasible within our current level of resources to pursue resume synchronization; we will be changing our focus and moving down the ATS route.

Be warned, this is a bit of a long post. I’m writing it to explain what is happening, why it is happening and what to expect in the future both to everyone already involved with the project and to the other people who had signed up to try the service but had not yet gained access.

Resume Synchronization

To recap, the original idea behind RE was to provide a resume synchronization service to job seekers, alleviating the need to re-enter the same information on site after site. We were planning on doing this in one of two ways:

  • The API provided by the site
  • Screen scraping the sites and roboting the forms

For our proof of concept, the plan was to establish three way synchronization between LinkedIn, Monster and the Washington Post.

Customer Validation

The service was to be free to job seekers. As you can probably imagine, we had them lined up at the door. Seriously; we signed up a few hundred people on a simple landing page strictly from word of mouth (mostly me going to DC area networking events) and a very limited ad campaign. Even more encouraging, our LinkedIn ad campaign enjoyed a 72.341% conversion rate (as compared to 12.441% from AdWords and 0.000% from Facebook ads). Obviously, the FB part wasn’t so spiffy, but LI was very attractive.

We were planning on charging recruiters for access to the system; we had interest and continue to move along with validating the pricing model — even with our pivot, recruiters and sourcers will remain our primary target demographic.

Proof Of Concept

We enjoyed rudimentary success with the Washington Post interaction, and pseudo-success with LinkedIn. Monster was a loss, start to finish.

LinkedIn (LI)

The LI API is extremely limited, only dealing with a small portion of the resume data LI captures and even then universally one way (out of LI only). Given that LI’s API was insufficient, we retrenched and tried to screen scrape LI instead. We had something that worked for period of time, and then we ran into a CAPTCHA. Interestingly enough, we only encountered the CAPTCHA when running our scraping program from AWS or Rackspace; I suspect LI has instituted a CAPTCHA for an IP originating from a known cloud server farm for just this reason.

We explored some alternative means, including what Kevin DeWalt calls manulating. While that would suffice (barely) and I did find some cost effective providers in both the Philippines and Bangladesh, it was workable as a tertiary fallback mechanism, not as a primary means of scalable production.

Monster

To the best of our ability to discover, Monster does not have a published API. Screen scraping was not viable, as Monster heavily uses JavaScript and AJAX throughout their site, and the Python based solution we were using consistently choked during the attempt to process the website. While there are existing products that can drive a JavaScript/AJAX website (if nothing else, automated testing tools), there were none that we found which fit within our technical framework or made business sense.

Washington Post

Actually, we made good progress on screen scraping this site. We stopped killing ourselves over it based on the problems with LinkedIn & Monster, as a synchronization process linking one site to itself isn’t all that useful.

Moving Targets

The kick of the whole thing is that even if we had been completely successful with all three sites, we would always be at the mercy of the designers of the respective sites we are synchronizing. If they change one little thing, the screen scraper would require inspection, if not refactoring. And, in today’s world of continuous deployment, they would always be changing something. It’s the epitome of a Red Queen’s Race. Initially, we accepted this risk on two assumptions:

  • We would be able to move quickly enough to add sites as a sufficient rate to attract job seekers (and, in turn, recruiters)
  • We would be able to demonstrate sufficient traction to acquire funding, which would support hiring enough coders to run that Red Queen’s Race until we had enough momentum we could influence the actions of the synchronization sites

The arrogance in that last statement is palatable, isn’t it? In any case, the amount of work required to resolve even the very limited interfaces to the synchronization sites proved this approach to be to expensive to maintain at any level of scale.

Too Many Sites

We’ve acknowledged this before, but there are a lot of job sites. And, it seems like there are more popping up every week. Even though our name is “Resume Everywhere,” we were never going to be able to cover every job site everywhere. From our initial estimates, we were going to need a junior to medium level screen scrape developer for every 20 sites we signed up. We had some ideas and tools in the pipeline that would have acted as a force mulitplier for that type of development, but it hasn’t been built yet. Strike three for synchronization in the scalable business competition.

Pivoting To ATS

A month or so ago, I was in NYC for SourceCon 2011. A conference dedicated to the needs of the sourcing industry, I went to do some customer validation; specifically, would these people be interested in searching the database of resumes collected through the synchronization process and how much would they be willing to pay for the privilege (the answers were “sure” and “it depends,” respectively). It was a good conference; I met lots of good people, won an iPad and learned quite a bit.

Recruiters & Sourcers Hate Their Current One

One of the things I learned was that nearly all of the people present expressed their intense dislike of their Applicant Tracking System, or ATS. The informal poll taken at the start of the conference revealed that only one — one — person rated their ATS as a 3 on a 1-5 scale; three or four more gave their system a 2 and everyone else gave it a 1 (with many saying they would give lower if they could). This is pretty clearly a market that is being underserved.

Extensive But Partial Domain Knowledge

In essence, an ATS is fundamentally a workflow application in which candidates are routed through a system of decision gates where various people (hiring manager, HR, senior management, etc.) have to approve a candidate for him/her to move forwards in the process. Between Scott and myself, we’ve architected, designed, developed, deployed and maintained over 30 different workflow systems for customers such as the US Department of State US-VISIT program or the FAA OE/AAA (Obstruction Evaluation/Airport Airspace Analysis) system, just to name two off the top of my head. We know how to move data around efficiently, and we get scale.

Where we are lacking is the domain knowledge for what specifically makes an ATS a good system and what does not. That is going to be foremost on our minds for the next several weeks, as we interview potential customers to learn of their pain points in much greater detail.

So, No Syncing?

Yes, no syncing. At least not for now. I still believe it’s a compelling business model and that there is significant user demand from job seekers for such a service. However, we are going to table synchronization until such a time when we either have the resources to pursue it correctly or the technical landscape has changed to make such a solution both feasible and scalable as well as cost effective.

So, that’s about it. We’re starting to execute our pivot, by which I mean we’re stopping on coding and going full time on customer development until we figure out exactly what a lean, stripped down and bulletproof ATS looks like. Then, we’ll be back in heads-down, staying-out-of-the-big-blue-room coding mode until we get things done. Hang on; it should be an interesting ride!

TwitterFacebookLinkedInXINGViadeoRedditDiggEmailShare
Vision — Comments Off
1
Oct 10

Why, Yes, We Are A Lean Startup

You might think we were jumping on the same bandwagon as everyone else. Well, in that we didn’t invent the principles of Lean Startup, I suppose you could say we are hopping right on the back. But, we are firm adherents to agile, test-driven development: making the leap to applying test-driven development to crafting the business model isn’t that much of a leap at all. Perhaps a slight hop.

RE isn’t my first startup; I would like to think I am applying the lessons of what did and didn’t work from all of those past attempts to make RE succeed. Chief amongst those lessons is to make sure that the bills can be paid on time and that people value the offering enough to write checks. After all, everyone loves free products.

I believe that the era of “build it and eventually figure out how to pay for it” is drawing to a close, Twitter not withstanding. Back in the .com days, the prevailing model went something like “if we have enough users, we’ll make it back in advertising,” which is a close cousin to the other approach. What we’re trying to do at RE is provide a service which can bootstrapped into profitability in very short order. We may have to accept some funding to get us through what I expect to be a rough patch at the start, but I don’t think we’ll need much or for a very extended period of time.

TwitterFacebookLinkedInXINGViadeoRedditDiggEmailShare
Vision — Comments Off
3
Sep 10

Our Raison D’Etre

We got started for two reasons: one personal and one philosophical. The personal one first.

Personal

Resume Everywhere got started when I was working on landing contracts for my consulting business. Between the GSA certification process (loads of fun, let me tell you) and then endless stream of forms both for online contracting and the more traditional people-you-know network, I became thoroughly tired of enter the exact same data over and over and over again. There had to be a better way.

Philosophical

The other thing; if you read the Terms of Service of most of the sites, you’ll find something very interesting: You don’t own your own resume data. The sites does. I think that’s fundamentally wrong. You worked very hard to build your reputation, and your reputation is not something to which LinkedIn should be able to lay claim.

Think I’m joking? Here’s the relevant portion from the LinkedIn ToS:

…[Y]ou grant LinkedIn a nonexclusive, irrevocable, worldwide, perpetual, unlimited, assignable, sublicenseable, fully paid up and royalty-free right to us to copy, prepare derivative works of, improve, distribute, publish, remove, retain, add, process, analyze, use and commercialize, in any way now known or in the future discovered, any information you provide, directly or indirectly to LinkedIn, including but not limited to any user generated content, ideas, concepts, techniques or data to the services, you submit to LinkedIn, without any further consent, notice and/or compensation to you or to any third parties.

Non-lawyer translation: You give us your resume data and we can do anything we want to with it, at any time, for any reason, whether you want us to or not. Furthermore, if you happen to put an idea into our system and we like it, we can take it and do whatever we want to do with it, at any time, for any reason, whether you want us to or not — and we’re not going to pay you anything for it.

This is not to pick on LinkedIn; Monster, Dice, Indeed — everyone pretty much has the same kind of ToS. Everyone, that is, except us. Here’s our Privacy Policy:

You will have the right to restrict access to your resume data by recruiters as you see fit.

We will only contact you when you say we can.

  • We may contact you with probable opportunities based on our matching algorithm, but only when you have indicated you are willing to accept such communications.

We will sell access to your resume data to recruiters (and other interested parties, such as third party analysts and academics).

  • At all times, your privacy will be protected to the fullest extent of applicable law.
  • At no time will your data be sold for marketing purposes. Ever.

We do not have any advertising, nor do we knowingly support any advertising operations (through data mining or other techniques).

That’s it. You own your data, not us; you let us trade on your data in exchange for access to our services. Sounds like a fair deal to me.

TwitterFacebookLinkedInXINGViadeoRedditDiggEmailShare