I’ve been mulling over a new metaphor for product management: farming. The farm metaphor has been used to describe software development in general. I believe it is also relevant to describing, specifically, the product management process.

Farmers produce crops to fill a societal need. Some crops are staples that drive modern society, growth, and advancement. Others are more vanity, but provide for another need: satisfying differing tastes and a desire for variety.

Product managers product products to fill a societal need. Some products are major innovations which end up driving our society. Others, such as entertainment products, provide for a different set of needs but real needs nonetheless.

A farmers job is to produce successful crops in a sustainable way. There are many choices and factors that determine the success of any given crop. To decide which seeds can and should be planted, farmers gain an understanding of the environment, including soil, climate, and the market in which the harvested goods will be sold. They negotiate for and purchase resources, such as land on which to grow crops and, water rights with which to nurture them.

A product managers job is to produce a successful product in a sustainable way. There are many choices and factors that determine the success of a given product. The product manager must understand the market need and the environment (what is possible) in order to make the most effective choices. They have a limited amount of resources with which to complete the job. They work within the constraints and capabilities of these resources while simultaneously acquiring and negotiating for additional resources as needed to ensure success.

To reap a successful harvest, the crop must be gingerly cared for while it is growing. It must be given the proper amount of water and nutrients. It must be protected from predators and adverse environmental conditions. Not all attention can be given to a single field, a single row, or a single plant. Farmers must distribute their time to ensure that the farm, as a whole, is successful. At the same time, they must be aware of the details to watch for signs of trouble or make adjustments as needed.

As a farm has fields, products have features. A product manager must decide which features to build and then care for the development of that feature. To develop a product and features successfully is actually a fragile process. The quality of the end result depends on the environment in which it is grown. Product managers should play a part in monitoring and shaping the environment to protect the product and the product team. Sometimes problems will arise that take focus away from success, and care must be taken to ensure that continued focus on the problem is justified.

Predators are an important threat to a successful crop. Farmers must be diligent in protecting the crop from these pests. They have a choice in how they protect their crops. For example, they may spray pesticides or they may introduce natural predators of the pests.

While everyone is supposed to be on the same team, stakeholders are often the biggest threat to a products success. Every stakeholder is naturally biased to their own position. Product managers must be respectful of stakeholders’ point-of-view while at the same time keeping the product vision and strategy in mind. Product managers have choices in how they interact with stakeholders to keep everyone aligned and truly on the same team. The choice of interaction style plays an important part of how engaged those stakeholders will be to the products success.

Some circumstances are outside the farmers control. A doubt, or a deep freeze may threaten or destroy a crop. Farmers must do what is within their power to protect their crops, but must also recognize when a crop is or will be unsuccessful. They should take steps to mitigate the situation without being attached to a sunk cost. They must also keep everyone motivated to keep going despite occasional failures.

Every product starts with an idea. Hopefully the idea meets a market need, or the product has very little chance of being successful. Even ideas that meet perceived market needs, however, need to be adjusted based on experience. In some cases minor refinements are all that is needed. In others, major shifts in strategy that will result in lots of rework are necessary. Product managers must continually examine their position and adjust or cut losses as necessary to stay viable and competitive.

With a little luck and a lot of hard work, the crop matures into a healthy and viable product. The farmer must take this product to a market full of competition. It helps if the crop can be uniquely positioned within the market. An understanding of the market led the farmer to make choices about what to plant and how to grow it. A crop may have been position as a high quality organic product that appeals to upscale local markets or oversees customers, or as a low cost organic product suitable for mass sale in national supermarket chains. These choices will now be played out in the market.

With a little luck and a lot of hard work, a viable product is born. The product manager must take the product to a market. In most cases the market will already have competition. Even if there is no competition, as is the case when the product creates a new market, competition will be sure to follow if the product is successful. The most successful products will have a unique position, which was painstakingly crafted and protected by the product manager throughout development. A good position will allow the product to be successful even in markets full of competition.

Part of the farmers success in the market will be determined by reputation. Especially in the modern age, where information sharing is at an all-time high, it is becoming difficult to keep lapses in judgement and quality a secret. Thus, farmers must be vigilant in maintaining a high quality of work and product produced.

