A Structure for Product Management Knowledge and Skills Acquisition

In the last two Certified Scrum Product Owner courses that I taught, people have asked, “What’s next?” A beautiful question indeed. My answer included a path to Certified Scrum Professional that Carlton Nettleton and I have developed, a series of advanced courses that Applied Frameworks offers, and the Scaled Agile Product Management course that we offer.

Let’s go much deeper in how people in the role of Product Owner and people in the software Product Management profession should think about levels of training and knowledge acquisition. I thank Luke Hohmann for the following structure that he attributes to Meiler Page-Jones.

1.     Innocent. You have not been exposed to a given area of knowledge and are unaware of its existence. In other words, you have absolutely no plans associated with the topic in your cognitive library, your preexisting set of solutions and experiences.

2.     Aware. You have been exposed to an area of knowledge (such as a new technique to organize your product backlog), perhaps by reading an article, and can see its relevance, but have not yet applied or used it. Your cognitive library may have one or two plans regarding the body of knowledge. These plans are rudimentary at best. You are still unable to use it for any useful purpose.

3.     Apprentice. You have had some formal training in the structures, processes, and outcomes associated with a topic, perhaps through a two or three day workshop. You have begun the task of creating and storing plans in your cognitive library. At this stage of learning, structures tend to be viewed as absolute, not to be violated. You can produce simple outcomes for well-defined problems, but require the assistance of more expert individuals to solve ill-defined or new problems.

4.     Practitioner. You are able to accomplish moderately difficult tasks without assistance. Your cognitive library is fairly well developed, but you must still rely on experts to accomplish very complex tasks.

5.     Journeyman. You regularly use the body of knowledge in your work, and begin to question and/or modify structures to suit your needs. At this stage your cognitive library is reasonably large. You begin to apply existing plans in novel ways. Individuals at levels 2 through 4 seek your guidance.

6.     Master. You have mastered the body of knowledge, and can effectively apply it in many different situations. Your cognitive library is quite well developed. It contains plans enabling you to solve well-known problems quickly and easily. You are adept at applying plans in novel ways. You can easily adapt or invent appropriate structures to aid in problem solving.

7.     Expert. With substantial expertise, you move beyond the master stage by extending the collective body of knowledge through lectures, writing articles and/or books, or applying the knowledge in new problem domains. The difference between a master and an expert is subtle, but important. Both possess extensive cognitive libraries, but the expert works at externalizing their library in a form suitable for use by others.

All of us at Applied Frameworks focus on how to assist you on your journey to the Expert level of product management in each of the frameworks you need to succeed and excel at your job.

We will help you assess where you are now and your path to the next level.  We absolutely value your input and specific feedback as we work through our minimum viable product to create a service that delivers value.

Don’t learn everything at once

I've also learned that only through focus can you do world-class things, no matter how capable you are.—Bill Gates, Microsoft

In my first job out of college, I was a programmer working “week on/week off” which was really cool. We’d work 12 hours a day for 6 days, Thursday through Wednesday (with Sunday off), and then take a week off. “On” days were long (!) but we found two teams working in shifts reduced mistakes that were more likely with three teams. And of course, “week on/week off” was a great recruiting tool!

48781.jpg

On my “off” weeks, my pal Jay taught me to play golf. Of course I’d played a little before but never really had the time to get any good at it. What really worked for me was the way Jay taught me to clubs. Initially I was only allowed to carry a 2, 6, and putter. Darn it! I have a whole bag of clubs! But we started with just a few. Once these were mastered, he allowed me more clubs.

So often, when you’re trying to learn something new, the topic can be overwhelming. Maybe we’d be better off to follow Jay’s advice and pick just a few clubs.

Lately everybody seems to be saying you should learn to program. But unless you have a reason—an application—you’re unlikely to stick with it. Same for a web site, or a blog, or whatever.

A friend hasn’t used Excel in years but thinks she should know it. But no matter how she tries, she just can’t get into it. The problem is, she doesn’t need it. She doesn’t have an application. And I’ve found that can’t really learn something until you have an application for it—a real need.

In my years teaching product management courses, people often said they wished they’d had the course when they started. But I wonder. Too many clubs just make for a confusing bag. Maybe new product managers need to ease into the job. (Particularly when everyone else in the company is desperately trying to dump their work on the new guy.)

Nowadays what I try to do is introduce people to frameworks just when needed

I have a bucketful of business frameworks—like three horizons, five forces, the S-curve of adoption. The trick isn’t to know the metaphor; the trick is to know when and how to apply it to your business problem.

What clubs should you start with? See my article Your first days… as product manager.

Your first days… as product manager

You’re in your first days as a product manager. In no time, your calendar is full and you have a zillion emails. There’s so much to do. Where to begin?

Before the demands of others overwhelm you, you need to prepare yourself to be the business and market liaison to the product team. Your role as a product manager or product owner is to make the best business decisions for the product, working from the best available information.

Refresh your domain expertise

