The Productologist

Product Manager’s Desk Reference by Steven Haines

There are books and there are Books, and with 700+ pages, the Product Manager’s Desk Reference (PMDR) definitely falls in the latter category of capital B books. It’s not a book you can throw in your laptop bag to read on the plane (or train). Actually, you could, but you might not have room for your laptop!

There are many books (and blogs) out there that purport to tell you how to be a Product Manager. I have discussed some of them here before and there are many reviews on sites like Amazon. The PMDR is unique among them in that it covers a very broad range of Product Management topics and it covers them in significant depth.

And fortunately, the PMDR is not just limited to the traditional Product Management functions. Haines covers all the topics that a Product Manager would even remotely have to think about or interact with–Leadership, Finance, Team Management, Research, and Career Development, just to highlight some.

In previous book reviews, I have gone through the book and summarized the main points and added some comments (observations, critiques, or questions). That’s a bit harder this time around since the PMDR is so big and I don’t think that it would add much value. What I am going to do with this one is pick out some of my favorite topics or points and provide some guidance on who it would be good for (New Product Manager (NEW), Experienced Product Manager (EPM), Big Company Product Manager (BIG), Start Up Product Manager (SUP) or everyone):

Topic	Starting Page	NEW	EPM	SUP	BIG
Stay Calm, Even When Your Hair’s on Fire	48	X	X	X	X
Documenting the Decision Process Chart	92	X	X	X	X
Basic Financial Statements	106	X			X
Competitive Positioning	150	X	X	X	X
Strategy as a Dynamic Continuum	216		X
SWOT	237	X		X
Product Strategy Review Template	345		X		X
Sorting Out Opportunities	270			X	X
So What?: The Value Proposition	277	X	X	X	X
Marketing Functional Support Plan	297	X			X
Product Performance and Monitoring	311	X	X	X	X
Eliciting Requirements	326	X
Functional Requirements	331	X
Make vs. Buy	337	X	X	X	X
Competitor Research	392		X		X
PM Role During Dev Phase	416	X
Decision Matrix for Development Changes	437	X	X	X	X
The 3 A’s of Product Launch	451	X	X	X	X
Win/Loss Audits	481				X
Recasting the Strategic Mix	502		X		X
Chapter 22 – Charting Your Career	559	X	X	X	X
Coaching Product Managers	583		X		X

There is much more to the PMDR than what I have covered above, but I think the areas I highlighted are important topics that many Product Managers struggle with. Like others who have reviewed this book (On Product Management, Cranky PM, and Product Management Zen), I think this book is a welcome edition to the library of Product Management books out there and serves to provide a broad foundation for Product Managers both within the field and beyond.

Recommendation: The PMDR is a fantastic resource for any Product Manager who wants to fill in gaps in their training/education or who wants a good reference tool for revisiting some of the areas and skills that they don’t use as much. Due to its size, it’s not portable and I wish the templates were available electronically AND free of charge for book owners, but it’s still a great book that should be in every Product Managers library.

Popularity: 3% [?]

Related posts

• Resources (1)
• Welcome to The Productologist (2)
• Why the UI is Important (4)
• How I Learned to Stop Worrying and Love Bug Scrub (3)
• Fast Release Cycles (4)

Tags: Book Review, career, career development, competitive, Launch, leadership, new product manager, process, product launch, product management, product management books, product strategy, requirement, Requirements, skills, strategy, training

The Product Management Question Corner has been on a bit of a hiatus, but we’re back with a vengeance. Today, we are talking with Jamal Ahmad, Product Manager at FrontRange Solutions, a CRM and IT service management provider. You may be familiar with their helpdesk app, HEAT or their CRM application. Jamal came to Product Management from Engineering via a host of other roles, but he’s never looked back.

Q: How do you see the role of the Product Manager changing in the next 5-10 years?

A: Let’s start with the impact of major trends.  A couple trends that we hear about every day are the recession and growth in social media. Here’s my take on how they will affect product management over the next few years.

“Do more with less” is a common theme these days, and Product Managers are not exempt.  I think you will see flatter product management organizations and fewer supporting resources available to product managers. Like it or not, we product managers have to fill gaps, and the gaps are going to get wider.  This means fewer specialists and more demand for product managers with a flexible skill set.  We have to work with executives and define strategy but also manage the tactical details.  In many organizations it has always been this way, but now the big companies are cutting back.  I think that individual product managers will end up with a wider scope of responsibilities.

The other trend is social media – online communities and forums in particular.  Sure, they’ve been around forever but user adoption still is increasing.  As online communities become more mainstream, their value as feedback mechanisms goes way up because they no longer represent just the enthusiastic fringe.  Communities give opportunities to engage with customers and hear what they have to say.  What problems do they encounter in running their business?  What questions are they asking about your product?

Q: If someone told you that they wanted to be a Product Manager, what would you tell them?

A: I think it’s a great idea.  Being a Product Manager will leverage all your abilities and expose you to many elements of running a business.  If you want my advice, find an organization where you can focus on the market, not dealing with internal bureaucracy or watching your own back.  Talk with as many people as you can when you’re interviewing and see how they like their company and their role.  Product Management isn’t for everybody, but for the right person in the right situation, it can be a dream job.

Q: What have you done or what would you consider the best way(s) for  Product Managers to improve themselves?

A: Keep yourself challenged.  Get out of your comfort zone.  If you feel most comfortable when dealing with technology, take on some marketing responsibilities to broaden your skill set.  If you’re the “big picture” type, dive into the details for a change.

