The biggest risk in hiring product people is… THE UNKNOWN.
- What if we hire this person and they aren’t able to execute?
- What if they can’t negotiate with our engineers?
- What if they can’t operate under conditions of uncertainty?
- What if they worry over every little detail until they’ve totally missed the big picture?
- What if they just say “yes” to everything so we lose our focus?
- What if they blithely accept our broken processes and bad habits so that we keep making the same mistakes?
In the past month, I’ve spent quite a bit of time being the interviewee, the interviewer, and the resume mentor. And the biggest mistake that I’ve made myself and seen others make is in being too neutral.
You don’t want to make a bad first impression. You don’t want to come across as someone argumentative and difficult to work with. You want to make it clear that you’re flexible and adaptable.
And that leads you into exchanges like this:
Interviewer: “Which development methodology do you prefer working with?”
PM Candidate: “I’ve worked in companies where we did waterfall, as well as agile, as well as daily releases, and I’ve been able to be effective in all of them.”
The interviewer thinks: If you were working closely with engineers and customers, you’d have directly felt the pain of what didn’t work. Either you were pretty hands-off (bad) or you don’t reflect on your work and process to see how you can drive improvement (also bad).
Interviewer: “Tell me about a time when you’ve dealt with conflict between product management and engineering/design/sales.”
PM Candidate: “I believe in working very closely with other teams and keeping the lines of communication open so we can avoid conflict.”
The interviewer thinks: Seriously? There are always differences of opinion and conflicting priorities. Either you just say “yes” to everything (bad), or you are oblivious to the fact that sales hates you (also bad), or your upper management takes all decisions out of your hands (maybe not your fault, but doesn’t make me want to hire you).
Interviewer: “What type of difficulties do you foresee in working with our product/culture/customers/distribution model?”
PM Candidate: “I’ve worked with X before, so I’m very confident that I’ll be able to handle the job here. Here’s an example of a related awesome thing I’ve done in the past.”
The interviewer thinks: If you are a good candidate, this isn’t your only job option. You should be critically thinking about the “cons” of this job and why you might not want it. If you haven’t, that’s a warning sign. If you have, but you’re not comfortable articulating them, how are you going to handle day-to-day communication and negotiation here?
It’s true that expressing your opinion may lose you a potential job. If you’ve eloquently detailed how you advocate user-centered design and incorporating customer research into the development process, the company where engineers call all the shots, is not going to offer you a job.
This is not a bad thing. You wouldn’t do great work at that job anyways — and how are you going to land your next job with a bank of mediocre work and no positive references? Better to dodge that bullet now.
If you have work experience, you have opinions. As a hiring manager, I want to hear them — as well as the context that you formed them in and how you arrived at them. Maybe you dislike a certain process because you’ve been burned by it in the past but you can see how it could be beneficial… or maybe you’re just closed-minded and resistant to change.
No one worries that you’ll be flat-out incompetent — if you were, it’d be blatantly obvious after a couple weeks, your manager could document your flaws and have you out in no time. But an employer is petrified that you’re going to be not-quite-right in more subtle, insidious ways that won’t be noticeable until it’s too late and you’ve botched a product release or customer relationship.
The tricky thing about product managers is that every candidate is different, and every past environment is different. Just because the last product you managed was a runaway success doesn’t guarantee that you were the reason why — maybe it was “right place at the right time”, maybe your boss made all the decisions, maybe it succeeded in spite of you. Same thing with product flops — maybe the market tanked, maybe your boss made all the (wrong) decisions despite your recommendations, maybe there was an engineering disaster. So your resume doesn’t really set the hiring manager’s mind at ease.
It’s your job as a candidate to make the hiring manager feel better about those risks. And how do you do that? By being opinionated. Give examples. Explain the “why” and “what I learned”. Write blog posts. Answer questions on Quora. The less of a “black box” you can be, the better candidate you’ll be.
Popularity: 11% [?]
December 2nd, 2011
View Comments
I was lucky today to have a day to spend with my 2-year-old daughter. In the morning we walked up and down ten city blocks, stopping to pet dogs, sit on stoops, and inspect leaves and spiders. In the afternoon we went to the Exploratorium, which is a ridiculously award-winning and enriching museum.
Truth be told, I’m pretty sure she had more fun just walking around for free. But as the adult who had to pull out a credit card to pay for museum tickets, I can’t help but feel a tiny bit like she ought to have had more fun at the Exploratorium.
Has anyone ever tried telling a child, “This cost a lot of money – you’d better appreciate it!”?
Has anyone ever had that work for them?
Of course not. Sure, you can tell them that something cost $10 or $100. You can also tell your dog that something cost $100, and they’ll comprehend your point about as well.
A small child cannot possibly understand what it means that something costs X dollars, because the experience of earning money and having both obligations and options on where to spend it is entirely outside of their sphere of experience.
But they know when they are having fun! You can’t trick them into thinking they are having fun when they are not.
As products people, we often do the same thing to our customers.
We know how which features took the longest to build, we know where the underlying technology is incredibly elegant and patent-pending, we know which of the components are the most expensive to support. So we say, “hey, this is what you should find valuable.”
But customers don’t care. They don’t care how long you spent coding it, they don’t care that other engineers think your technology is jaw-droppingly awesome, they don’t care how much or how you support it.
All they care about is, am I having fun?
Sometimes customers try to clue us in, and they tell us about your product or service’s Benefit K that they find life-changing and awesome (and yes, fun). But if Benefit K isn’t one of the parts we’re especially proud of, we ignore it. We think, “well, they ought to be appreciating Benefit Q,” and then we headline our marketing campaigns with the awesome advantages of Benefit Q.
When you do this to a small child, it doesn’t take long before the child starts thinking two things:
- “If this grownup really thinks it’s more fun to do X than to stomp in puddles, perhaps they aren’t very bright.” and
- “I am concerned about what other dumb decisions this grownup is going to try to force on me.”
Your customers are thinking the same thing.
Popularity: 18% [?]
November 3rd, 2011
View Comments
As I discussed in the previous post, many products have terrible design because the design team doesn’t get to use the product, and because design is brought into the process too late.
I’m going to discuss two more reasons which extend beyond the design team.
The first one will not be a surprise to anyone who reads this blog regularly — most products are poorly designed because the product leadership failed to get out of the building and talk to customers. Another way to state it is an overvaluing domain expertise.
Don’t get me wrong – complex products require a product manager who understands the rules of the game. I don’t want to use brokerage software created by someone who doesn’t know a 401K from a 529 plan.
But it takes more than knowing the conventions and constraints to build a great product experience. You need to be able to anticipate your customers’ concerns and fears, to know where they’re likely to be confused and need reassurance, to understand the context in which they’re using your product.
When you have deep domain knowledge, it’s hard to remember what it was like when you did not have that information. (see: the “curse of knowledge”, popularly explained in the book Made to Stick).
When I worked with financial software, I commonly heard product managers and engineers explain a certain workflow with “but this is the logical choice!” How many people do you know who are logical about their money? Money is emotional. Things that threaten our money (or anything that is important to us) scare us and turn us into irrational creatures.
Products that are designed by rational humans but used by irrational humans… usually doesn’t result in a positive user experience.
To overcome this, you need to make a conscious and deliberate effort to understand your customers. What is their mental model? What are they concerned about? What is their comfort level with this task? You need the ability to put aside your domain expertise and see your product through the eyes of the uninitiated — and this is a challenge.
Most of us work really hard to become experts at something, and it goes against our nature to spend time pretending to not be experts.
The final reason why most products are poorly designed is that the product development process doesn’t get feedback fast enough.
Raise your hand if this sounds familiar:
Company: “Oh, we always do user testing to identify any usability issues or confusion with our products.”
Me: “That sounds good. When do you usually do your testing?”
Company: “We do our testing when we have a real working beta; that way we’re testing the real app so we get the most accurate results.”
Me: “So, if your testing uncovers major issues, how long do you have to address and fix them?”
Company: “…A few weeks.”
User testing is too often just lip service. If your product is fundamentally wrong — and if you made the first 3 mistakes I discussed, it almost certainly is — you can’t just patch that up in a couple of weeks. Not only would that require your engineers working 36-hour days, but now your whole organization is invested in the thing that has already been built, is already working, was already promised to customers.
Even if you made incredibly good guesses, even if you talked to customers before you started building — if you wait until the product is 90% complete to get feedback, you might as well have not bothered. You’ll learn what you should fix in the next version, but for startups, you may not have the luxury of a next version. This version needs to meet a minimum value threshold or you’re headed for the deadpool.
The way to fix this is simple.
Get feedback sooner. Build that into your schedule:
- Interview customers before you start building and use that feedback to identify changes to your requirements.
- Show early mockups to customers and iterate based on that feedback.
- Show early prototypes to customers and iterate based on that feedback.
- Find ways to manually emulate the “finished product” experience and share that with customers, iterate based on that feedback. And, of course
- Look for ways to build the 2-week version and then another 2-week version and then another 2-week version — instead of the 6-week version where you’ve invested a lot of all-or-nothing time.
Sounds like a lot of work. But the hours you spend on gathering that feedback pale in comparison to the hours you waste when giant features or releases have to be thrown away and redone. (And let’s not even talk about the morale hit…)
Popularity: 16% [?]
October 26th, 2011
View Comments
(Originally answered on Quora.)
Why do so many products have crummy design?
Many designers do not (fully) use the product they are designing. Sometimes this is due to laziness on the designer’s part; much more frequently company culture and the product management/engineering organizations are to blame. Why?
Many applications — especially B2B applications — are difficult, if not impossible, to use in an isolated manner.
A single designer who sets up a project in a project management application may be able to input tasks, but they are not truly “using” the product and experiencing the use cases they are designing for unless it has real projects and real team members interacting with it.
For any product that relies on customer data (and nowadays, that’s almost everything: personal financial applications, social, local, analytics, healthcare), you can’t really recognize what is difficult or unclear unless you are looking at your, relevant, personal data. Sample data is a poor substitute (though better than nothing!)
The other reason is that, in many organizations, designers are brought into the process too late.
Instead of being included in early discussions where business goals and constraints are identified, designers are often thrown a fully-written spec and told to “make this pretty”.
This is basically impossible: all the visual design in the world can’t save features and workflows that shouldn’t have been spec’d in the first place.
So how do we fix this?
Here are some of the things that are needed:
- Product management needs to involve design early in the process
- Product management needs to explicitly define problems, business goals, and constraints
- Design needs to also have access to other teams who are familiar with customer problems — customer support*, sales, engineering — and the company culture needs to support a “there are no stupid questions” mindset
- Executive management needs to buy-in to the idea that designers aren’t just there for ‘making it pretty’ (i.e. schedules need to support designers taking part in early meetings)
- Executive management needs to lead, top-down, a company cultural expectation that “everyone uses the product, no exceptions.”
- Design, product management, and engineering need to collaborate to provide internal tools that support use of the product (e.g. sample data, test accounts, training)
*Customer support, incidentally, is the overlooked knowledge gold mine in most companies. They know why customers are unhappy, cancelling, or singing your praises, but they rarely get to share that info with other teams.
Those are the first 2 reasons – and, in my experience, the most pernicious. Next week I’ll cover the other 2 problems, and how your organization can improve upon them.
Popularity: 19% [?]
October 6th, 2011
View Comments
