I’m sure this isn’t a surprise—most non-product managers have a hard time articulating what product management does, much less a way of evaluating it. In their defense, it’s often easier to see signs of success (or failure) in other parts of the organization:

Engineering/project management— “Are we making dates?” “Are the launches high quality with few bugs?”
Marketing— “Are we increasing leads/customers/traffic?”
Sales— “Is revenue increasing?” “Are we closing deals?”
Customer Service— “Are we handling calls/emails/chats?” “Are wait/response times decreasing etc?”

We all have a stake in helping organizations develop evaluation methods for our discipline and it wouldn’t hurt if they were easy to “see”—the more tangible the better.

So using Steve’s framework as a jumping-off point, what should a CEO “see” if a product manager is succeeding?

Technology Expertise

From Product Management Expertise:
“Technology expertise is about how the product works. From their daily interactions, product managers pick up a deep understanding of product and technical capabilities; they achieve this by playing with the product, by discussing it with customers and developers, by reading and reading and reading. For a technology expert, the product almost becomes their personal hobby. They think of themselves as product experts.”

In my experience, a product manager’s relationship with the development team can hinge on the product manager understanding how the product is/will be built. If a product manager has a strong technical understanding, they are less likely to make “painful” requests and take the team down rabbit holes.

What the CEO “sees”:
—Positive feedback from team leads on product manager performance
—Smoother, on-time release cycles
—Engaged (not grumpy) engineers

Market Expertise

“Market expertise is a focus on geographic or vertical markets, either by country or by industry. They know how business is done in that market. They know the major players, and the jargon or colloquialisms of the market. Market experts define themselves by the market they serve: “I’m a banker” or “I support BRIC.”

A product manager’s grasp of the dynamics that make up a market (customers, suppliers, partners, logistics, purchase cycles) tends to manifest itself in the product choices they make which, unfortunately, aren’t always the obvious optics we’re hoping for. One way for a CEO to evaluate market expertise is to have the product manager explain product choices in the context of the overall market. Having the product manager break down a competitor’s product/feature set and tie them back to market specifics is also a great way to measure a product manager’s expertise.

What the CEO “sees”:
- Product choices mapped to market knowledge
- Competitive breakdown

Domain Expertise

“Domain expertise is about the discipline your product supports, such as security, fraud detection, or education. Domain experts know (and often define) the standards for the discipline and can explain the latest thinking in that area. They understand the problems that your product endeavors to solve, regardless of the market or industry. And for a domain expert, your product is merely one way of addressing the problems of their specialty. Domain experts define themselves not by the product but by their topic area.”

This can be tricky to differentiate between market expertise so I distilled it down to ”Is the product manager a thought leader?” From this vantage point, evaluating expertise has two components—internal activities and external activities. Internally, much like demonstrating market expertise, CEOs need to evaluate a product manager’s ability to evangelize within the organization. Externally, I would expect to see a product manager as a thought leader at conferences and meetups, on social media, and writing blog posts and white papers.

What the CEO “sees”:
- product manager leading internal discussions furthering the organization’s collective knowledge
- Public activity within the industry and social platforms

Business Expertise

“Business expertise is where your traditional business leader or MBA graduate brings strength. These experts know the mechanics of business and can apply that knowledge to your product. A business-oriented expert knows how to use research to determine product feasibility, can determine how the product generates profit with lots of financial analysis to back it up. Ideally these business skills need to be combined with one of the other skills or provided as a support role for the other areas of expertise.”

Product managers without an MBA or a business background often struggle with incorporating this type of thinking into their strategy. Product managers who can lead financial reviews of their products performance (and the competitions), understand pricing strategies (ecommerce product pricing, subscriptions vs one-time, freemium vs premium) and speak to a product’s profitability are exhibiting this expertise.

What the CEO “sees”:
- Product managers leading financial reviews
- Deep understanding of product pricing strategies
- Speaks the language of P&L

Next steps

The easier we make it for managers to evaluate our performance the clearer our value-add will be to the organization. In the end, product managers will always be judged on product outcomes but it’s our duty to help our bosses see our expertise in practice everyday.

About the author

Anton Reut started building ecommerce and media sites in the mid-90s (yikes!) including founding eWork.com, launching Gifts.com and most recently as VP, Product & Mobile at US Auto Parts. When he isn’t writing about product management, he is consulting for startups, large corporations and everything in between in Los Angeles. Learn more at
http://www.linkedin.com/in/antonreut

What should I know about moving from a developer role to product management?