Unlike crops, product features tend to stick around past the point of harvest. In a sense, they are continually harvested to continue building the success of the product. Features are a bit like reputation. They are really hard to get rid of once you have them, so product managers should be careful to what and how features get developed.

If the farmer succeeds—in picking good, nutrient rich land in a good climate and picking crops to match the climate and the market; in choosing and following a position for how to produce and sell the harvested product in the market; in nurturing and protecting crops during development; in cutting losses that would take focus away from successful crops; and finally in taking to market and promoting the harvested crop—they will be profitable and can continue to iterate many times over.

Finally, if the product manager succeeds—in picking a good idea that will satisfy a need in the market and is possible to build; in positioning the product for success in that market; in nurturing and protecting the product throughout development; in maintaining focus and adjusting and cutting losses where necessary; and in taking the product to market and promoting it—they will be profitable and can continue to turn their ideas into reality.

Posted via email from Learning Product Management | Comment »

Reproduced from the Learning Product Management board on Quora.

One warning sign I’ve developed a sense to watch for is when a developer reports that something is or was “hell” to implement. This often translates to an incomplete understanding of the problem, the solution, or the technology needed to implement the solution. Having an incomplete understanding is natural when solving new problems or learning about new areas. However, an incomplete understanding becomes dangerous when coupled with a lack of desire or inability to gain understanding.

Without adequate understanding, programmers may engage in guess-and-check programming. They stumble closer to a “working” solution by guessing at changes that might fix an issue encountered, checking after each to see if it does. This may be appropriate in some very limited situations. More often, however, bad things will happen when programmers make lots of changes to fix issues without understanding why it appears to work. Without taking the time to understand, they will miss things or cause unintended consequences, i.e. side-effects. This creates a form of technical debt which causes problems for all involved down the road.

There are many reasons why someone may not get an adequate understanding. Perhaps they feel it is not important, or underestimate the complexity. Perhaps they are under a tight, externally imposed deadline and lack the confidence or perceived authority to challenge the deadline given the situation. Or, perhaps they simply do not realize that their understanding is inadequate due to inexperience or stubbornness. It takes a certain level of maturity to realize that you’re in over your head, and need to take a step back, when you’re already on the battlefield.

One thing that you and fellow team members can do to help is to watch for the warning signs and react to it. It’s in all of your best interest to do this. As a product manager, you’ll pay the price if you don’t. Some of the consequences include having to incur the cost of fixing resulting bugs, pissing off customers, and perhaps even having to completely redo a feature. I’ve faced these consequences many times, and thus have become sensitized to the warning signs. The one that I pointed out at the beginning of this post, when something is referred to as “hell,” is a common one on my team.

If you recognize the warning signs, you can take steps to help the impacted developer or team before it becomes a serious issue. The steps to take depend largely on the situation. Here are a few you might consider.

First, you can ask them about it. Just having someone serve as an outside observer, in a constructive way, can help give someone the nudge needed to get unstuck from the muck. For some teams this can be done directly. On other less healthy teams the direct approach may be perceived as threatening. In this case the same effect can usually be achieved indirectly, through a team lead or manager.

Second, if you know of someone else inside or outside the organization with a better understanding of that area, you can attempt to hook the developer up to that resource. Alternatively you may be able to do a bit of research and find good materials on the Internet.

Third, you can be supportive. Offering to talk candidly about a deadline, scope, or importance of an issue indicates to developers that it’s OK to bring up issues that may cause delays, and that properly executing a feature is usually more important than sticking to a deadline. Of course this option must be exercised with caution—you don’t want to lose any perceived urgency that you have painstakingly built up, but yet you want to foster a healthy and supportive environment. Striking a balance is difficult but important.

Finally, you can work with the team on an alternative. Sometimes something that is causing a lot of frustration or will take a lot of time to understand adequately may not be worthwhile. There may be an alternative approach or solution that is more desirable, given the level of effort involved. If, on the other hand, it is actually very important, you can make sure that the developer understands just how important it is an why. This knowledge helps arm them against the doubts which will rise in their mind against their own judgement, and justify the level of care necessary in the work. The team will look to you to help make that determination.

