Archive for February 2012

Search for Jobs Using the Jobvite Facebook Application

It’s live!

From the email:

Employees can now automatically match Facebook friends to open jobs then easily invite them to apply in just a few clicks. No spam and no automatic posts. All users choose what job-related information they want to share with friends.

Job seekers can privately request referrals and view job listings at their friends’ companies. They can Jobvite friends or apply to the job directly within Facebook. And, they have complete control over what, if any, information from their Facebook profile is shared with a potential employer.

Go here to install it. We have hundreds of customers like Twitter, Groupon, Living Social and LinkedIn.

 Comments | Comment

Taking The UX Drinking Game Down To San Diego’s UX Speakeasy March 31

The UX Speakeasy Conference  is on March 31 at the San Diego Zoo — rumor has it, they’re going to let me out of my cage.

They have been kind enough to invite me and Dylan Campbell, a great recruiter out of Los Angeles, to talk about all aspects of interviewing and writing your resume as an User Experience Designer:

From Application To Interview: How To Get A Great UX Job

The process of getting a great user experience job isn't as hard as you would think. This workshop covers all aspects of the interview process,from presenting a great resume and portfolio, what to expect during an in person interview, and how much flexibility companies have in salary and compensation. Also covered are questions to ask during the phone screen and in-person interviews, how to spot trouble signs, and what else to look for so you can find the right culture for your skills and career.

One of the breakout sessions will also include the UX Drinking Game: “If a conference invites two guys to talk about something they know nothing about, drink.”  The attendee that comes up with the best reason to drink will win a George Foreman Grill.

It’s only $179, not bad for a one day event. Don’t go just because I’ll be there:  Aaron Irizarry, Angel Anderson, Dennis Wixon and Russ Unger are going to offer their thoughts on our wonderful industry. And you get a free ticket to the San Diego Zoo to boot! Such a bargain!

You should go. I’ll bring the hooch.

Ping me and I’ll give you the promo code for 15 percent off that $179.

 Comments | Comment

Digital Trends: The Re-imagined Windows 8 Metro Concept That You Wish Was Real

Gorgeous. You have to see this:

The clean, re-imagined Windows 8 concept is a refreshing break from Microsoft's Metro user interface. It's a kickback to earlier versions of Windows, and has us wishing that Microsoft could buy out Phyek's design to offer it as an alternative. Don't get us wrong, Windows Metro aligns with Microsoft's 2010 mobile operating system, Windows Phone "Mango", and in itself is an innovative product. Microsoft developed a solution for integrating social media, and up-to-date information, alongside the typical icons for files that all operating systems to this day have used.

One thing is sure: Metro is absolutely far from a mimicry of Apple's OS X. As  ZDnet  humorously  points out, it brings back memories of 2006, when Apple's Bertrand Serlet compared the uncanny similarities between Mac OS X Tiger and Microsoft's Windows Vista. Microsoft's fervent desire to differentiate itself from Apple has been evident, and to that extent, the designers over at Microsoft have accomplished their goal with Metro.

 Comments | Comment

Forbes: How Apple Listens to Its Customers

Apple turns bad customers into more profitable customers. Here’s how:

At Apple, store managers call every detractor within 24 hours. Initially, they found there were some detractors they couldn't reach. Subsequent studies showed that detractors that they did reach purchased substantially   more Apple products and services than the others. Further studies showed that every hour spent calling detractors was generating more than $1,000 in revenue or additional sales of $25 million in the first year, which was a good return on the investment.  

In traditional management, where customers are secondary, the expense of following up with customers would seem like the first kind of expense to cut in a crunch. With these numbers in hand, Apple's managers realize that this is one of the last things that should be cut.

At Apple, customer focus is thus not a vague slogan. It's at the core of the way the stores are managed. Employees know where they stand among their peers in terms of NPS and where their stores stands relative to the rest of the stores in the region.

It makes Apple a lot of money:

Where a typical electronics store averages $1,200 per square foot in sales, mature Apple stores exceed $6,000 per square foot-the highest productivity in retailing of any kind.

Thus Apple practices  radical management, where making money is the result, not the goal of the organization. The bottom line of its business is to delight the customer. We are indebted to  The Ultimate Question 2.0  for showing us how they accomplish that on a daily basis.

 Comments | Comment

Users Know: Limited Products Versus Shitty Products

What should be built is a question all software development companies struggle with. If you don’t launch enough of a feature set, user adoption will suffer.