First, congratulations! You’re about to see the world in a whole new way.

The great thing about product management is you work across all parts of the organization—development, marketing, sales, services, support, finance, and the executive team.

The secret to success is to know the potential customers for your product better than anyone else. Your job, particularly with development, is to explain the personas and their problems. The who and the what. You’ll want to be very cautious of telling your team how to solve the problems. Your challenge will be your technical background will lead you to describe exactly how you think the problem should be solved.

And don’t forget that your “product” is more than software. The product is what people buy, so they probably need services and support as well as software.

The ideal scenario is to set up a design group—yourself, a user experience person, a developer—to review your market requirements and determine the best approach for solving those problems.

In the short term, the way you earn credibility with your team is market expertise. Your development peers will likely attempt to pull you into design and specifications but that’s the life you left behind. Longer term, market expertise will help you communicate with the rest of the organization. You’ll be able to tell stories of how real customers use the product to solve real-world problems.

You already have strong technical expertise. Now you’ll want to expand your skills in market, domain, and business. For more on the four types of expertise, read my (free) ebook: Product Management Expertise.

Pictures courtesy of pictofigo.

You will never find time for anything. If you want time, you must make it.— Charles Bruxton.

Charles Buxton was an English brewer, philanthropist, writer and Member of Parliament. Learn more…

I work with product management teams around the world and they all have one thing in common: they have too much to do, and not enough time.

We say “yes” to too many things. Steve Jobs said, “It’s only by saying ‘no’ that you can concentrate on the things that are really important.” There are plenty of good ideas—you have to choose those that are critical to your product. You have to say “no” to the many, many things that are compelling but not vital.

If you want time, you must make it.

As they say, if you don’t control your calendar, someone else will. Block time on your calendar for product management. Pick one day a week to focus on the vital aspects of your job.

In my first product management job, I was living in DC and my developers were in Los Angeles. I flew to LA once a month and stayed with them for a week. They shared the work they’d completed in the last month (what we now call a “demo”) and I caught them up on what I’d been doing.  The rest of the month I’d work with teams around the company and allocate time for product management.

Nowadays I’m doing the same with my consulting clients. I spend a few days with them once a month, leave them action items to do while I’m gone, and checkpoint periodically through the month. (Sound interesting? Learn more about my consulting offerings.)

Can you do the same? Can you allocate time each week or each month for intense focus on product management?

If all you do is respond to the needs of others, you’ll get really good at doing work for others. But who is going to do your work? Who will do product management?

If you want time, you must make it.

It is better to train ten people than to do the work of ten people. But it is harder.—Dwight Lyman Moody

The typical product manager’s inbox is a mess. Maybe yours is too. But when you’re working from your inbox, you’re working on someone else’s priorities, not your own. The same is true for your calendar. Before you know it, your calendar is filled with appointments that seem really urgent—but are they really important? And are they furthering your agenda or someone else’s? Others are determining your priorities, as you go from one urgent meeting to another.

Attending meetings, responding to emails, helping individuals one at a time can’t be maintained, at least not for long. We need to find a better way to empower others.

Instead of answering questions, explain the vision. Instead of providing detail, provide context. Tell stories about personas and their problems so development and marketing teams can use their judgment.

After all, what is the goal of product management? We want developers to build the right product and we want sales people to know how to sell it.

We want to build the product right and also build the right product.

In a small company, the executive team manages the product and defines product direction, perhaps with ideas from developers and sales people. But as the company grows larger and the product set more complex, the company leaders are too busy managing the day-to-day of the company to focus on a single product. That’s when you need product managers and product marketing managers.

Ideally, product management is making decisions that the leadership would make if only they had the time to do so.

Product management professionals serve as the leadership’s eyes and ears, at the product level. Looking at the business aspects of the individual products and spending time in the market to help make product decisions with the right priorities.

Share market information with the company

Every development methodology calls for someone to represent the market to the product team. Developers need to understand the people who use the product and the problems they need to solve. There are two ways to help this effort: either work side-by-side with the product team and answer questions as they arise, or help the team understand the context of the problem so they can answer their own questions using their judgment.

That’s the power of product management artifacts: personas, stories about problems, and descriptions of workflows. These help the team understand what they’re trying to solve.

General George Patton said, “Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity.” Yet many leadership teams and many product management teams insist on telling the developers both what to do and how to do it. And after a while, the developers learn not to use their judgment and insights and innovations. They say, “Just tell me exactly what you want and I’ll do it.” But that increases the amount of work dramatically.