In my own experience, getting an MBA was a great boost for my career.  It let me transition from an engineering role into a marketing role, and I would have had little opportunity to do that otherwise.  If you’re already in a Product Management position it’s harder to justify the cost of going back to school, and you’ll have to look for other ways to develop new skills.

Q: What Product Management tool could you not live without and why?

A: Microsoft Word (actually, any word processor would do, but that’s the one I use).  Pretty basic stuff, but the main thing is that you need a formal way to communicate market feedback and requirements.  A release tracking system is a valuable tool, but if you just track issues and features as line items, it’s hard for anyone to see the big picture.

Competitive positioning targets, market feedback, competitive analysis, strategic objectives, etc. are important to communicate to engineers.  When it comes time to explain why Issue X really matters for this product release, you can tie it back to the business objectives.  When you see emails flying around about irrelevant Issue Y, you can gently remind the engineers (and yourself) to focus on the things that were defined as priorities from the beginning.  It’s all there in the document.

Q: If you could be the Product Manager for any product, what would it be and what would be the first thing you would do?

A: That’s an easy one… Guitar Hero.  First I’d lose the lame hair metal bands of the eighties, because who really wants to pretend they’re Warrant?  (I hope Warrant doesn’t read this blog.)  Add some tracks from bands with intensely loyal fans – that might bring in some new customers.

You didn’t ask, but the second thing I’d do is get the engineers to come up with a way to put more buttons on the guitar, for a little more challenge and realism.  I know there are some technical limitations that make this difficult, but I’ve got to believe there is a way to make it happen.  Otherwise the game’s going to get old.

_________

And now for Jamal’s question for The Productologist:

Q: I brought up a couple of trends that everyone already knows about.  What trend do you see that’s outside the clear field of view, and how can I use this information to make my company’s earnings double every quarter for the next 5-10 years?

A: Oy! Raise your hand if you want a magic pill that solves all the worlds ills. Ooh, me, me, me. Unless your company’s current earnings are about $1.00 this quarter (and for some of you out there, that may be true), doubling them every quarter for 5-10 years is a very tall order.

Just to put it into perspective, if you started with $1.00 in earnings your first quarter and you doubled it every quarter thereafter, in 5 years, you would have  $524,288.00 in earnings. By the time you get to to 10 years, you’d have more than 1/2 TRILLION dollars in earnings. Not impossible, but certainly not the kind of returns that you should rely on for your next product roll out.

Now, about that trend.

In my view, location and situation awareness in applications is going to start becoming more ubiquitous. Right now, GPS is becoming much more prevalent in our everyday lives, from built-in GPS in vehicles to portable GPS units, even in cell phones. But GPS tools still rely on humans to tell the software what we want to do with the location information.

If I am in my car and driving to a destination, the GPS can tell me where I am and what route I should take to get there, but I have to tell it that I am hungry and want to find a nearby restaurant or that I am tired and would like to find a hotel for the night.

In a travel scenario, I see some AI or fuzzy logic making recommendations about the route based on where I am, what time of day it is, what day of the week, my speed and other locations that I have been recently. For instance, if the software knows that I am traveling a long distance and that it’s been 5 hours since I last stopped, it might recommend a restaurant coming up on my route (especially if I am approaching a cluster of restaurants and that food will not be available for some distance afterwards). It might also make a recommendation based on other restaurants that I have gone to or searched for recently.

GPS might not be the system that provides all of the location or situation awareness for every application, but more and more, software will need to evaluate the situation it is being used for or for the user, based on a variety of parameters. It will then adjust or make recommendations to the user that are relevant.

The user will still have options. Nobody want to end up with a solution like HAL (queue 2001 theme music) where humans are removed from the decision process entirely, but software applications will need to become more than just tools for helping humans accomplish tasks. They will actually HELP humans accomplish tasks.

What to do with this information

I don’t see making this radical jump overnight. Don’t expect something like the ship computer from Star Trek (I know, another science fiction reference…color me geeky). But Product Managers, designers, and developers should start thinking about ways that their products can use information that it already has to improve the user experience.

Think of the Microsoft Office Assistant applet (I know, it hurts me, too). This was actually an interesting example of what I am talking about, albeit, horribly implemented. If the software thought you were trying to create a certain type of document, it would ask you if that was the case and if you needed any assistance. The problem arose in the fact that it tried to help before you really needed help, which turned out to be annoying to most users.

For software to overcome the annoyance factor, it has to be able to recognize that not all patterns are equivalent. If I open a new document and type “Daar Steve,” and nothing else and then 5 minutes elapses, am I stumped on how to write a letter or did I get distracted by some other task?

If the software could be aware that you have a meeting scheduled on your calendar or that your phone is in use or that you have written MANY other documents that follow the letter format, it’s probably safe not to ask if you need help writing the letter.

Software is meant to be helpful, but it only succeeds when it doesn’t annoy us so much that we stop using it.

A bit more about Jamal:

Jamal started his career in engineering, with two degrees and four years working in that field.  He decided to pursue a role with an emphasis on marketing, so he moved to California for the MBA program at UC Berkeley.  After stints in product marketing, venture capital, and strategic marketing, Jamal made the move to Product Management.  He has worked for several companies including Symantec and Akamai, and is currently responsible for the GoldMine CRM product line at FrontRange Solutions.

Popularity: 14% [?]

Related posts

• Resources (1)
• Welcome to The Productologist (2)
• Less is More (2)
• Why the UI is Important (4)
• Clearly, You Aren’t Hearing Me (2)

Tags: big picture, CRM, Customers, Engineering, feedback, focus, issues, Marketing, MBA, priorities, process, product management, product release, requirement, strategy, travel, user experience

