If you are just looking for warm bodies to collect a paycheck, by all means, use that generic job description.

An acquaintance of mine is starting a new job board for software product managers and marketers. Her angle? Submit a job posting and you’ll get feedback on how to make it more compelling. I love it.

Take your average rockstar candidate (as though there were such a thing!) - if a recruiter calls them up with an opportunity, what is their first question going to be?

Why should I work here?

Can you answer that?

Look at your company through the eyes of a job applicant:

• Google your company to see what the first impressions are
• Visit your company website - is it attractive and up-to-date?
• Visit the “careers” section of your company website - does it answer the important “Why should I work here?” question?
• Search job boards to find other companies who are advertising for the same position. Print out their job descriptions and put them side by side with yours. Is yours more interesting? Easier to skim? Does it direct the job applicant to where they can find out more about you?

Most hiring managers won’t have any control over the content of the company homepage - that’s why the job description is so vitally important.

When I was hiring for an interaction designer, I thought to myself, Why would a great designer want to work here versus somewhere else? I jotted down what I loved about our culture, skimmed through the Interaction Designers mailing list I’m on and read designers’ frustrations, and I read through my folder of “happy emails”. (I strongly recommend all product managers and designers have a mail folder where you keep all the positive feedback from your users - some days you’ll need it.)

I wrote a “Why work here” section with 4 bullet points. Then I sent it to some co-workers and asked for their feedback and tweaked it a bit. I sent it to HR to make sure it was kosher, then added it to the rest of the qualifications/overview section. I emailed the whole thing to myself, to see how long it was in an email window, and then trimmed it a bit as a result.

In total, it probably took me an extra four hours of active time versus just going with the generic description. I consider that a non-trivial amount of time. It also landed me with a terrific candidate within a week, one who chose us over several competing offers. Time well spent!

How many times have you been in a postmortem meeting where the “bad” items were no surprise to you? Where people sheepishly admitted, “Yeah, I guess we should’ve expected that would happen.”

To borrow some wisdom from a CTO friend of mine, “The problem is that you’re basing a plan around assuming that the code works.”

You have to assume that things will fail, and plan for how you’ll deal with it when it does happen.

(more…)

“This is far too specific! How did we know that we had users like this? What if our users were actually 45 years old, or not college-educated? We can’t risk thinking like this - what if we think these are our users and then they aren’t?”

The origin of this outburst was sharing one of my team’s sample personas with a marketing manager.

Persona Analysis is the process of identifying individual person representatives for your target audience and fleshing out their traits, likes and dislikes, frustrations and limitations. For most designers, this is an invaluable tool for remembering “you are not your user”.

For product managers, personas provide a framework for writing use cases, justifications for feature requirements, and an easy way to educate other teams (engineering, QA, customer care) on the “why” of what they’re building and supporting. It’s so easy to think, “this is important to me, so it must be important to my customers,” but having those clear personas is a great gut-check. If someone on your team who loves tweaking website preferences is pushing really hard to support CSS skins, it’s not hard to look at “Donna” and realize that she will never, ever take the time to switch skins or customize a page layout - she doesn’t have the time and that’s not her priority.

In an ideal world, the personas for your products are based on measurable evidence. You look at usage patterns, look at the market for your industry, and you do some primary research with customers, and based on that, you can draw up a very accurate picture.

In a non-ideal world, you take whatever you have. In our case, our personas originated from three sources of feedback: our beta user community, the in-house usability tests we conducted, and voice of the customer feedback from one of our biggest clients. These sources painted three distinct pictures - a “hard core” early tech adopter type, a “time poor” household manager type, and a “high net worth” investor type.

Are these personas the most accurate pictures of our users? Probably not. But - here’s the important part - they are not us. Having the intellectual discipline to think not just as “yourself” or “teamself” is a difficult thing, maybe a scary thing. But what choice do you have?