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.

Roadmapping That Works

Thanks to everyone who attended last week's webinar. I appreciated all the great questions. The recording and slides are now available as well as a full set of Visio and Excel templates below. I will also post the questions and answers from the webinar. I plan to add a lot more content in the coming weeks to provide greater detail about our product roadmapping framework and how to use it.

iStock_000011359879Small.jpg

Basic Template - Excel / Visio

Expanded Template - Excel / Visio

Advanced Template - Excel / Visio

Top Ten Signs That Your Product Manager Isn't Agile

Blog Editor's Note: This post originally appeared in late 2008 when we were Enthiosys. I'm very interested in whether anyone else agrees that the list still resonates. Enjoy.

Originally Published October 20, 2008

Here at Enthiosys [now Applied Frameworks] we spend a lot of time helping Product Managers become Agile. In the process, we often run into developers who are really frustrated with their Product Managers' lack of Agility. Acknowledging their pain, here are our top ten ways to tell if your Product Manager doesn't understand Agile. And yes, it was hard to whittle down from the 40+ items on our initial list.

10. She says "I think" instead of "the market research says" or "during our last review meeting with a customer…".

9. He thinks release planning can be done in 2 hours.

8. She sometimes attends an iteration planning meeting, and rarely (or never) attends an iteration acceptance meeting.

7. He thinks the backlog is just the list of market problems he captured in his MRD.

6. She doesn't have a roadmap beyond the stories in the next release.

5. He thinks MuSCoW works when prioritizing the backlog.*

4. She can't provide acceptance criteria during release or iteration planning.

3. He stops visiting customers so he can attend every daily standup. Even worse, he talks about his tasks during the daily standup.

2. She thinks that year-old market data is good enough for managing the backlog or developing a roadmap.

1. He thinks a product owner is a Product Manager.

*MuSCoW is a way to organize requirements into buckets of "Must, Should, Could, Would".

productcampRTP 2014 Presentation

I enjoyed spending Saturday at pcampRTP and appreciated the opportunity to present Finding the Best Frameworks for Product Management. The concepts in the presentation have been percolating in my head for a long time and I finally had a great venue to get the ideas organized, expressed and validated through feedback from a terrific audience. The roadmapping concepts resonated most and I plan to follow up with several more posts on roadmaps.

I look forward to seeing the other presentations once they're shared by the organizers. Some highlights - Mark McClear from Cree delivered a great keynote about their LED light bulb history from a product adoption point of view. Greg Hopper presented a fantastic overview of Product Strategy Lessons from Apple - a light speed talk in over 90 slides in 40 minutes. I can see how his courses at Duke must interest students.

Steve Johnson will be at the next pcamp in Boston on May 3rd. I recommend attending if you're in the area since time at these camps is well spent. 

It's difficult to manage P&L...

It’s fairly common for product managers to be asked to act like “mini-CEOs” or “the president of the product. Good idea in concept but harder to implement in real life.

product-scorecard.png

Even if you don’t have actual control over P&L, you can control reporting of P&L. Try using a scorecard approach, a key deliverable in a product playbook.

I was working with a team on their scorecard but alas, all of their metrics were focused on development productivity: how many defects, how many hours, how many stories, how many features…?

But what about metrics on the business of the product from your perspective?

  • What are development costs against plan? Revenue against plan?
  • How many calls to support? Is that more or less than the monthly average? What is the trend?
  • How many leads from marketing? How many were rejected by sales?
  • What is your win rate and what are the top reasons by you lose?
  • What are the trends in Net Promoter Score or other loyalty-related metrics?

Fundamentally, what are some of the business metrics you should have at your fingertips? What questions are your execs asking that you should be able to answer? Be the source of metrics on the business of the product!

What other metrics would you capture?