If you’ve been in your industry for years, you probably have strong domain expertise but you may not be up-to-date on the latest information.

Review the corporate pitch. Perhaps the fastest way to get up to speed on your company and its role in the industry is to review the product and corporate slide decks. Whether your company is a bellwether in the industry or on the periphery, what’s been said in the past will help you understand how your company and its products are perceived, at least from the perspective of your new organization.

Catch up on the latest blogs and articles. Take time to review the latest thinking in your industry. And even if you’ve been in the domain for years, it’s always helpful to take a new look from your new perspective as a product leader. Reports from industry analysts may reveal new industry trends, and perhaps show how your company and products are influencing them.

Fill out your technical expertise

You may have some familiarity with the product from your past research. Now it’s time to get into the raw details.

Know your new product. What documentation exists for your product? You can probably find some customer documentation and help screens, release notes, product plans, sales and conference presentations, white papers and ebooks, and sales enablement tools. Review them all. Learn the key capabilities, particularly those that are competitive differentiators.

Review the product roadmap. And where is the product headed? Has anyone developed a roadmap for the next few releases? How does what you’re seeing align with what you know about the domain and industry?

Understand the architectural themes and challenges. Talk to the developers about the technical challenges for the product. What percentage of development effort is spent on architecture and defects versus new functionality? And while you’re at it, interview the developers about their perspective on your role in moving the product forward.

Update your market expertise

You likely have some market expertise but it never hurts to give yourself a refresh.

Sit in on some customer support calls. Want to know what’s going on with your product in the field? Ask customer support. They know about technical problems with the product as well as customer implementation problems. Sit in on some support calls and listen to customers directly.

Go on some sales calls. It’s fascinating to examine the contrast between the product as perceived by the product team and by the people in the field. When you’re on a customer visit with your sales team, you’ll hear how the product is being sold—right or wrong. You’ll also hear unfiltered customers’ problems in their own voices. Listen to the language they use; listen to the problems they’re trying to solve. You’ll get plenty of ideas for how to improve the selling and promotion of your products. And you’ll get to know some sales people in a more social setting; they’ll be your contacts in the future when you need advice on sales enablement and product improvements.

Do some installation/implementation visits. For enterprise products, implementation is where all your sales and marketing promises meet the real world. Watch (or help) the implementation teams install the product; sit in on any customer training; examine closely the areas where the product must be configured or customized to work in the customer environment. You’ll definitely get some great ideas on improving the product.

Eventually, you’ll want to start visiting customers without a selling or support objective but get these initial customer touchpoints under your belt first.

Leverage your process expertise

Now that you have a strong understanding of the technology, industry, and domain, take a look at your internal product processes. What methods are used in your organization? Where are the company templates stored? And which of your favorite processes apply to your new situation?

Evaluate existing processes and systems. If you’re stepping into an existing job, you’ll likely find a set of methods that are already in place, formally or not. If you’re part of a new product management team, you’ll want to be a driver in defining your product processes.

What artifacts are necessary? What minimal set ensures success? Is your organization clear on what constitutes a requirement and what’s actually a specification? Which positioning technique is used, if any?

Start your own product playbook. Take all your methods and the company’s methods and put together a set of living documents. You’ll want your product plan and financials, buyer and user profiles, positioning, requirements, maybe a price list or pricing model, and any other documents that you reference often. Print them or store them in your dropbox so you’ll have them handy. For more on the product playbook idea, see http://appliedproductplaybook.com

What should product managers do in their first days?

Look for high-impact deliverables that don’t require much up-front effort. Train the sales engineers and product implementation team. Develop informal product champions. Refresh or refine your product positioning, taglines, and blurbs so you can do “copy-and-paste marketing.”

Then focus on the methods to make sure you have a minimal set of effective processes that ensure product success.

What tips do you recommend? Add your thoughts in the comments area. 

Your first days... as the head of product management

Take time to work on the business, not just in the business.—Richard Rhodes

 

Do you lead a new product management team? Where should you begin?

In The Earth is Flat, Thomas Friedman expressed his view of the government’s primary role: to provide infrastructure. Make it easy to start a business, protect our persons and property from harm, provide ways to get products from point a to point b (ie., roads), and enable information transfer (such as phones and internet).

What is the role of senior leadership, particularly the head of product management? Isn’t it the same? To provide infrastructure.

In my experience, decisions are being made at all the wrong levels of most organizations. Executive teams are dabbling in product and portfolio prioritization while product managers are trying to determine (or guess) the product strategy. Shouldn’t it be the other way around?

The product manager is expected to represent the business of the product so your dev teams can make technical decisions. At the start of a project, the product manager (or product owner or product leader) should express the strategic direction, the roadmap, and the business issues. But what seems to happen in real life is product teams make decisions in the absence of any meaningful insights from management about the product and portfolio direction.

What should you tackle in your role of VP of product management?

Think infrastructure.