Some of you may have noticed that I have changed jobs recently. This move included changing from a waterfall-style development organization to an Agile one. Well, sort of. We’re getting there.

While I am not an Agile expert (at least not yet), even back in the early days of The Productologist, I was writing about Agile, albeit as an outsider looking in. And there has been no shortage of discussion about Agile and its role and effects on Product Management on many famous Product Management blogs: CrankyPM, Product Beautiful, All About Product Management (there are many more, just click on any of the blogs on my Blogroll and search their blogs for “Agile”).

To be honest, the embracing or disdain for Agile development methods feels a lot like a discussion about religion. Either you believe (or as the CrankyPM says, “The writing is on the wall“) or you don’t.  A third possibility is that you are looking for something to believe in.

My development team is moving from a loose Agile methodology to a more formalized SCRUM process. Much of our current process looks a lot like SCRUM, but it lacks some of the key components, such as an official ScrumMaster, a strict daily SCRUM meeting and other SCRUM specifics, but we’re close and with a bit of tweaking we’ll get there.

After only seeing a cursory level of Agile in action, I have to say that it is appealing from a Product Management perspective. There is a high level of visibility across the organization and it’s much less chaotic than I had anticipated. I am still not convinced that Agile methods are best for every type of software development team, and I have very few sprint/release cycles under my belt, so I am reserving judgment and commentary until later, but I am watching (and participating) with a critical eye.

If you have experiences, good and/or bad with Agile, and SCRUM in particular, please leave a comment. I’m interested in hearing others’ stories.

Popularity: 37% [?]

Related posts

• Resources (1)
• Welcome to The Productologist (2)
• Clearly, You Aren’t Hearing Me (2)
• How I Learned to Stop Worrying and Love Bug Scrub (3)
• Fast Release Cycles (4)

Tags: agile, agile development, agile methodology, agile methods, CrankyPM, process, product management, release cycles, scrum, ScrumMaster, software, software development, software development team, sprint, waterfall

In this episode of the Product Management Question Corner, I am interviewing Gene McKenna, VP of Product at UpTake, a travel search and discovery site. The next few PMQC posts will focus on Product Managers who have an entrepreneurial streak. They’re founders, CEOs, and exec team members at start ups and you’ll find that they have some interesting things to say about how they approach Product Management and how they moved from PM to bigger things.

Q: How did you become involved in Product Management and was it planned?

A: I’ve had an organic growth from developer to architect, to a professional services role and then formally into Product Management. Product Management is a broad term and varies a lot from place to place. I am more on the product development side than the product marketing side. My path was not all planned from long ago, but each step change seemed like the right decision.

Q: What are the biggest challenges that Product Managers face?

A: I’m reminded of that credit card commercial with David Spade where he keeps saying “no”. If you are a Product Manager, you better be good at that. Lots of people have great ideas, but a great product needs focus and priorities. The challenging part is to keep people from getting discouraged when they hear “no”, so I try to say “yes, in the future” which is really the right answer.

A second challenge can be getting everyone in the business on board with the same process. We embrace agile development and that sometimes poses a challenge for folks who still cling to those heavily detailed project plans and that big waterfall document.

Q: What is your greatest Product Management achievement?

A: I like to think my greatest work is yet to come, but my greatest work to date is UpTake’s industry-first, semantic travel search engine. We spent about two years building a search engine and a back end data collection and organization system whose output is the web’s largest online catalog of travel products. Already, it helps travelers make better decisions by providing them with a summary of the collective intelligence about travel products we recommend. Realizing our full vision and making it a truly great product will be the focus of the next two years.

Q: What was your worst Product Management mistake and how did you recover?

A: Failure to set expectations properly. As a Product Manager, you are always talking about what is coming, what features we will have and how great they will be. There are two ways to mess this up and I’ve done both. First, I’ve underestimated how long things will take and second, I’ve miscommunicated that a concept that might come some day is a feature coming soon. Recovery is a long process of getting it right the next ten times.

Q: What Product Management tool(s) would you consider most effective and why?

A: When people ask me what I do, I answer “I translate and I meet.” I translate from marketing-speak to engineering and back. I translate business requirements to visual and technical designs, and back. And I meet, and I meet, and I meet. For my job there are only four tools I ever really need. Outlook, Excel, google docs and a wiki. I can mock up nearly anything in Excel, with occasional bits of Photoshop pasted in. A wiki that describes what are we doing, why and when is it done, is critical. There are lots of agile development “scrum board” tools, but we’ve found using a simple Google Docs spreadsheet as the focus of our daily stand-up and means of tracking progress works great. And of course, Outlook is important because I need to have a good calendar to schedule lots of face time with pretty much everyone in the company to talk about what we are doing, when, why, what it should look like, which trade-offs can be made, etc.

Q: Where is the best place for the Product Management function in an organization and why?

A: In a corner office with an awesome view.

Organizationally, the answer will depend on the kind of company. Is it a product company or a service company with a product or set of tools? Are there many products or one? Is it a big company or small? Are there separate product marketing and product development functions or are they the same? Generally if there is a business group whose P&L is driven by a product, the Product Manager should either be the general manager of that business unit or should report to him. At a small company, that usually means reporting directly to the CEO.

Q: How has your experience as a Product Manager influenced you as a CEO or founder?

A: I think both my Product Manager role and my co-founder role have influenced each other. The business side says you don’t need the best UI, the biggest set of features or the latest technological doo-dad, what really matters is if you are achieving the business goals. The perspective that being a Product Manager brings to business is a simple, well-honed message and a focus on getting the core parts of what you are doing right.

