Product Management Journal

If you've ever worked in a state-of-the-art usability lab, with skilled user experience staff, you probably find it hard to consider a product finished until it's been tested for usability. Unfortunately, most companies don't have the infrastructure, budget or time for this sort of testing. While I believe it's too expensive not to do usability testing, I know that it's still very difficult for a PM to insist when deadlines are tight and there's no in-house usability infrastructure. Not doing usability testing costs money and time - the later a usability problem is discovered, the more it costs to fix. Find a problem in the spec/prototype stage, and it's trivial. Find it during beta testing, and it's a lot more expensive to fix. Find it after shipping, and the cost can be measured in extra tech support and lost sales, and then it may still have to be fixed in the next release. Clever user experience designers (you have some of them, right?) have d...

Hiring someone is a little bit like getting married. You're making a long-term commitment to spend a lot of time with him or her, you'll depend on each other in many ways, and it's not easy to end the relationship. So the hiring process is like dating - you want to find out a lot about each other, and like dating, it's not just about technical qualifications. Here are some different approaches to getting to know someone during the hiring process. Interviews usually start with a discussion of the candidate's past experiences. As an interviewer, it's important to press for details, not just hear the rehearsed story. For example, you can ask:   - "Why did you leave a job?" Press for details and ask how to confirm them. Is there someone, not necessarily a supervisor, you could talk to, from the previous job? You can learn a lot from a person's reaction to this, even if you don't follow up. And when you ask about why they left another job, you ...

The recession has done strange things to the hiring process. Few openings, many applicants. Stacks of resumes, many embarrassingly overqualified, some grotesquely underqualified. All too frequently, companies are treating applicants poorly, not following up after interviews and behaving arrogantly. And often people are hired in a hurry, without sufficient scrutiny. Hiring may be the most important process at any company. Everything else depends on having the right people in place, especially when it comes to product managers. But whether you're hiring a product manager, a CEO, or a product support rep, your company's future depends on having the best people in place. You are who you hire. Hiring the right person isn't that difficult if you know what you're looking for, make the effort to get to know applicants well, and are patient. Here's what I look for when I'm hiring, in order of importance: 1. Intelligence . You can't teach this, and if it isn...

A product manager has to be demanding. Literally: It's part of the job to demand that the product be built properly, in a timely manner. Tactfully and politely, of course. Open to suggestions and negotiation, certainly. But you still have to be demanding. Of course, it's nicer to request than to demand. At least, that's what my mother taught me, and it's certainly a lot more comfortable. Since the members of a development team usually don't report to the PM, then it's important to be on comfortable terms with the team. But that doesn't mean that demanding results isn't appropriate. A product manager is in-between groups that want timely results (management, Marketing and Sales), and groups that have to produce the results (Engineering, QA). Sometimes these relationships can become stressed, or even adversarial, if development has trouble meeting expectations. Product management, being in the middle, is often in the best (or only) position to resolve...

Long ago I studied architecture by designing and constructing buildings for my college. It was a unique program, and, in retrospect, it was an agile development process. Building design is normally a classic waterfall process, so it's interesting to look at what happened... Each project was run by a professor-architect . We began with a plan that included the building program (requirements) and a basic framework for the design, with few details. Every few weeks we would get together and agree on the next part of the project, craft the details, and begin what we might now call a sprint. Every morning we would meet (our scrum): the crew of students, the faculty architect (analogous to the product owner), and our professional contractor (our scrum master). In the summer, we would meet on the site; in the winter (this was Vermont) we would meet in a small construction shack around a hot woodstove, and draw on the walls (which we would paint over periodically). Our designs were increm...

The First Law of Priorities: Raising the level of one priority requires lowering the level of one or more other priorities. Otherwise, it requires changing the schedule, adding new resources, or compromising quality. This law is often very unpopular. Many managers would love to repeal it. Here's a typical scenario: The Product Manager has identified "installation user experience" as the number one priority for the next sprint. Meanwhile, Sales meets with a top customer who says he "must have" a new printing feature "immediately." Management decides that this should be added to the top priority list for the release. Obviously, something has to give. Extend the schedule? Add people for design, programming and QA? Or jam it into the existing schedule, using existing resources, and overlook the fact that quality will inevitably suffer? Unfortunately, the last choice is often the road that's taken. Why? Well, sometimes it's hard to say no. When mana...

Everyone has a different idea of what's "good enough." What's the best criteria? Getting quality right is important: products (and whole companies) have failed because a product was not good enough, or, because it was good enough and didn't get to market while it was being "perfected." It's the Product Manager's job to identify the appropriate level of quality for a product, and to see that this gets to market promptly. I once built furniture and cabinetry with a guy named Robert. He was a terrific craftsman, and had very high standards. Our woodworking shop was next to a river, and whenever Robert made a mistake, he would go outside and throw the less-than perfect piece into the river. Robert was good enough that not a lot of stuff went into the river, but he threw away things that other people would have used. And his finished work was gorgeous. I learned a lot about making things from Robert. I learned that sometimes there is a right way and ...