Optimize your processes. What processes do you have in place to turn ideas into products? And how do new products get to the market? Fundamentally, product management needs repeatable processes to define and launch new product capabilities. Development teams have adopted agile methods to optimize their delivery of new products. Shouldn’t you do the same?

Clarify roles and responsibilities. What is the product manager’s role? How about product owner and product marketing manager? Do they have different responsibilities? Just as you need optimized processes, you need clarity on the roles and responsibilities of product management. Profiling your team will identify where individuals need help as well as skill areas for future staffing decisions. For instance, if you’re strong in technical expertise, maybe you need to staff up for business expertise. 

Identify up-skilling requirements. Identify the strengths and weaknesses on your team and develop a plan to bring each employee up to speed. HR professionals often recommend allocating 3% of an employee’s annual compensation for training and coaching.

Improve internal perceptions. How do other departments perceive your team? If their perceptions aren’t favorable it’s often because they have expectations that are out of sync with yours. While many departments expect product management to provide product and domain expertise, most leadership teams rely on product management for business and market expertise.

* * *

In my experience organizations are unclear about the roles and responsibilities and titles of product management. Some product managers are technical; some aren’t. Every product manager uses different templates, tools they’ve found or developed or brought back from training sessions, each with a different look and feel.

As an product management executive, you want a common set of methods so you don’t have to “learn” each deliverable every time. Clarifying responsibilities, processes and deliverables are the first steps to optimizing product management. 

See Rich Mironov's "What We Need in a VP of Product Management" for a different take on the success profile of a product management leader.

How to prep your team for an annual review

In my first job out of college, I was a programmer in Fort Worth. The job was challenging but not very clearly defined so it took me a while to find a good working scenario. By the end of my first year, I knew what I was doing but I wasn’t too thrilled with it. At my annual review, my boss said, “I don’t think you should continue working here.” (YIKES!) But then he added, “I’d like you to interview with a friend of mine in Dallas.” He looked at my skills and performance, and realized that I would be better suited as a sales engineer than as a programmer. Now that’s a manager!

Love ‘em or hate ‘em, the annual performance review is a required event at many companies. Many on your team see the annual performance review as a healthy discussion about their careers. Or else face them with dread, fearing you’ll have nothing helpful to say.

They also think you spend a lot more time on these reviews than you probably do. From their standpoint, you hold their career in your hands. They don’t realize that you have to do one of these damn things for every person on your staff and the work is more annoying than anything else.

From “Invasion of the Annual Reviews” by Phyllis Korkki

The annual performance evaluation is “this weird form you fill out every year that has nothing to do with everyday life,” said Robert Sutton, a professor and organizational psychologist at Stanford and co-author of the forthcoming book “Scaling Up Excellence.” Sutton is wary of rankings and yearly evaluations in general. Many organizations, he said, would be better off if they provided continuous feedback, with formal evaluations coming into play mainly if a worker is being eyed for promotion or has shown substandard performance.

Your people should value your feedback. Good or bad, knowing where they stand can only be helpful.

Start with current status. Do you have a product status dashboard or score card? You should have a one-page summary of the state of every product your team manages. (If not, see mine here). Could you use a similar approach for your team’s accomplishments? Whether by person or by product, a summary cheat-sheet is a helpful tool to get you prepared for your evaluations.

Get a success memo. I suppose in an ideal world we’d keep a log of all the good and bad things employees did throughout the year but I certainly never have. As managers, we tend to have short-term memory; we can probably only remember the last thing an employee did, or perhaps the last bad thing an employee did. We surely don’t remember some of their successes from six months ago. So ask them for a “success” memo. Get your folks to write a list of accomplishments: the projects they worked on, their product deliverables, their goals achieved. You’ll likely be surprised at some of the things they tell you about—things you’ve long ago forgotten but were really big at the time.

Discuss growth and stretch goals. In your face-to-face discussion, talk about their career plans and help identify specific activities to help them achieve their goals. One product manager wanted to better understand the mechanics of trade shows so putting that item on their next year objectives made sense. Another wanted a closer relationship with sales people so we discussed good and bad approaches for working with the sales team.

Discuss how to move to the next step in the career ladder. There’s an old rule of management that you need to be grooming your replacement if you ever want to be promoted yourself. Your existing team members are likely the best candidates to take over your job. Discuss where your employees want to be in the next few years and give them specific tips on how to get there. I used to ask my team to write next year’s resume and then we’d work this year to make it become true. In fact, a current resume is a pretty good tool for discussing where your team members’ pasts and potential futures.

Share your own challenges. Be sure to take some time to solicit help and advice from your product managers. It’s always easier to see things from the outside and you may be amazed what observations they have that you’re too close to see. After all, you hired your people to help you solve business problems; let them help you solve your business problems!

diamond50.png

As a manager, you owe it to your employees to give them career counseling. But don’t do all the data gathering yourself. Use existing information or get your employees to pull the raw data together. Then use your management skills and career experience to analyze the data so you can provide specific recommendations. Your team will appreciate that you cared enough to prepare a meaningful assessment.