Laura Klein makes a compelling argument that launching a limited product that solves a user need and then improving on it is a better than launching a product that’s packed not only with features but bugs and usability issues.

Great post:

A limited product is something that may not do much, but what it does, it does well. It makes it clear to the user what it does and what they should do. It solves a serious problem, or perhaps a small part of a serious problem. It doesn't crash relentlessly. It doesn't have enormous usability problems.

But a limited product probably doesn't do anything else. It doesn't have bells and whistles. It doesn't have "nice to have" features. It may only support the problems of a small subset of the market. It may only be released to beta users.

A shitty product, on the other hand, often tries to do too many things at once, and it doesn't do any of those things particularly well.

You really don't want a shitty product because, when people don't use it, you have no idea if they aren't using it because you have a bad idea or the wrong market, or if it's just because your users are confused and turned off by your shitty product.

Shipping a shitty product is one of the best ways to get a false negative on your idea. People will use products that aren't "polished." They will abandon products that are just bad.

So, when I'm yelling at you to Fucking Ship It Already, I don't mean that you should ship something bad. I mean that you should ship something limited – something that is small enough to be shippable and usable in a very short amount of time.

And then I mean that you should immediately improve it and ship it again.  Do this over and over again as many times as you can for as long as you can.

 Comments | Comment

Adam Colson: What an API Product Manager does

Adam Colson is a product manager I’ve worked with, and he works as a product manager that manages mostly APIs. Great User Experience designers should understand how APIs work and how to consume them. I personally love them, because once I understand an API I want to think of great ways to use it.

Great technical companies now create APIs for all of their data so front end engineers can consume it. It requires foresight, but enables much more flexibility. There was a famous post about Amazon’s services on this that’s also worth reading.  

He wrote this post to describe what he does. Cheers.

Often times I’m asked what it is I do. I usually answer with a short response like “I sit behind a computer most of the day and send emails” or “I help build Web sites and apps”. You see, describing what a product manager does to someone not in technology isn’t easy. You want to tell them in intricate detail what it is you do but you don’t want to bore them or tell them something that will just go right over their heads, like “I write product specifications for RESTful APIs”.

Recently, a VP of Engineering where I work reached out to me to help understand what I did, so that they could better identify a candidate for an API/SOA product role that they were looking to fill. The questions were:

  • What are the responsibilities of this product manager?
  • How do you define what is done by product and what is done by an engineer?
  • What type of documentation is produced by this product manager?

An API product manager’s responsibilities

An API PM is a fairly specialized product role. My experience in job searches is that there simply are not a lot of these types of roles out there. Hence, there is probably also not a lot of product candidates with explicit API experience.

It seems most organizations see APIs as a feature or bi-product of a larger feature. Organizations that take the distribution of their data and services seriously realize that making APIs a product and applying product management disciplines is key to success. So don't despair if the field is small or the perfect candidate doesn't surface.

That said, here is a quick summary of my role as the Product Manager responsible for APIs. Maybe finding candidates with this skill set and experience, plus the necessary technical understanding, will work.

Product  Manager Responsibilities

  • Subject matter expert and product expert for API or other products that are managed
  • Deep understanding of client needs and market trends, through client interaction and other market research
  • Owning and creating the product strategy and roadmap
  • Reviewing the roadmap with key stakeholders
  • Determining product priorities, including new features and bug fixes
  • Owning and creating the business/product requirements documentation
  • Managing feature iteration throughout the product lifecycle
  • Management of client API integrations and pipeline
  • Ownership of API documentation (ie – developer's site)

API  Engineer Deliverables

  • The product manager defines the "what", while the engineer defines the "how"
  • API architecture
  • Development of API features and functionality
  • Documentation of how specific methods work
  • Description of how to test specific methods (for QA – if applicable)

 API  PM Deliverables

This is using developing a new Web service for an existing system as an example.

  • Black box use cases (or user stories in Agile development methodology)
  • Description of services needed
  • Description of functions (ie – method calls) needed for each service and what they should do
  • Specific requirements for each method call:
    • Is it for Creating, Reading, Updating or Deleting data?
    • What are the data or input parameters?
    • What business rules or conditions should be respected or created?
    • What data inputs should be validated and how?
    • What should be returned in the response?
    • What data should be validated in the response?
    • What exceptions should be handled? If a business rule, condition, validation or other logic didn't pass, what error response should be returned?

You can read the rest of his blog here.

 Comments | Comment