Q: If someone told you that they wanted to transition from a Product Manager role to CEO (or founder), what would you tell them?

A: Being a Product Manager and a founder/co-founder is a great idea. Go for it. It is one of the best ways to act on the creative drive inside you. Moving from a Product Manager to a CEO means you will need to focus your creative energies on lots of things besides making the best product

—————-
Gene’s question for The Productologist:

Q: The Productologist does a great job of covering a broad array of topics of interest to Product Managers, in all their flavors. What do you see as the core mission of The Productologist? How will you know when you’ve succeeded?

A: Hmmm…while I don’t typically think of my blog as a product, it is. It has features (and bugs) and I have to serve my customers with quality or they will jump to the next Product Management blog and never look back.

When I started The Productologist back in early 2007, my goals were pretty simple: write about my experiences as a Product Manager and contribute to the dialogue about Product Manager professional development. At the time, I thought I had done a fair bit of planning. I did some research on domain names, found a decent publishing platform and a relatively unique template. I even took the time to map out a publishing calendar and wrote about a 6 posts before actually going live.

What I didn’t have was a mission statement or a roadmap for where I wanted to go. I just figured I would “play-it-by-the-ear” (thank you for that Kenyan colloquialism, Lucy Farrell) and see what happens. I thought (and still think) that is fine for The Productologist. The core mission has evolved from being just being focused on my experiences, to getting other Product Management professionals to share theirs, through comments and interviews like the Product Management Question Corner. It may change again in the future, but my plan is to let it evolve organically.

I don’t rely on it for any income (it’s more of a cost center) and it’s not my only focal point, but I do spend a good deal of time thinking about it. I think about how I can extend my reach to new readers or whether my writing is getting any better or whether my early posts stand up to the test of time. I keep thinking about what new features to add or how to make the information more accessible and useful to my readers (and potential readers). It’s subjective, but that’s how I measure its success. And so far, it’s pretty successful, at least in my mind.

If I ever find that I don’t enjoy the writing or managing the blog anymore, or that I don’t get that little tingly feeling when I push the “publish” button, that will be the signal that I’m done.

A little more about Gene:

Gene has 15 years of experience in software design and product development in direct marketing and travel. Previously Gene ran product at Acxiom Digital (formerly Digital Impact) and was responsible for the platform that sent over 5 billion personalized emails daily; during his tenure the company reached profitability for the first time. Before that he co-founded Bluedot Software, a travel company sold to Peter Ueberroth’s Ambassador’s International. Gene is a MIT-trained engineer and has a Masters from Stanford.

Popularity: 54% [?]

Related posts

• Resources (1)
• Welcome to The Productologist (2)
• Why the UI is Important (4)
• Clearly, You Aren’t Hearing Me (2)
• Hiring for Success (3)

Tags: agile, agile development, bugs, ceo, communicate, Customers, david spade, Engineering, Gene McKenna, goals, Marketing, organization system, plan, priorities, process, product management, product manager, product marketing, requirement, Requirements, roadmap, scrum, software design, start ups, trade-off

Don’t Make Me Think (2nd Edition) by Steve Krug

I have seen this book sitting on the desks or bookshelves of several designers and UI engineers that I know and it has always intrigued me. The whole concept of making the user experience so easy that it seems obvious is a big task and even with the help of books like this one, it’s still a moving target.

The book is geared toward building corporate and publisher websites, but a lot of the topics can also be applied to applications, both consumer- and enterprise-oriented software. It’s a short book (with pictures, no less), which is good. It’s laid out with some guiding principles around page layout at the beginning and then goes on to more advanced topics such as usability testing and accessibility.

Good Enough

Early on, in chapter 2, the author identifies a fundamental challenge of software development, especially web applications:

“We Don’t Make Optimal Choices. We Satisfice.”

By this, he means that we make trade-offs between making the best possible solution and one that is good enough to satisfy the user or market. Many choices that a Product Manager has to make are based on having to balance between the optimal solution and what can be done in a given time frame with the available resources. We bet that if we satisfice, it will be enough to address the short-term requirement or at least buy some time to refine the feature in a later release.

Krug later identifies some other best practices, again focused on web sites rather than web applications, but many of them apply to both, including the following gems:

1. Using common navigation and organizational conventions
   The less time users spend trying to figure out about your site/app, the happier they will be
2. Limiting the use of text-heavy instructions
   If your instructions are more than a few sentences, go back and fix your process or workflow, because that’s where the root of the problem is
3. Telling visitors about your site/application
   Don’t assume that everyone who arrives at your site/app know what it’s for and what it does
4. Creating an obvious starting point
   The home page is precious real estate, so there is going to be some crowding; make sure users know what to click

They seem like no-brainers, but both web sites and applications sometimes forget about one or more of them in the rush to create a unique experience of the user in “the next big thing.”

And Now a Word About Users

In latter part of the book, Krug dedicates some space to Usability, a subject that is near and dear to me, but which is often overlooked due to lack of time, space, money, know-how or resource availability. He starts off by debunking the myth of the “Aveage User.” The Average User is a tool frequently used to make trade offs for a website or application. Unfortunately, building software for the average user typically ends up creating mediocre software that addresses no one’s requirements.

Krug also discusses the ins-and-outss of usability testing, drilling home the message that focus group testing is NOT usability testing. It’s great that testing is included as an integral part of design. I have heard (and lived a few) horror stories about re-design projects where 100% of the effort is allocated to page layout and supporting graphics, and ZERO effort on determining if the changes are an improvement over the existing version. Oh, there’s a lot of review and feedback, but it doesn’t come from users; it comes from people within the company, most of whom are NOT the target user.