These are just some examples. Inevitably you’ll find many intelligent ways to handle this situation. However, you can’t react to the warning signs unless you know how and what to look for. My friendly advice to you is to pay attention to your team and look out for warning signs such as the “hell” heuristic, and to then take steps necessary to ensure your team is not sacrificing understanding and thoroughness for expediency. Otherwise you’ll likely regret it later.

Posted via email from Learning Product Management | Comment »

The deal is nearly done.

This sale is the biggest sale of your product yet. A significant milestone by any measuring stick. The buy decision hinges on one critical feature which you happily agree to build as it strategically aligns with your product roadmap. It’s not every day the stars align!

You must act fast and execute well. A minor slipup will not jeopardize the deal, but as a relatively new entrant in the market a failure to execute could scare the customer away and into a competitors arms. Furthermore, this is a major chance to prove the part of the product vision and to score a major motivational win. You really want to get this one right.

First things first. You’ve worked with sales and the customer to figure out exactly what needs to be built, and why (i.e. what problems it will solve for them). You nail down minimum scope needed to solve the problem and clinch the sale. You also add a pinch of dazzle for good measure and buzz power.

Play it cool. “Sure we’ll build this for you, as a special favor because we truly value your business!” It not false, but behind the scenes you’ve been planning something like this already and you’re glad for an excuse to give the priority a major bump. It will take time to complete the picture, but this feature is a key to open open doors in the future. Your enthusiasm cannot be contained.

Next things next. Time to communicate it to the team. You have two options, and these two options are the point of this little story.

Option A: You fire up your email client, write a quick 2 paragraph summary about what is happening, why it’s great, and what you need. “I would like to have a quick chat about next steps, so please come by when you have a minute!” you say as in your email to the key players. You await their response. It comes in the form of a meeting request for later that day for you and each of the key players which will hear your feature request and see what can be done.

Option B: You walk over to one of the key players desks and tell them, face-to-face, that you have some very exciting news and need their help. Do they have a minute? You briefly overview the situation and a high level picture of the feature, emphasizing the opportunity that is presenting itself and how much it will mean to absolutely crush it. That key player starts mulling over the possibilities and (as a developer) immediately starts telling you about this fantastic solution they will be crafting.

Which option do you think will lead to lead to a better outcome? In my experience, Option B is the way to go in nearly every possible case. Why? Roughly the same information is being communicated in both options, right? Wrong!

Option A and B may both communicate the same tactical information, but Option A has blunted a very import tool in your inspirational tool chest: your emotion. It’s very difficult to communicate enthusiasm in an email. Even if you go to pains to do so, it’s still going to be less effective in 99%+ of cases, especially when the same care is given to a face-to-face delivery.

Another advantage that option B has is that it allows you to start building excitement incrementally. The dynamic of dealing with a single individual in face-to-face communication is completely different than the dynamic of a group email or even a group meeting. Starting with a single individual makes the interaction an individual one. The chance of a “me vs. them” attitude infecting the conversation is much less than might be the case when presenting to a group of people. Get one or a small number of people behind you and allow them to be the torch bearer. They are closer to the action, the trust is there, your methods will be appreciated.

I’m not arguing that choosing Option A will completely sabotage the chance of success. However, my experience has led me to realize that Option A will lead to more uphill battles, misunderstandings, and loss of motivational opportunity. If you’re into statistics, think of Option B as increasing your chance of success in a probabilistic system. Even the best idea can flounder with poor execution. So too can the best course of action be derailed with poor communication.

Despite having seen this borne out time and time again, it’s still tempting to write out an email for many situations in which face-to-face communications would lead to better outcomes. Now that I’ve written about it, maybe I’ll remember the lesson a little more frequently!

Posted via email from Learning Product Management | Comment »

Posting another answer I posted to a question on Quora about resolving conflicting #1 priorities.

The Question

What are good ways to resolve conflicting “#1 priorities”? This is an open-ended question intended to spur discussion, I have no particular conflicts that need resolving at the moment.