Think of the remote control for your television. For some people, choosing inputs and channels is all rather like magic. One solution is to document everything: “to watch a movie, switch to HDMI-1 by pressing the INPUT button up to three times until you see ‘DVD’ in the upper-right corner of the screen” and so on. Instead, you’ll have better luck if you can explain how the input button toggles between the different input sources—cable, internet, Blu-ray player, game device, and so on. Once your family understands what devices are connected where, they can use their common sense to operate the remote control.

The same is true for developers. This is the essence of agile.

And sales people. You could give them a long list of answers to memorize and a Q&A document to reference, or you can help them understand who buys the product, what issues they’re facing, and the philosophy of how you solve it.

Help them understand the why, not the what.

Help them help themselves

Telling stories about the work your customers do, explaining personas and their problems—these help the development, marketing, and sales teams learn to help themselves.

Think of a legal document, like a will or an employment contract or an employee handbook. These documents attempt to describe in laborious detail every aspect of the problem to be solved. How much easier would it be if these documents explained the ideas rather than the details?

Nordstrom Rules: Rule #1. Use your good judgment in all situations. There will be no additional rules.

That’s it. The Nordstrom Employee Handbook. On a single index card.

This sort of “use your judgment” idea affects the kind of people you hire. And is impacted by the people you have already hired. If you’ve hired mindless drones, if you think product creation is like factory work, you can’t expect them to use their judgment. If you hire people who know nothing about your industry and domain, you’ll likely be disappointed if you expect them to answer their own questions. So you need to either hire for expertise or supplement the people you have hired with expertise.

I believe that people can learn. I believe that people want to know more about their products and their customers and their companies. You can help your colleagues learn to use their judgment by sharing your product vision, the kinds of customers who need your products, the problems that those customers are trying to solve, and the tools you’re using to connect with those customers.

What’s next?

Look for ways to explain and teach and empower those who need product and market information. Instead of responding to each request one at a time, ensure the information is available online or in ready-to-use tools.

I have a personal rule: if one person asks, then most people don’t know. So whenever I get a request from a colleague or a customer, I write a comprehensive answer and then publish it. That’s the reason for an internal wiki or external blog; you can respond to inquiries, in detail, and never answer the question again. Before you know it, you have a collection of documents and articles and posts that answer almost every question.

Use the artifacts of product management—personas, stories, roadmaps, and plans—to give people the information they need when they need it. Show them where it is so they can answer their own questions and use their own judgment.

Anyone who acquires deep expertise does so at the expense of breadth.—Andrew Hargadon.

Professor Hargadon is the author of How Breakthroughs Happen: The Surprising Truth About How Companies Innovate, which was published by Harvard Business School Press in 2003. Learn more…

We throw the word “expert” around somewhat casually but you can’t be an expert in everything. The more you know about your domain or industry, the less you can know about others. It’s like the brain is a candy machine that can only hold so many M&Ms. And when you add new memories, the old ones get pushed to the back and become stale.

Product managers and product marketing managers should take a moment to inventory their expertise. Is it the domain, the product, the market? And then set a plan to keep that area of expertise current. “I talked to a guy last week” is more persuasive than a story from last decade, don’t you think?

Product leaders need to staff the right level of expertise in their teams. You may have a lot of product owners who are strong on the product and technology but how’s their market knowledge? Maybe you need to supplement your group with some product marketing managers.

You can have breadth or depth. Staff accordingly.

Want to learn more? Read my free ebook, Product Management Expertise.

How does a new product manager or product owner get up to speed in your organization?

Imagine you’re a new product manager. What company-specific knowledge do you need? Is there a standard template for positioning or for a business case? Where is it? Once you fill it out, how do you share it and store it? And with whom?

What you need is a product management playbook, a collection of the templates and tools tailored for your organization.

You’ll want to create company-specific versions of all your planning templates including “institutional knowledge” like where templates can be found and stored online, the key contacts in each business area, the standard distribution techniques such as distribution lists and discussion forums.

Here’s a list of fewer than 10:

• Portfolio roadmap
• Buyer profiles
• Product profile
• Financial plan
• Product backlog
• Marketing backlog
• Launch plan
• Profitability retrospective

Plus

• Distribution lists
• Discussion forums
• Online locations for storing development, marketing, and sales information
• Key people you need to know with contact info

The trick is to make sure the procedures and methods are grounded in reality. Some teams create “ideal” processes that don’t work in real life. They tend to favor cross-functional teams from all areas of the organization rather than just a few key decision makers. They prefer perfect information—and who doesn’t? But getting precise information isn’t always possible.