In addition to the “why,” the author spends a good deal of time outlining the “how” of testing. Beyond just providing the steps to take, Krug provides a sample script that highlights how even a bootstrapped organization can do minimal testing to improve their product.

The book closes with a chapter on how poor usability can zap user goodwill toward your software. We’ve all been there. You go to a site or web application that looks interesting, but after 10 minutes, you are so frustrated that even if the site provided all of the answers to the great questions of the universe, you wouldn’t go back. He highlights some of the most common goodwill killers:

1. Hiding information
2. Asking for unnecessary information
3. Szzle for Sizzle’s sake
4. Making users jump through hoops
5. Looking like an amateur

Recommendation: This book is one that Product Managers should read once and then give/loan/purchase for their Engineering VP/Lead/Developers. It’s easy to understand, provides both context and supporting data, and it’s short. You (or an Engineer) could read it in one night.

Popularity: 56% [?]

Related posts

• Resources (1)
• Welcome to The Productologist (2)
• Less is More (2)
• Why the UI is Important (4)
• Hiring for Success (3)

Tags: applications, Book Review, consumer, Engineering, enterprise, feature, feedback, goodwill, guiding principles, page layout, process, requirement, Requirements, Satisfice, steve krug, trade offs, trade-off, UI, Usability, usability testing, user experience, web applications, workflow

I saw a question on Linked In from a new Product Manager who is switching careers and wanted some pointers about how to make the transition smoothly. I answered the question with some suggestions. She is not a software Product Manager, as I am, so my response to her was not tied specifically to what I do as a software PM. I am re-posting a slightly modified version of my response here. Enjoy!

<original_response>

Welcome to Product Management. It’s a very challenging and rewarding field and provides a great opportunity to interact with many business functions.

I work as a software Product Manager, which is slightly different than what you are doing, but regardless, ANY Product Manager should be doing the following things to be successful:

1. Learn about your product(s).
   Even if you are already familiar with them, do whatever you can to learn more. Review documentation, go to user training, talk to any “experts” within your organization about what they know about the product.
2. Listen to stakeholders.
   Product Managers are the link between many different areas of the business. You will need to take those diverse and frequently conflicting interests into account as you make product decisions. Product Management is not a democracy, but it does require listening to, understanding, and synthesizing input from many different constituents.
3. Listen to users.
   Every product or service has a user. It may be an external customer or an internal one. The Product Manager is the proxy for that user and all users. To effectively be that proxy, you need to listen to feedback from users, both positive and constructive. Don’t let others (Sales, Support, Executives, etc) be a filter. You have to hear for yourself.
4. Understand your business.
   Beyond just making your own product successful, you need to know how your product fits into the overall corporate strategy and what the success factors for the company as whole are. Your decisions need to take those external factors into account.
5. Make decisions holistically.
   Product Management is a long-term process and you will be faced with making many decisions almost every day. As you weigh the details of each situation, focus on how that decision will affect your product over time. The shortest, easiest option may look appealing, but also consider what that decision means for the future. Also consider that each decision is not made in a vacuum. Try to see how those decisions are linked together.
6. Take risks and embrace failure.
   No one does everything right every time. Even with the best planning and analysis, things don’t turn out the way you think they will. Don’t be afraid to do something just because it might not work. If it’s not successful (or as successful as you thought it would be), figure out why and learn from it. A past manager of mine told me once that it is OK to make many mistakes, but not the same mistake more than once.

There is so much to Product Management that it is hard to sum up in short space and this is by no means an exhaustive list, but it should help make the transition a little easier. Some of the information you need to be a successful Product Manager only comes with experience and getting your hands dirty.

</original_response>

One thing I left off of my original response (because she was already doing it to some degree) is to talk to other Product Managers. Success as a PM in one organization does not guarantee success in another, but there is a lot of collective knowledge out there. Search out and use that knowledge to jump from rock to rock as you cross the river, rather than wading across on your own.

For starters, check out the other Product Management blogs I have listed in my blog roll on the right panel (look for the heading: BlogNation). They know a lot about a lot of PM topics. Just ask. They won’t bite.

Popularity: 61% [?]

Related posts

• Resources (1)
• Welcome to The Productologist (2)
• Less is More (2)
• Why the UI is Important (4)
• Clearly, You Aren’t Hearing Me (2)

Tags: business functions, conflict, corporate strategy, Customers, Documentation, external factors, feedback, process, product decisions, risk, Sales, software, stakeholder, strategy, success factors, Support

I went to visit a customer a few weeks ago as part of a commitment to myself (and my products) to get out into the field more often. My goal with them and with all of my planned visits to the field was to talk about how they use my product, what business challenges they face and what they see for the future in terms of their own growth and what they would want and need from my product. I got what I was looking for…and a whole lot more.

Unlike many of my colleagues in Product Management (at least in software Product Management and in the Silicon Valley), my educational background is not in Business, Marketing, or Engineering. Both my undergraduate and graduate work were in Psychology and Counseling Psychology. I didn’t learn a lot about financial models or the 4 P’s of Marketing or how to write Java code (though, I did learn about the Internet, primarily through it’s forebearer, Gopherspace), but I did learn the importance of listening.

