Posts

Showing posts from 2010

The Vision Thing

A US president once said he wasn't very good at "the vision thing." (He wasn't re-elected.) Product managers can't afford to be anything less than great at the vision thing. The product vision is the glue that holds a team together. It's a great tool for herding all the development, marketing and executive cats in the same direction. But it needs to be sound, it must be straightforward and compelling, and it needs to be communicated well and often. A product vision is pretty much what it sounds like: something that enables anyone to see clearly what the product is, does, and who it's for. Beyond that, there isn't really a formula for defining a product vision - it's the product of good research, clear analysis and, most importantly, imagination. A good product vision usually seems obvious in retrospect:. Take the iPod: An elegant-looking pocket music player that non-techies could learn quickly and easily download songs from an online stor

Focus Groups, and Unfocused Groups

Sometimes useful revelations come from focus groups. If you ask the right group of people really good questions, you can validate (or disprove) a theory. Sometimes you can identify customer problems that provide opportunities for new product solutions. Sometimes . The trick is going in with the right expectations, and knowing when alternative methods, such as customer interviews and surveys, may be better. I've used focus groups to explore customer attitudes, and to validate the viability of product concepts. Careful questioning about "how you do it now" can be useful, especially when the group becomes engaged and discusses their personal experiences. This is where focus groups can work: getting people to open up, describe their experiences and compare notes about current problems. (Important note: Having a top-notch moderator is essential: if you can't shut down a loudmouth, your group will be a waste of time. But it can be hard finding a good moderator who unders

Surveys: You Get What You Ask For

Recently a product manager mentioned that he was doing a "quick little survey" of his customers. Being the curious sort, I asked "how quick and how little?" and he said "oh, with Survey Monkey I can do a thirty question survey in a couple of days." I let it go at that, but I could have asked " should you do it in a couple of days?" Yes, it's possible to post a survey and get results very quickly, especially if you have a pre-identified or captive audience, especially if you limit it to two or three concise questons. But if you whip up a few dozen questions and expect to pop the results straight into PowerPoint, you may be disappointed. First, asking the right questions is tricky. If you ask too many, or they're too complex, people won't complete the survey. Worse, if you ask ambiguous questions, you'll get answers that may be impossible to analyze, or may even mislead you. It's crucial to use the target person's lan

Feedback is Where You Find It

Recently I was talking to a PM from a consumer products company. I mentioned that the feedback for his products on Amazon was pretty good. He looked a bit offended, and said "that's not very scientific - we try not to pay too much attention to it." There are a LOT of customer comments about his product. The majority are good, some are not so. As a sample of his customers (and possible customers), he's right that it's a pretty atypical group. But worthy of being ignored? There are two kinds of people who write customer reviews on the web: Those who tried the product and have a really strong opinion, and those who have a really high opinion of themselves and want to share their every thought. Kind of like bloggers and twitterers. And people will review almost anything - software, MP3 players, music, books, deodorant - you name it. Actually, there's one other type of contributor: People who review their own products or competitors products. But we'll i

Who Needs a Roadmap?

Who needs a roadmap? Anyone who's going someplace they haven't been before. And creating or enhancing a product is always a new journey. A product roadmap explains where you're going, and describes your routes and stopping points along the way. Its purpose is to get you where you want to go. It's not, however, a list of what you're packing in your suitcase or what you're going to eat at each rest stop. A good roadmap lists the high level functionality that is intended for each product release, as well as the reason for choosing this configuration. The reason shouldn't just be "we have to build function A before function B", but instead should explain why the release configuration will make sense to customers…and why it will excite them enough to use it, buy it, or upgrade. The roadmap should name the release - not with numbers or code names, but referencing target markets or personas ("the health services release" or "the syste

Consistency vs. Innovation

One of the most vexing user experience questions is: When must applications be consistent with each other? When is it OK to invent news ways of doing things that require users to relearn established methods? There is rarely an easy answer, but a Product Manager can play an important role in making these decisions. Most of us assume that it's a good thing when a mouse click performs the same action in different applications. Few of us miss the bad old days when every word processor had its own conventions, and there were no Windows interface guidelines and web interaction conventions. De facto standards have been created by successful products and suites, such as Microsoft Office and the Adobe suites. If you've learned one application, you've learned most of what you need to know to use another. But product designers are constantly confronted with opportunities to do things in a better , but different way. Is consistency an inviolable "must", or, as the saying

Personas: How Many Are Enough?

Personas provide a great way to focus your efforts on a specific type of customer. Which is why I was taken aback when a colleague proudly told me that he had provided 37 personas to his team. Focus. That's the point. Personas are descriptions of archetypical customers - they represent the common attributes of a large number of people. They can provide reference points for everyone involved in the planning and development process. Well-developed personas enable a software developer to say "Harry wouldn't be able to use that feature" or an marketer to say "Elaine needs to be able to justify purchasing the product to her manager." Personas should be a constant reminder of who the target customers are. For this to happen, Product Management has to create personas that are vivid and few . Vivid personas provide insight into the customer's problems and motivations; they can begin to convey the kind of gut-level connection that you get when you visit

Passion

Someone asked me recently: What's the most important unteachable trait to look for in a product manager? Passion . All the skills can be learned. The procedures taught. Business strategy can be picked up by experience (or maybe even in business school). Agile development can be learned on the job. Even leadership skills and public speaking can be coached. Passion can't be taught. A passionate product manager believes in her products. In fact, it's hard for a passionate PM to work on products that she doesn't believe in. When that happens, she may decide to move on. Matching people to their passions is important in hiring, and in management. It's crucial to recognize that different people are passionate about different things - one person may be excited about digital imaging applications, while another is enthusiastic about eLearning systems. When a PM believes in a product, its success becomes important on a personal level. Failure becomes, as they say, n

Softball and Software

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,

P-Camp 2010

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"

Just-in-Time Usability Testing

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

You Are Who You Hire (part 2)

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

You Are Who You Hire (part 1)

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&#