My Answer

I find a few ways to interpret this question: that the priorities conflict because you cannot do both at the same time, that they conflict because the output of each is mutually exclusive, or that they conflict for political reasons. I assume you’re talking about the first, but please let us know if not.

This three step process may be helpful to resolve time/resource based conflict:

• Reexamine both priorities to make sure they truly are priorities
• Look for a solution that can make a partial headway on both
• If all else fails, do some priority calculus

I’ll discuss each below while attempting to keep the tips/techniques generic to any type of “priority.” I use “solution” as a generic term for whatever the priority is (be it taking some action, adding some feature, selling to some particular client, etc.).

RE-EXAMINE THE PRIORITY OF EACH

This first step is a heuristic designed to save time. These basic questions, applied to each solution, hopefully help you arrive at a decision quickly:

• Ask yourself “what would happen if we don’t do this?
• Are we solving a core problem, or working on context?
• What problem is being solved (prioritize problems over solutions)?
• How many customers/users does this solution benefit?
• Does the solution fit into your products strategic vision?
• Does the solution fit into your organizations strategic vision?
• How well does the solution fit into the roadmap in terms of timing?
• Are other high priority items in the backlog complemented either solution?

LOOK FOR A SOLUTION TO MAKE PARTIAL PROGRESS ON BOTH

If the initial step to re-examine each priority does not turn up a clear winer and loser, consider looking for a way to make a little bit of progress on each.

If you’re solutions are somewhat related, I suggest conferring with the team. Two heads are better than one, and they might come up with a “3rd way” that resolves the conflict by meeting a little bit of both needs, or even better by finding a solution which is mutually reinforcing. You never know what the brilliant minds around you are capable of.

If the solutions are not at all related, you can still realize some benefit. First, you’ll have to reduce scope for each, which is usually a good practice anyway. Having an aggressive constraint really helps to trim the fat (less useful parts) from your solution.

Second, through the course of working on each solution, you’ll probably learn more about their relative priority. One of them may turn out to be less important than you thought. Sometimes this realizing just happens naturally in the course of development.

Third, by releasing a partial solution, you increase the chance that you’ll get feedback on the direction your taking, which could turn out to be great or completely wrong. The feedback may change the priority, solution, or both. What’s being described in these three benefits is basically the iterative development process.

DO SOME HEAVY DUTY PRIORITY CALCULUS

Finally, if you don’t find any obvious difference in priority and do not find it advantageous to implement a partial solution for each (or the solutions are already at the lowest level of scope), then it may be time to turn to a more in-depth analysis. One such method is a prioritization matrix.

There are a few different types of prioritization matrixes. One type assigns features into quadrants. If you’re solutions end up in different quadrants, the decision would probably be easy. Otherwise, you may look into another common type of matrix which compares items by assigning numerical scores on a number of factors. Recognizing that priorities differ depending who you’re talking to, prioritization factors are often categorized by function (i.e. for sales, customer impact, etc.). The factors are weighted, the value of which depends on you, your organization, and what stage of development your product is currently in.

When compiling a feature matrix I find it helpful score items yourself for the first round. Then, get feedback from others as to why they think it should be higher or lower. The resulting conversation can uncover a lot of assumptions.

A nice feature about numerical scores is that they make it a little easier to compare line items. You might ask, “You say this should be a 4, but is it truly as important as this other item which is also a 4?” Be careful, however, as feature matrixes discussions can have a tendency to get overcomplicated. “Well, yes this is a 4 too, but only if that other item gets completed, because this item is pointless without it,” for example. Just remember that it’s ok to make assumptions and move on. The prioritization matrix should be a living document that is updated periodically.

The bottom line is that doing some kind of structured analysis, such as using a feature matrix, can help objectify the decision in order to unstuck yourself. Additionally it can be good for situations in which the decision for priority is politically charged.

ONE LAST (IMPORTANT) THING

If you’re the product manager, then in the end you need to make a decision. Go with your gut instinct if an objective analysis does not turn up a clear winner, or if the impact of the decision is sufficiently small as to be unworthy of conducting the analysis in the first place.