One of the primary tenets of Psychology, be it clinical, research or counseling, is that you have to listen more than you talk. If you are working with experimental subjects, you have to listen and document their responses. If you are working as a Psychotherapist, you typically spend 40.5 of the 50 minutes of the “therapist hour” listening to your client. And not just listening to what they are saying, but listening for the hints and hidden messages behind what they are saying and deciphering their context and meaning, which is the key to successful talk therapy.

As a result, listening is a skill that was hammered into me repeatedly for 6 years and has come to be a valuable tool for me as a Product Manager. When talking with customers, prospects, Engineers, Salespeople, or the Executive team, I listen first. I make sure that I understand not only what is being said, but why it is being said, the context and whether there is or might be any sub-context (which is really just another way to say “reading-between-the-lines”). Once you start listening, you’ll realize that the person or people talking are giving you much more information than you originally thought.

Which brings me back to my original point about the customer meetings. As I mentioned earlier, I was just looking to get some very high-level information that I could normalize with all of the customers that I was planning to meet with. I had never met with this customer before, but had reviewed some of their past and current support tickets to get a cursory understanding of some of the issues that they faced. I had also talked with members of the Support team to get their view of what type of customer they were and the relationship that they had with our company.

Based on the preliminary data I had collected, I was prepared for a somewhat painful meeting with the customer. I didn’t think they were a very good fit with the characteristics of our “ideal” customer and the features they were asking for and the issues they brought up with Support were considered by me and others to be edge cases.

The original plan was for me and one of our founders and the VP of Engineering to visit this customer, but due to some last-minute scheduling conflicts, it ended up being just me. I thought about changing the meeting, but it had been hard to coordinate in the first place, so I decided to see it through. When I got there, however, and started talking with the team, my perceptions about them started to change.

First, after about 30 minutes, I had a better understanding of their business, which was considerably different than what I thought it was before the meeting. Having that understanding made many of their issues seem less like edge cases and put them more in line with some of the challenges that other customers might have. That gave me some ideas about how to tackle some of the challenges in the near-term and also what I would need to do in the future to address areas which I thought were well outside of our sweet spot, but now see as being more integral.

Another thing that happened was that while the meeting initially had a somewhat adversarial tone to it (we started the meeting by getting some of their issues out on the table, even though I had tried to steer the conversation away from that area), as I let them talk and asked only a few questions to spur the discussion, they started to discuss more about their vision and how they saw my product fitting in to that vision.

What I found was that they had many ideas on how to use my product that I hadn’t considered. They wanted to use my product in a way that it wasn’t currently being used, but that made a lot of sense when they spelled it out. It was an “A-ha!” moment for me.

Finally, through the discussion, I got insights into how another organization operates. What their processes are. How they build their product. What they spend their time and money on to increase success. What type of people they have on staff and in what roles.

It’s easy to become insulated in one’s own organization and I sometimes find that I limit myself to the same patterns of interaction and process that I have become accustomed to. Hearing the stories of this customer (and others) helps me to lift my head up from looking at my feet while I walk and take a fresh view of the world.

Plenty of Product Management texts and resources recommend talking to your customers in order to build better products, but there’s also a good possibility that just listening to customers can help build better products and better Product Managers.

Popularity: 53% [?]

Related posts

• About (0)
• Welcome to The Productologist (2)
• Less is More (2)
• Clearly, You Aren’t Hearing Me (2)
• Hiring for Success (3)

Tags: challenges, customer, Engineering, executive team, feature, Marketing, process, Prospects, software product management

It’s been a little over a month since I started using this new note-taking method and I wanted to provide some details on how it’s going for me. To be honest, it hasn’t been as easy to switch to this note-taking style as I thought it would be. I have struggled on a few fronts–

Paper

The Cornell Note-Taking Method utilizes a special paper layout that divides the page into discrete sections. Each of the sections has a specific purpose. In my original post on this topic, I provided some links to Cornell Note-Taking Method page generators, but I found that to be a bit wasteful. I didn’t see the need to use a whole page of paper (even recycled paper) for every meeting so I decided to use my existing notebook (one of those bound composition notebooks with the black and white cover that you see in the school supplies section at the store) and just create the Cornell Note-Taking Method layout manually using my pen.

This has worked fine, except that I still end up wasting a lot of paper because I don’t end up taking a full page of notes every time. I’ve even had the occasion to cross out the original meeting title and write a new one because I didn’t write anything down.

Space

Using the Cornell Note-Taking Method, I sometimes find that I feel cramped when I write ideas down. Because the note-taking area is smaller than without the Cornell Note-Taking Method, I find myself running out of room on the page faster. I also find that it seems harder to write down a complex thought with less space. It’s nice to have the other areas to write additional or clarifying notes in, but sometimes it ends up being wasted space if I don’t use it.

Reverting

Another challenge that I have had is that it’s quite easy for me to forget to use the Cornell Note-Taking Method and go back to my old style of note-taking. I usually notice this about 1/4 to 1/2 of the way down the page. I don’t know if I just need more time or if breaking the habit of my old style is just going to be a challenge I will face for a long time.

Time

Part of the Cornell Note-Taking Method is going back over the notes that you have written and re-stating or summarizing them to better ingrain them in your memory. I have found that due to my schedule (lots of scheduled and impromptu meetings and phone calls), I don’t have or take the time to go back and do the secondary note-taking steps. I do give my notes a cursory once-over to look for action items or things I need to follow up on, but as for summarizing all of the days notes, that just doesn’t happen.

Next Steps

I’m going to keep trying the Cornell Note-Taking Method for a while longer to see if I can get over the hump of my past note-taking habit and see if there is a bump in usefulness/productivity for me, but I thought it would be easier to switch to using the Cornell Note-Taking Method and the benefits would be more pronounced.

