Product Management Journal

I've coached girls softball for years, taking one team to the national championships. It's interesting to look at the ways that coaching a softball team is similar (or not) to product management… - In softball, mastering the fundamental skills is the foundation for success. Without this, no amount of strategy or motivation will lead to success. One weak player can lead to many losses. - In product development, there are specific skills that are absolutely necessary, such as mastery of development tools, design capabilities, and architectural vision. One missing skill can sink a project. - A softball team must be motivated to succeed. Goals, both for both the team and individuals, can help a team continuously improve its performance. These goals can be about both competition (beating a team or winning a championship) and personal performance (improving batting or fielding results). - A development team can usually produce something even if they're minimally motivated,...

A day at Silicon Valley P-Camp…very refreshing. P-Camp is a free information-exchange event for product managers. This year's event was held at Yahoo headquarters in Silicon Valley. There were many hundreds of PMs there…kind of a scary thing, when you think about it. I can't imagine that more product managers have ever been packed into one room. The beauty of this event is that it exists for everyone's benefit. The attitude is that if we all get better at what we do, then it's good for all. Never mind that there were many competitors there - in a way, we're all in this together. Product management is hard, so we might as well learn all we can from each other. It works. Oh, and it's free. P-Camp features class-type sessions that are chosen by the attendees. People propose sessions online, and attendees vote on which ones they want. The winners are given one-hour time slots, with 6-8 sessions at once. Topics ranged widely, from" PM Productivity"...

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...