NOTES

• For more on core vs. context: Geoffrey Moore at Business of Software 2009
• For more on prioritization matrices, Google it!

Posted via email from Learning Product Management

Posting another answer I posted to a question on Quora about resolving conflicting #1 priorities.

The Question

What are good ways to resolve conflicting “#1 priorities”? This is an open-ended question intended to spur discussion, I have no particular conflicts that need resolving at the moment.

My Answer

I find a few ways to interpret this question: that the priorities conflict because you cannot do both at the same time, that they conflict because the output of each is mutually exclusive, or that they conflict for political reasons. I assume you’re talking about the first, but please let us know if not.

This three step process may be helpful to resolve time/resource based conflict:

• Reexamine both priorities to make sure they truly are priorities
• Look for a solution that can make a partial headway on both
• If all else fails, do some priority calculus

I’ll discuss each below while attempting to keep the tips/techniques generic to any type of “priority.” I use “solution” as a generic term for whatever the priority is (be it taking some action, adding some feature, selling to some particular client, etc.).

RE-EXAMINE THE PRIORITY OF EACH

This first step is a heuristic designed to save time. These basic questions, applied to each solution, hopefully help you arrive at a decision quickly:

• Ask yourself “what would happen if we don’t do this?
• Are we solving a core problem, or working on context?
• What problem is being solved (prioritize problems over solutions)?
• How many customers/users does this solution benefit?
• Does the solution fit into your products strategic vision?
• Does the solution fit into your organizations strategic vision?
• How well does the solution fit into the roadmap in terms of timing?
• Are other high priority items in the backlog complemented either solution?

LOOK FOR A SOLUTION TO MAKE PARTIAL PROGRESS ON BOTH

If the initial step to re-examine each priority does not turn up a clear winer and loser, consider looking for a way to make a little bit of progress on each.

If you’re solutions are somewhat related, I suggest conferring with the team. Two heads are better than one, and they might come up with a “3rd way” that resolves the conflict by meeting a little bit of both needs, or even better by finding a solution which is mutually reinforcing. You never know what the brilliant minds around you are capable of.

If the solutions are not at all related, you can still realize some benefit. First, you’ll have to reduce scope for each, which is usually a good practice anyway. Having an aggressive constraint really helps to trim the fat (less useful parts) from your solution.

Second, through the course of working on each solution, you’ll probably learn more about their relative priority. One of them may turn out to be less important than you thought. Sometimes this realizing just happens naturally in the course of development.

Third, by releasing a partial solution, you increase the chance that you’ll get feedback on the direction your taking, which could turn out to be great or completely wrong. The feedback may change the priority, solution, or both. What’s being described in these three benefits is basically the iterative development process.

DO SOME HEAVY DUTY PRIORITY CALCULUS

Finally, if you don’t find any obvious difference in priority and do not find it advantageous to implement a partial solution for each (or the solutions are already at the lowest level of scope), then it may be time to turn to a more in-depth analysis. One such method is a prioritization matrix.

There are a few different types of prioritization matrixes. One type assigns features into quadrants. If you’re solutions end up in different quadrants, the decision would probably be easy. Otherwise, you may look into another common type of matrix which compares items by assigning numerical scores on a number of factors. Recognizing that priorities differ depending who you’re talking to, prioritization factors are often categorized by function (i.e. for sales, customer impact, etc.). The factors are weighted, the value of which depends on you, your organization, and what stage of development your product is currently in.

When compiling a feature matrix I find it helpful score items yourself for the first round. Then, get feedback from others as to why they think it should be higher or lower. The resulting conversation can uncover a lot of assumptions.

A nice feature about numerical scores is that they make it a little easier to compare line items. You might ask, “You say this should be a 4, but is it truly as important as this other item which is also a 4?” Be careful, however, as feature matrixes discussions can have a tendency to get overcomplicated. “Well, yes this is a 4 too, but only if that other item gets completed, because this item is pointless without it,” for example. Just remember that it’s ok to make assumptions and move on. The prioritization matrix should be a living document that is updated periodically.

