I appeared on an episode of The App Guy podcast that aired yesterday (12/27).
This is part of my continuing series on applying Jobs-To-Be-Done product design theory to the problem of recruiting. In my first installment, I explained the concept and gave some idea of applying JTBD to recruiting would mean:
In their workshops, Bob and Chris teach how to find out why people switch from one product to another by interviewing people that have done it already. How many of us have interviewed our recent hires to find out why they switched from their old job to ours, how they found out about it, what happened in their lives to cause them to want to switch jobs? If we did that, I think we’d find that we’re advertising in the wrong places, not emphasizing the right strengths, and generally not making the applicants know that we meet their hiring criteria.
Next, I wrote about the problem of hiring passively looking developers, where the key question I addressed was: “What would you do to your recruiting efforts if you wanted to hire people that aren’t looking for a job?”
Following along that vein, and again, using JTBD techniques, let’s talk about “progress making”. Essentially, people switch (products, jobs, houses, etc) because they are trying to make progress in their lives. In order to design products that make people switch to them, we need to know what kind of progress our users are trying to make.
In this case, it’s pretty uncontroversial to say that our potential applicants are looking to make progress in their compensation, or, if they are willing to trade that against other things, they have a lower limit.
Salary, for a potential job switcher, hits all of the forces of progress making.
- They are pushed toward switching by the feeling that their current job doesn’t value them enough;
- they are pulled toward switching by a job that pays more;
- they are pulled back from switching by familiarity with their current pay structure and raise schedule;
- they are pushed away from switching by anxiety that other jobs won’t pay as well (or have less potential for future salary growth).
Dissatisfaction, aspiration, allegiance, and anxiety: to get someone to switch we need to address all of these, and increase the first two while lowering the other two. (learn more about the forces from JTBD Radio).
Our potential applicants have total knowledge of their current salary, so to help people realize they will make progress, they need to know what we are offering. For the passive looker, who is not willing to invest much in each opportunity, the risk of early filtering is high. The unknown feeds the anxiety component and does nothing to drive aspiration (the two forces our offer directly controls), so they won’t associate “progress making” with your job description.
[ASIDE: I know why we don't list salary in job postings, but I would say that whatever those reasons are need to be balanced against wanting to make our job attractive to top developers, which we believe are not actively looking for a job. So, if we accomplish "having a good starting point for negotiation", but not "attract top developers to applying for our job", we failed.]
To alleviate anxiety about your offer, I would try social proof, a lossy communication channel, or possibly a transparent salary ladder.
For social proof, get candidates via referrals from your employees. People will make a judgement about your salary scale based on what they know about their contact.
By lossy communication channel, I mean a way to communicate salary possibilities such that the candidate gets an idea, but knows that it might be wrong and doesn’t interpret it as an offer. One way to do this is with a 3rd party recruiter — you give them a range, and they will leak it to the applicant, who will have skepticism for anything a recruiter tells them. You could try 3rd party ads that “estimate” a salary or write up truthful descriptions in something like GlassDoor or other salary reporting places. No one thinks those are definite, but at this point, they just need some idea.
A third option is to have total transparency and a completely non-negotiable salary ladder. This is what union and government jobs do (so it has a bad rap), but I’ve seen tech companies try it — here’s a really old post from Joel Spolsky about Fog Creek’s compensation and here’s a very recent article about Buffer’s compensation policy. Both use a formula based on mostly objective criteria.
Your goal is to throw something out there to alleviate anxiety enough to get them to contact you.
You rarely see an ad that is so good that it would be missed if it was removed. It’s not easy, but if you want to shake things up a little, look at one of the publications you advertise in and think about what it’s missing, then buy space and add it.
My favorite example of this is the PC-Lint “Bug of the Month” ads that ran in Dr. Dobbs and C++ Report. These were essentially the puzzle section of these magazines, and I used to spend time engaging with the ad each month. Solving the puzzle gave you a visceral understanding of what the product did.
You have to be careful. The other way you see this tactic being used is to make fake content that tries to trick the reader into thinking they are reading another article. I never think it’s a good idea to start off a relationship with such a blatant lie.
The better way is to be clearly an ad, but still have compelling content.
- Puzzles, like PC-Lint did. The trick here is that solving the puzzle should be a little like using the product. Just putting a Sudoku in your ad space probably isn’t going to cut it.
- Comics. For example: SourceGear ran a serial comic a few years ago.
- Pure educational content — don’t make it look like the publication, instead make it the text of your first auto-responder. It should deliver value
- Information. I’d look to Kinvey’s Backend-as-a-Service ecosystem map — I don’t know if they advertise it, but if they did, I would probably tear it out. If it was updated more often, I’d eagerly await the magazine it was in to get an updated copy.
The key is that it should add value to the content it’s delivered in. Hence: the addvertisement.
I’ve been doing some research on how people advertise tech jobs, and I found a few interesting jobs in the Pioneer Valley that I want to share
- Fiksu: This company has offices in Boston and Northampton (right in downtown), and has an opening for a Software Developer in the Northampton Office.
Fiksu, Inc. is a progressive, creative, fast growing, cutting edge
advertising technology company for mobile applications. We build the
leading user acquisition platform to help brands achieve their
business goals faster and more efficiently than ever before.
Fiksu is looking for talented developers with a deep interest in big data, distributed systems, high scalability, open source technologies, and cloud computing. You might not have much experience, but you’re a disciplined software engineer who is excited to learn and use new technologies and methods.
- Communicate Health: This company is right down the block from my house — I pass it every day. I met their Senior Designer, Molly McLeod, at the Western MA Hackathon, and she posted this job recently:
Senior Web Developer
CommunicateHealth, Inc. is a health education and communication firm specializing in improving health literacy through user-centered design, policy, research, and content development. At CommunicateHealth, we believe people deserve clear information about their health. This doesn’t mean using short words and lots of pictures — it means making sure the information and services our clients provide can be accessed, understood, and used by the people who need them most.
The senior web developer will take the lead on many projects as our primary technical staff member.
- HitPoint Studios: The CEO, Aaron St. John, wrote to tell me about this position in their Amherst office.
Windows 8 XAML/C# Engineer
HitPoint Studios is looking for an experienced engineer to work on the development of engaging front-end user interfaces for Windows Store and Windows 7 games. We are seeking someone with one or more years of experience with WPF/XAML, familiarity with Windows 8 development (Windows Store apps for Windows 8 and Windows Phone 8), a strong background in MVVM design patterns, and a good eye for UI and UX design. The position involves maintaining and improving an existing reusable code base for multiple Windows Store and Windows 7 titles with similar front end functionality but varying UI views and feature sets.
- Atalasoft: Atalasoft publishes developer tools for imaging and capture applications. We have a great job for a web developer that wants to spend time helping software developers get to know our company and products better. It’s in the marketing department, and you’ll be creating technical content (demos, sample code, blogs, tutorials, copy for brochures, newletters, e-learning, etc) that we can use to reach developers and get them interested in our company’s products.
This is the latest in a series of limited perspective movie reviews. These reviews, inspired by a Letterman bit, look at only one narrow aspect of a movie, related to software engineering or software business.
SPOILER ALERT: These reviews assume you have seen the movie.
Oz is set in 1905, so it doesn’t have much advanced technology. I researched the novels of Frank L. Baum, and I was surprised to learn that he wrote a novel that introduced the idea of augmented reality. Also, in the Wizard of Oz novel, the emerald city isn’t made of emerald (as it is in the original movie and this one), but instead, Dorothy and her companions are given glasses to wear that make it look as if it is. Unfortunately, since my review is limited to Oz, the movie, I can’t write up a comparison between that and Google Glasses.
Instead, I’ll concentrate on the one big use of advanced technology, the wizard’s “ghostly head” effect. If you remember the Wizard of Oz, we first see the wizard as a ghostly head appearing in smoke.
Later, this is revealed to a projection from a complex machine operated by a man behind a curtain.
In Oz, we get a little insight into this machine. It’s implied that it was inspired by the Projection Praxinoscope.
He combined the idea with Phantasmagoria, which is the projection onto smoke.
The thing is, in both of these technologies, you need to put the image on a transparent slide to shine light through. In the wizard’s case, he was able to project his live head (not a series of still images). I see no reference to this technique anywhere, but it’s a plot point that he’s being helped by The Master Tinkerer (who, in the novels, created the Tin Man), so we can assume that he could invent something.
The only thing I can think of is using a one-way mirror somehow. When I researched that, I found Pepper’s ghost:
In this case, you are looking through a view-port (red rectangle) at an angled one-way mirror (green rectangle). The left area is out of view, and shows up in the mirror when it is lit. You make the ghost appear and disappear by raising and dimming the light in the off-stage area as compared to the area through the mirror.
So, it’s not a projection, but I could imagine a master tinkerer and Oz (who is himself a master in prestidigitation), could figure out some way to combine these technologies (all available in the late 1800′s) to a new live smoke projection effect.
What I can’t imagine is how the older wizard is able to upgrade this to show the green, bald head instead of his own.
Earlier today, I tweeted:
When I did, I didn’t look up #twitstarter, but now that I have, I think this might be the first serious usage of it. To be clear, #twitstarter is not the project I am asking you to back (more later).
To use #twitstarter, make a tweet with the hashtag #twitstarter, give a pledge amount, a goal, perks, how to pledge, and some indication of what the project is. That’s a lot to squish into 140 characters, but my tweet shows that it can be done.
Q: Are you serious?
A: Yes — note the use of the #thisisserious hashtag, universally recognized as indicating seriousness. Despite what you might see, this is actually serious (details to follow)
Q: How do I enforce that the pledger will pay?
A: You can’t really — keep the amount low, and make a judgement call
Q: How do pledgers make payment?
A: I’m planning to use paypal or cash.
Q: Are you planning to do more work on #twitstarter
Q: Do you mind if I work on #twitstarter?
A: No — If you do, I hope you let me pledge a dollar to you
When I read this about Climber (a new iPhone app that lets you post short videos to App.net):
Our video pages simply rely on App.net post data to retrieve links to video files contained in personal App.net file storage. If a user chooses to delete their App.net post, or even just delete the video file in their file storage, then it can no longer be viewed on our website.
It struck me that the full cost of the back-end of this app was being paid for by the user. Until this, developers typically paid for a back-end or relied on free services.
When the developer paid, they had to deal with their app having a low, fixed life-time value, but unbounded costs. They either added a premium subscription service (Evernote), in-app currency (mostly games), or ads. Another common solution was to get acquihired before it imploded and have the new owner assume the costs (Instagram) or shut down the app (nearly everything else, but recently, Summly).
If they relied on free services, then they risked the service going away. Mobile RSS readers that treated Google Reader as a sync-service now have to either create their own or see what develops. Twitter client developers got hit with limited user-tokens.
App.net is offering another choice – Bring Your Own Back-end (BYOBE) — where they sell the user on the benefits of a backend and deliver less value to the developer (for a lower cost).
BYOBE isn’t new with App.net. Salesforce users have Apex, where they can find 3rd party apps that run on Salesforce servers. Apex app developers do not have to build out infrastructure for their applications if they can stay within Apex guidelines. In some sense, Evernote premium is also BYOBE for 3rd party applications. In fact, any app developer who solves their business model issue with a subscription service, can also transition to being a BYOBE provider. I’d put Github, Dropbox, and many others into this category.
As I understand, a hugely divisive internal debate occurred among Twitter employees around this time. One camp wanted to build the entire business around their realtime API. In this scenario, Twitter would have turned into something like a realtime cloud API company. [...] I think back and wish the pro-API guys won that internal battle.
The price for developers is a flat $100/year. App.net gets its variable revenue from the app’s users as they must subscribe in order to use any app on top of the infrastructure. It’s tempting to think that they are paying for Alpha (their Twitter clone), but that’s just an app built on the infrastructure — they are paying for API usage, not Alpha.
App.net is not a paid service for mobile application developers — App.net is a paid service for mobile application users. The closest thing I can compare it to is iCloud, where users pay for iTunes Match or more storage, but developers get a syncing API to build on (or will eventually, when it works).
The benefits to users are clear (they are now paying, so they accrue some value)
- They control their data
- They aren’t sold to advertisers
- They can plan on some sort of longevity and consistency
Developers, who now have lower costs, also get less value.
- They give up control of the user and user data
- It would probably be harder to independently charge the user another subscription
They do get a service they can count on, but they could have that with Parse, Kinvey, AWS, or any number of paid back-end as a service companies. Most of the developer benefits are over free services, which I don’t think make sense to build on.
I certainly see why I’d want to be an App.net user based on this — but, since I don’t want Alpha (or message feed based services), it will make more sense when the app market is more diverse (not a bunch of Alpha clients).
As a developer, this model appeals to me because I think of this space more like a hobby — I would definitely forgo control to not have to think about or pay for the back-end. It would be even more interesting if App.net had a payments option or revenue share. Rather than Twitter’s limit of 100,000 user tokens, App.net is incented to reward a developer who gets that kind of traction. This brings costs to developers even lower (perhaps negative), and transfers value to themselves and users (they keep control of user payment data, and users have one bill).
I certainly don’t think this is the right mix of values/costs for every user — the key will be if the user thinks of themselves as having paid for an app and then get the services (and the other apps) along with it. Then, each different app category brings in different users. For example, it feels like Alpha costs $36/year, but what if you paid $36/year for your (let’s say) project management app, and just got Alpha for free? If Alpha is ever to have an enormous user-base (who all still pay for App.net), it has to be because they think they are paying for apps.
If there’s any kind of model for this, it’s the fact that I buy a data-plan for my phone and bring it to my apps. App developers do not have to sell me a data-plan. I buy electricity for my toaster, water for my shower, gas for my oven — consumers are no strangers to buying infrastructure.
Come to think of it — is this the natural order? The main alternative is turning out to be infrastructure subsidized by ads.
I noticed that Horace Dediu, the founder and main author of asymco, recently started adding sponsored content to his site. Typically, his articles are data-backed analysis of the mobile market. To get a quick idea if you don’t know it, see this recent entry titled Revolutionary User Interfaces. In it, Horace uses data visualizations to show how Apple disrupted the phone market with multi-touch.
It happened despite having a clear, front row view of the transition of the industry from mobile voice to mobile computing. The shift in the basis of competition from “connecting people” to “connecting people to data” ended up being a classic disruptive trap. Many will argue that it was the failing of individual managers. Perhaps, but how did they conspire to fail simultaneously?
When you see disruption happening, it’s natural to seek out a cause, a pivotal magical “force” or event that enabled the weak to humble the strong–the proverbial sling that enabled David to defeat Goliath.
The article is worth reading, but what I wanted to point out was how his sponsored content is as interesting as a typical article. This one for Textastic reads almost as a follow-up.
With the new touch-based devices of today, we are seeing similar migrations of utilization to new jobs to be done. The simpler creative tasks migrate first and the advanced (or emergent) uses follow. Like with the microcomputer, the first common creative task for tablets happens to be text-based editing.
I have been giving a lot of thought to this kind of advertising, where it is as useful as the content to the reader. This is more than just relevance and unobtrusiveness, as I think advertising from The Deck accomplishes on sites like Daring Fireball. Instead, it turns advertising into something that I would read eagerly and perhaps miss if it were gone.