What would you put in your product management playbook?

The primary purpose of a persona is so that you won’t design for yourself, or for your boss, or that loud, annoying client.—Alan Cooper.

Alan Cooper is an American software designer and programmer. Widely recognized as the “Father of Visual Basic,” Cooper is also known for his books including The Inmates are Running the Asylum. Learn more…

I hear it from developers, product managers, product marketers, executives. When writing anything from a press release to a programming module, most folks write for their parents. Or their friends. Or themselves.

That’s the value of personas. They remind you that you are not the target customer, nor are your colleagues, your leaders, or your families.

My first encounter with the term persona was in Cooper’s The Inmates Are Running the Asylum yet I’d been using the concept for years without this handy label. “Actors” is a similar concept from UML; so is “audience profiles” from the world of marketing.

But it seems the persona concept is under attack from some quarters.

I’ve heard “personas don’t work for us” and “we don’t use personas; we write for ourselves.”

Invariably when I pursue these concerns, I learn their personas are fictional biographies of theoretical people; they are not based on real people. These “bad” personas are not written based on personal experience with buyers and users of their products. These personas were written by marketing people working with HR and sales people. They’re out of sync with real people with real problems. One marketing team created about 40 personas based on the job descriptions in their HR systems… ignoring that technical team members working at a vendor are materially different from those in internal IT.

When writing, you’re goal is to communicate. Writing doesn’t have to be simple as long as it’s clear to the reader. If your reader knows XML, you can write about classes and inheritance. If not, not. Know who you’re writing for before you start writing.

Do you have personas for your products?

Need help getting personas off the ground in your organization? Check out my Pragmatic Marketing implementation assistance.

How do you know whether a product idea is going to succeed if you build it and take it to market?  If you’ve ever been part of a startup, or if your organization has launched a new line of products, you know how precarious the effort can be.

That is the challenge that led to the creation of the ‘product opportunity evaluation matrix’ or POEM framework.

Read more here.

Be sincere, be brief, be seated.—Franklin D. Roosevelt.

Franklin Delano Roosevelt, also known by his initials, FDR, was the 32nd President of the United States and a central figure in world events during the mid-20th century. Learn more…

The reality of today’s workplace is that almost everyone needs strong speaking skills. There are loads of resources for doing better presentations. Here are a few of my favorite tips:

• Memorize your first 30 seconds. You never get a second chance to make a first impression.
• Don’t tell jokes; tell stories. (Particularly if you’re terrible at jokes.)
• Use graphics and photos more than bullets and text. This is especially helpful when you want to change up what you’re going to say because you’re not stuck reading the text. You can say almost anything you want with a graphic.
• Stick to the point. For every slide, ask yourself: does the audience really need to know this?
• Never, ever, ever run long. How many times has a meeting or conference been derailed when one of the speakers took more than the allotted time?

Whenever I speak at a conference, I ask the organizer when he or she wants me to be finished. No matter when I start, I always try to end on time. I remember the time I was given 45 minutes. The organizer knew I had 20 slides so she was really panicked when I spent 20 minutes on my first slide. And then she was astounded when I finished 3 minutes early. I guess I’ve learned to expand and contract based on the schedule. (In the world of development, I’ve always preferred shipping on time rather than feature complete).

Check out Garr Reynold’s great rant against “Slideuments” plus many many tips on speaking in this article at LifeHacker.

Need a speaker at your next event? Check out my speaking page.

A desk is a dangerous place from which to watch the world.—John le Carré.

David John Moore Cornwell, pen name John le Carré, is a British author of espionage novels. During the 1950s and the 1960s, Cornwell worked for the British intelligence services MI5 and MI6, when he began writing novels under a pen name. Wikipedia

I’ve been reviewing job descriptions for product managers and product owners and something’s missing. The responsibilities include “representing the customer” and “being expert on the market.” Then they list a bunch of meetings and artifacts and office work.

How can you know the market if you’re not in the market?

Another client is developing a program for on-going customer interaction, including a “customer adoption” program for the executives, outbound calling trees for top-tier customers, and online forums for all customers. And of course, frequent visits to clients by product managers and product owners.

Haven’t you found clients to be the best source of positive information about your product? After all, your company colleagues can only see the problems and flaws as they strive to improve (which is good). But customers will tell you stories about how your product helps them do their jobs, and improves their value to the company and to their clients.

Need some good news? Call a client today.

Need help? Check out my Pragmatic Marketing implementation assistance.