The bottom line is that doing some kind of structured analysis, such as using a feature matrix, can help objectify the decision in order to unstuck yourself. Additionally it can be good for situations in which the decision for priority is politically charged.

ONE LAST (IMPORTANT) THING

If you’re the product manager, then in the end you need to make a decision. Go with your gut instinct if an objective analysis does not turn up a clear winner, or if the impact of the decision is sufficiently small as to be unworthy of conducting the analysis in the first place.

NOTES

• For more on core vs. context: Geoffrey Moore at Business of Software 2009
• For more on prioritization matrices, Google it!

Posted via email from byte plight | Comment »

An answer I posted to a question on Quora about protecting complexity when it is required received positive feedback. The question and my answer follow.

The Question

As a Product Manager who is technical, what are the best ways to protect a feature that requires additional complexity from the Simpletons? I have external influences in my product organization that tend to oversimplify features to a point that results in the final result being insufficient to meet the required needs of my customer. What is the best way to manage these influences and preserve the integrity of my feature and future integrations. We practice Agile in my organization and tend to under-develop a feature in order to release it, but end up having our lunch eaten by our competitor when it comes to capability?

My Answer (with minor edits)

I’m sorry, but my experience is exactly the opposite: you should listen very carefully and attempt to please the “simpletons” as much as possible. They are invariably trying to tell you something useful. It may not seem so, or it may not be easy to hear, but it’s almost always worth the time to explore.

If I get pushback that a design is too complex, I try to go back to the drawing board. Re-examining the data and assumptions about the problem leading to the current design invariably yields new insights. I would also examine each element of the component design and how it maps back to the problem. A careful analysis pretty much always leads to alternatives that had not been considered (or not enough).

Surprisingly often, improvements on the original design come out of this process. Occasionally an entirely new path becomes apparent. The old design is thrown out in favor of something better. The most infrequent case by far is a conclusion that the current feature was perfect as is and should be left alone.

If doing this process transparently, you will often have reached a compromise with the outside influences by now, and they are satisfied. Even if the feature is justified as is, going through this process will help you clarify and simplify your thinking. Often, pushback is just the result of insufficient or unclear communication. Clearly communicating the problem, rather than the feature, and then clearly communicating the feature in simple terms, can be enough to put the issue to bed.

Before you start re-examining, the most important step is to simply listen. And by listen, I mean listen carefully. As a technical PM, you may suffer from the same problem that many other technical people do. You’re a problem solver and your mind moves quickly. You may be good at listening, but invariably your mind races ahead of others. If you’re not careful, you steamroll what they are trying to tell you before they get a chance to say it. Shut up and listen. They are not “using it wrong” or “thinking about it wrong,” they are simply trying, in their own way, to communicate to you how they think about the problem. Understanding how they think is important. Furthermore, listening carefully will help others feel hear and that their needs are being considered. This alone can go a long way towards bridging the gap.

I would also suggest that you watch Geoffrey Moore’s points on core vs. context as they relate to your feature: http://blip.tv/business-of-software/geoffrey-moore-at-business-of-software-20…… Are you battling over core or context? If it’s context, your probably better of focusing on core. If you’re not sure, then you probably need to spend some time to define core and context for your product.

In summary, I would suggest that you: * Listen carefully to the needs of those influencers. They are trying to tell you something that you should not get in the habit of ignoring. Don’t talk over them. Just shut up, listen, and ask lots of questions when they stop talking. * Reexamine the problem and solution, especially from the point of view of your users, to uncover your assumptions and clarify your thoughts such that you can communicate them clearly and simply. * Iterate the design to find potential improvements or new designs. Document the iterations where necessary. Just seeing a document where you’ve outlined a feature analysis can be enough to convince others that you’ve done your homework, and allow them to trust your decision. * Think about your product and whether the problem you are struggling with is core or context. If it’s context, ask yourself if it’s worth it.

One last thing. The final call should be that of the product manager in charge of that product, perhaps with veto power granted to a product executive such as the founder. Nonetheless it’s important to take all stakeholders views into consideration and, as much as possible, get consensus. Consistent failure to do this can and will lead to bad, bad things.