Popularity: 87% [?]

Related posts

• About (0)
• Resources (1)
• Welcome to The Productologist (2)
• Where Does All the Time Go? (1)
• Why the UI is Important (4)

Tags: breaking the habit, cornell method, cornell note taking method, diagrams, Documentation, meeting minutes, meetings, note taker, note taking, process, productivity, staff meeting, tips and tricks

The Inmates are Running the Asylum by Alan Cooper

I have been meaning to read this seminal text on application development and usability for some time (read: years), but somehow it always ended up on my reading list just below something else. After seeing some others reference the book and discuss conference talks where the author expanded on his theorems, I decided to bump The Inmates are Running the Asylum to the top of the list. After finishing it up, I was surprised, to say the least.

Cooper spends a good portion of the book providing examples of what’s wrong with software development and user experience in particular, which is initially helpful, but gets a bit tiresome. Maybe it’s just my perspective as a Product Manager, but I know that software design and development is a dynamic process. Even when you improve the product dramatically (new features, ease of use, performance or cost), there are still more ways to make it better. I’ve never heard ANYONE say, “Ok, we’re finished. There’s nothing more we can do to improve this.”

Software is constantly evolving. There may come a time when development of a particular application is stopped for business reasons or the need for the application disappears (anyone remember XTree?), but there are always improvements to be made. Case-in-point, the application that I use to write the drafts for my posts is called Notepad ++. It’s your basic text edior with some nice add-on features, such as macros, word completion, and word count. It has a bunch of other features that are more geared toward folks who use it to code, but it does what I need it to and it then some.

You’d think that a text editor wouldn’t have a lot of room for growth at this point. Text editing programs have been around for such a long time and have been used for so many things that it’s hard to believe that there are many things still to be added to the feature set. But, just today, I was prompted by the application to download a recent update.

After upgrading, I went to take a look at what I was getting with the new build. Included in this release are at least 24 bug fixes (that’s how many were listed in the readme, but being a Product Manager, I know there were probably more that weren’t included in the readme) and six new features, which incidentally were more about the user experience than the actual functionality of the software.

Which brings me back to The Inmates are Running the Asylum. The main lesson that I got out of the book was this–

• The people who code the software are not the people who use the software, so they should not be the one’s who design the software.

It’s easy to create a list of features that a software package should have, but it’s an entirely different thing to make those features accessible and useful to the intended user. Cooper repeatedly claims that software engineers are fantastic at fulfilling the requirements of the first half of that sentence, but usually don’t have a clue on how to do the latter (or even stop to consider that there is a second half of that sentence).

I’ve worked with my fair share of software engineers and that assumption is generally true, though I have worked with some very talented developers who were good at coding and at understanding the needs of users who may not be engineers. The challenge that Cooper identifies is that users and programmers fall into two separate and mutually exclusive groups.

Users want the software to do most of the work for them. The best kind of software is the kind that doesn’t get in the way of doing what the user wants to do. They become frustrated when the limitations of the software are exposed to them. Think of the scene in Office Space where the laser printer displays the PC Load Letter error. To the software engineer who created the application inside the printer, this probably had some connection to what was happening or what the user should do, but to the user it is as cryptic as reading some alien language. The user has no idea what the problem is or what to do about it.

On the other hand, programmers revel in the challenge of getting past the problem, as witnessed by this passage–

If you aren’t utterly on top of your game, computers will leave you whimpering in the dust. It is easy to picture the exhausted programmer chugging Coca-Cola, grinning and saying “Yeah the fetch logic caused the crash, but only when the main heap grew beyond 64K, otherwise the cache wasn’t activated. Almost couldn’t find it!”

This fundamental difference in how users and programmers interact with the software exemplifies Cooper’s point that developers are not the right people to handle interaction design (which he differentiates from interface design). Cooper spends chapters 7 and 8 discussing the differences between programmers and users in detail.While most of the book centers around development, there was a passage that caught my eye, since it specifically called out Product Managers. It is in the chapter entitled, Wasting Money. Cooper calls all of us out on to the carpet with this statement:

“I’ve seen Product Managers sacrifice not only design, but testing, function, features, integration, documentation and reality. Most Product Managers that I have worked with would rather ship a failure on time than risk going late.“

Ouch, although, there is some truth there. Part of Product Management is balancing the must-have with the nice-to-have. In big companies, it may be more acceptable to slip a ship date, but in the start-up world, missing a product release deadline can mean missed revenue and even layoffs or closing the business. I’m not trying to be dramatic, but there are real differences on what types of choices a Product Manager has to make that are based on the size of their company.In Chapter 9, Cooper introduces what is likely the most novel concept in the book–Personas. He provides very concrete examples of what a persona is, what it’s for and why every software project needs them. When The Inmates are Running the Asylum was originally published, personas were not a common tool used in software development, but reading the text today, many more development processes include Personas at some level.

There is some dissension in both the Product Management and Programming communities about the usage and benefit of Personas. Cooper recommends creating full Personas (a name (which Cooper says is essential; without one, it’s useless!), pictures, lots of details about the person that may be unrelated to the software), but for me, that’s a bit of overkill.

When I create a Persona, it just has to describe what is relevant to the usage of my products. By making the Persona so specific, it loses some of the value of being a Persona and just becomes another user. I don’t need the Persona to “come alive” like a character in a movie. What I do need is for the Persona to provide insight into the needs of a type of user that helps me, the engineering team, the QA team and anyone else involved in creating the user experience what the archetypal user needs to be successful.