Posted via email from Learning Product Management

In the previous post, product management was considered as a craft. Specifically mentors, a salient features of a craft, were discussed. Newer product managers can avoid making costly, live-fire mistakes by tapping into the experience of mentors available to them. I suspect that most product managers have mentors available to them. Whether or not they choose to utilize their mentors is a separate issue. In this post, I briefly discuss another characteristic of the craftsmanship: mastery level.

In traditional craftsmanship, mastery level is thought of as three successive stages: apprentice, journeyman, and master.

Apprentices are newcomers. They have embarked on a journey to learn the craft. They may have started this journey some time prior, but have not yet acquired enough competency to practice it without the guidance of a teacher (i.e. mentor). A common mistake of apprentices is to underestimate their own lack of knowledge in their apprentice stage. I would like to say this is caused by enthusiasm and eagerness, but I believe it is often a more sinister cause: pride. Apprentices outward behavior may often be described as cocky as a result of this. Cockiness is expected, they do not yet know.

Journeymen have gained enough experience to be trusted to work on their own, without the direct supervision of a teacher. However, they are not yet considered to be experts at their craft. Apprentices may misjudge journeymen as masters, stemming from the same problem that causes apprentices to misjudge their own competence. However, wise journeymen know that there is much they do not yet know. They understand the depth of their own inexperience. To make up for this, wise journeymen also seek help often. They may be trusted with a great deal more responsibility and independence than an apprentice, but they have a better grasp of their limitations.

Masters have attained a level of competence such that they’re considered experts in their craft. So much so that they’re sought out to solve the most difficult challenges (or practice the highest form of the craft) and to teach others how to do the same. Apprentices are assigned work, journeymen seek out work, and masters are sought out for work. Like wise journeymen, masters know that they lack much knowledge, for it is not possible for even a master to be an expert on all things. They are also more likely to have an in-depth understanding of their own strengths and weaknesses. Finally, in the efforts to improve their skill even beyond their current level often results in advances in the state of the art itself.

Naturally, there is no strict dividing line between the categories of mastery. The boundaries are grey, fuzzy, independent. It may be redrawn depending on the situation, need, or defining individual. In some sense the choice of three as the categories is arbitrary. There is perhaps no other good reason to use three other than simplicity. I myself find this level of categorization sufficiently descriptive as to be useful, yet simple enough to be used in evaluating my own mastery level.

At what level am I, then?

My job role is product manager, and I’m in charge of multiple products at my company. I am often in a situation of having the freedom to and being expected to act as a journeyman. On the other hand, I also look back with some regret on missteps that could have been avoided with a little precaution and guidance. Thus, I’m looking for a way to define myself such that I will be most likely to seek out help. A way that will promote openness to from my boss, and also from all those around me who have a unique perspective to offer. I think the most appropriate level for that is apprentice.

For the last few years I’ve been practicing my own form of product management. I’ve read, listened, accomplished, experienced much, each lesson cultivating my understanding and shaping my opinions and methods. Yet, I have far to go, and I still make the same mistakes from time to time. As an apprentice going on journeyman, it’s time to start putting the lessons to work. Time to stop making the same mistakes, time to start becoming more effective, and time to start organizing the path to achieving my goals.

I believe that product managers must possess and regularly utilize a very wide range of competencies in order to be successful. Most disciplines can benefit from strength in a multitude of competences. To product management, however, breadth is not just helpful, it is essential. Organizing and progressing on the skills and competencies necessary to achieve a mastery of product management is a major life project in-and-of-itself. Step one: I’m committing discovering what it takes, and documenting the Way.

Posted via email from Learning Product Management

Product management is a craft says Bob Corrigan, a sucessful product manager and author of the ack/nak blog. He said this on the February 2009 episode of the Product Management Pulse Podcast (PMPP), “The Craft of Product Management,” where I first heard it, and on a ack/nak post, “meditation: on mastery”.

Until recently, Bob claims, there were no product management focused programs at universities. Most product managers have achived their level of competency by learning product management skills from a mentor, traversing the road from apprentice, to journeyman, and finally to master. In his own words:

After some reflection, I think that product management follows the same apprentice-journeyman-master training vector as medieval craftsmen, but without the benefit of any explicit structure, standard training, or agreed-upon criteria for evaluating mastery.

At the beginning of our careers, if we’re lucky, we find a “master” who is generous and patient – even if the products we do our learning on are neither. Everything is a live-fire exercise in product management. All the more reason why having someone to show you the ropes is so essential. Book-learnin’ just won’t do.

This speaks some truth.

I myself did not undergo formal training in product management. While I did take a handful of management classes while an undergrad studying computer science at UCLA, none of these classes were specifically focused on the art of building products loved by customers (and their pocketbooks). Instead, they focus on tactical matters such as project management, financing, accounting, leadership, and so on. These are important competencies in a product managers toolbelt, but they do not constitute the core of what a product manager does.

Much of the learning, then, comes on the job. As Bob aptly said, it’s a live-fire exercise. The cost of failure is real money, and lost opportunity. To an apprentice like myself, guidance from someone who has been through it all before can be a huge help.

If you work at any level other than the top of a large, well-established company, you probably do have a mentor. You may not like it, you may call them by another name, or you may conciously choose not to treat it as such, but the relationship undoubtably exists. This is because, larger companies are more risk adverse, and less likely to let a rookie take the ropes without guidance (read oversight).

To some this can be reassuring. To others it is midly restrictive. To others still it is nothing short of bureaucratic in the worst sense of the word. Whatever your outlook, heeding the advice of veteran can help you avoid blunders. If that person has been with the company longer than you, it can also serve to better integrate you into the culture of the company. Furthermore, the resouce pool at a large company can be expansive, allowing you draw from multiple sources or seek a different mentor if the need arises.

If you’re the founder of a bootstrapping startup, you may find that you have no mentor other than your own experientially built repertoire. Unless you are unusually gifted, keeping this repetroire growing healthily each day is an important factor to achiving success. Fortunately today you have an advantage. The ability to seek and connect with mentors virtually is easier than ever before. While you should be careful not to believe everything you read from unknowns like me, a little reserach and good judgement will go a long way. If you’re betting your life savings on your venture, then by all means seek all the help you can get!

If neither of these categories applies to you, you’re probably somewhere in-between. Perhaps, like me, you work for a small company with a founder CEO. Your company has enough road behind it to be proven, but may now be experiencing growing pains while attempting to transform itself from a one hit product wonder to a sustainable product-line execution machine. From a team small enough that everyone knows one another’s names, to a headquartered, multi-office mega-player. A mentor can be extremely beneficial to a product manager entering this fray.

A budding product manager in a small but growing company will be called upon to put in establish new processes and procedures, and make decisions on matters that are outside of their experience, level of competence, or comfort zone. Making do is part of the game, no time to dwell on the inconsequential. It comes with the territory—resources will always come up short of the need.

Even the most talented individuals will make mistakes under these conditions. What’s more, your output may seem sound, and the mistake may not be apparent until it is too late. While mistakes are a powerful motivator to learn and improve, they are not the only way. Fortunately for you, my friend, you probably have great resources right under your nose. The founder or founders that went through it all while launching the product that brought the company to its current level of success, and they are probably more than willing, nay, eager to help you.

Seeking support from founding individuals serves dual purposes.

First, since they are the founders and probably own at least the majority stake in the company, they have a strong interest in keeping things moving in a positive direction. However, te company has grown to a point where a few individuals (themselves included) cannot control, keep tabs on, and decide everything. This is terrifying to them. You must accept their input, but by taking it one step further to actively seek it out regularly and frequently, you make it easier for them to let go of this control and get past their anxiety.

Second, it greatly decreases the chance of you making a mistake. At this stage of your companies growth, some mistakes that are way to easy to make can have detrimental effects. They cripple your growth or even send you back to the to the starting line. Call it CYA if you would like, but I wouldn’t want to be the one responsbile for that simply because I was too proud to ask for help from those around me with more experience.