In chapter 10, Cooper makes the case that software should anticipate the needs of users and be “polite”. He lists a number of characteristics which he identifies makes software polite. Here are a few examples:

• Polite software has common sense
• Polite software is perceptive
• Polite software is deferential
• Polite software gives instant gratification
• Polite software is trustworthy

All admirable qualities for software (and people, too), to be sure, but hard to find in either one.

Cooper finds his way to poke fun at Product Managers again in chapter 12–

It is easy to see why product managers can mistake industrial design for interaction design. Just because the buttons are easy to find and pres doesn’t mean that the user will know which button is the right one to press.

His point is that it is easy to make something pretty to look at, but it’s a whole different thing to make a product easy to understand and use, which sums up much of what Cooper is trying to say throughout the book. It takes heavy lifting to make a product that has both the features and functions that users need AND a user experience that makes those features accessible.

Recommendation: Although the examples and concepts seem a bit dated, and I don’t agree with everything he says, and he takes the occasional potshot at Product Managers, the need to examine the user experience and improve upon it never goes out of style. The Inmates are Running the Asylum is a book that EVERY software Product Manager should read and review on a regular basis if they want to build great products.

Popularity: 78% [?]

Related posts

• Resources (1)
• Welcome to The Productologist (2)
• Why the UI is Important (4)
• Hiring for Success (3)
• Using Human Factors in Design (2)

Tags: alan cooper, Design, Engineering, feature set, Interface, new features, Personas, process, requirement, software design, software development, Usability, user experience, users

I’ve been listening to career-related podcasts on my commute to and from work lately and one of my favorites is Manager Tools. They are basically two management consultants (Mark Horstman and Michael Auzenne) who talk about tips and tricks to being a good manager, which if you have supervised others at work, you know is not as easy as it seems.

One of the “casts” (that’s how they refer to the individual podcasts) dealt with running meetings, a topic that I have discussed previously. They highlighted the fact that as the meeting leader, you should not be trying to manage the documentation of the meeting because your role is to facilitate and if you are struggling to write things down, you aren’t focused on moving the discussion forward. They say you need a dedicated note-taker to transcribe the discussion.

That sounds great when you are having a daily, weekly or monthly staff meeting and all of the participants in the meeting are your direct reports and you can easily delegate the responsibilities of note-taker to someone on your team, but in my world, the majority of folks that I have meetings with (when I am the meeting organizer) are either peers or senior to me. I can’t just say, “You there, VP of Engineering. Please take notes during this discussion and distribute them to everyone present by the end of the day.” Well, I could, but it’s not likely that I would leading many more meetings (or anything else) at that company soon after.

So, it’s up to me, which brings us back to the podcast about meetings. Another recommendation that the folks at Manager Tools make is that the note-taker use something called the Cornell Method of Note-Taking. This piqued my interest because for as long an I can remember, I’ve never used a “method” for taking notes, either in school or in a business setting, although I’ve most likely been using some form of outline notes, since I tend to try to organize the notes into a hierarchy as I am writing them.

During the podcast, Mark and Michael described the Cornell Method at a high-level and explained that there is a process for how you write the notes and what you do with them afterwards. The process involves dividing the note page into discrete sections that each have a unique function. There’s a notes, cues and summary section which are broken out on the page roughly 60/20/20.

The details of the discussion are written in the notes section and are distinct items that you hear in meeting. The folks at Manager Tools identify these as the who-what-when elements. Whenever you hear one of those things in a meeting, write it down in the notes section.The cues area is for supplemental notes that tie details together, diagrams or questions for follow up. In the Cornell Method, which was originally designed for college students, the cues are to be written after the lecture or chapter is completed and you have finished writing in the notes section, but for business notes, it makes more sense to use this area for alternative content such as organization charts, workflow diagrams or mindmaps.

Lastly the summary section is for capturing next steps, action items or surprise, surprise–a summary.

The benefit of this whole process is to help with the absorption of the information. In an educational setting, it helps students better understand and remember the information that they hear in class and read in their texts. The steps of capturing, reviewing and re-writing the notes in various ways helps to ingrain the content in their memory and gives them ways to assimilate the information together into their body of knowledge.

For business users, it provides a mechanism to capture different types of information in an organized way, even if the information is not presented in an organized fashion. The challenge of many meetings, especially at software companies and at startups in particular, is that the discussions in meetings are non-linear. They don’t move from topic to topic gracefully. They are more like a teenager trying to learn how to drive a car with a manual transmission in a parking lot. They lurch and stop and change direction and sometimes just go around in a circle. The Cornell Method could be a better way to capture all of the information, digest it, and make it easier to distribute to others.

Now, after having gone through all of that, I have a confession. I have NEVER used the Cornell Method. But, I am anxious to try it out. I have been doing some research on it and there are some online wizards that can help you make the templates for Microsoft Word or PDF. I plan to just manually divide my current notebook pages to save some trees, but I know that others prefer to have task-specific tools and I don’t begrudge them that choice.

If you have experience using the Cornell Note-Taking Method (or other similar methods) in either an educational or business environment, I’d love to hear what you like/dislike about it. I’m excited to try it out for myself.

(Note page layout image: University of Maine at Fort Kent)

Popularity: 82% [?]

Related posts

• Welcome to The Productologist (2)
• Where Does All the Time Go? (1)
• Why the UI is Important (4)
• How I Learned to Stop Worrying and Love Bug Scrub (3)
• Fast Release Cycles (4)

Tags: cornell method, diagrams, Documentation, meeting minutes, meetings, note taker, note taking, process, staff meeting, tips and tricks