 Leadership is a frequent topic of discussion within the product management community. You won’t find much of a debate on the topic of whether product management is a leadership position, but you will find much discussion on the depth of the leadership. The discussion will span across whether product management should have people management responsibilities, whether they can be accountable for key performance indicators or just generally how to be a better leader.In a recent webinar , David Locke suggested he though the product manager role was more accurately as titled as Product Leader. Perhaps David can comment as to why he thinks this title might be more accurate. He discusses this in the webinar around the 44 minute mark. The product management leadership angst generally occurs when it appears like a lack of authority is blocking your plan. The reality is that your powers of influence are probably lacking. If you know me (actually maybe no one knows this), I love word definitions. I look up one word a day, mostly due the fact that I had a history of not reading very much. I am reading much more now. Anyway, here is how the Merriam-Webster Online Dictionary defines authority and influence. Actually they have a few different definitions for each word (of course they do), but I thought these were closer aligned to product management than the others.
From a product management perspective, I typically get nervous if you are managing a product and people. The people distract from the time that the product requires and not managing people will generally preclude you from the authoritative leadership you might be seeking. The power of influence is perhaps the most important tool in your professional toolkit. It should be a skill that you are constantly working to improve. It blends in a number of your personal traits including likability, compassion, empathy and understanding. But it also requires that you put the effort on your end to be able to justify anything you might need. People can be more easily led if you use market-, fact-or customer-based evidence for your requirements. I tell people that product management is 90% leadership and of that 100% will be by influence and supported by all your market sensing activities.
Again, I defer you to the two experts on the topic of product management and leadership: Image Source: Bonner Center for Service and Learning |
|
|
|
|
|
Entries from September 2009 ↓
Authority vs. Influence
September 24th, 2009 — Leadership, Product Management
Repost: Use Cases vs User Scenarios
September 21st, 2009 — Product Management
Finally, documented clarity around the difference between use cases and user scenarios. Let me summarize the difference. A use case is a step-by-step account of system behaviour associated with one or more actors. A user scenario is concrete description of a very specific interaction, but one that is chosen to be typical or representative. OK, now what does that mean? Use cases are very detailed and typically define the actors, a brief description, pre-conditions, the main flow (i.e. happy path) and any alternate flows, sub-flows and exception flows. It will also describe the state of the system at the end of each flow, happy or otherwise (i.e. post-condition). User scenarios are slightly more creative. They are typically narrative versus the bulleted / numbered form of a use case. They incorporate individual user characteristics (i.e. a persona) while outlining the tasks undertaken to achieve goals. Essentially, you tell a short story about your persona interactiing with your product. Product Managers will survey their external stakeholders, end users, customers and prospects to determine what the system will do and how it will be used. This is captured in the form of user scenarios, first informally, then expressed more formally in a use case model. At the end of the day, the differences are very minor but you can start to see how they are relevant and important to the software development process. |
|
|
|
|
If you enjoyed this post, please leave a comment or subscribe to the feed to receive future updates. You can also follow me on Twitter. Tell other people about this post. |
Responding to Change
September 15th, 2009 — Roadmaps, Strategy
 I swear I have written half a dozen posts in my head in the past week, either while driving or walking. I really need to learn to channel my inner Winston Churchill diction skills. Alas those ideas are lost for now.
Over the past month I have been mentally wrestling with change. Death, taxes and change are about the only things guaranteed. With respect to change, you can be guaranteed change will happen and will affect something. Change can and will come from market conditions, sales, marketing, customers, executives, support, engineering and many more sources. Change can and will affect everything including revenue, cost, project plans, feasibility, roadmaps and many more. As product mangers, every day you have to deal with change. Every day you have to deal with the effect of that change on your product. The successful product managers, the ones who cope with change the best, are the ones with a sound strategy that reduces the risk of change and/or enables them to respond to the change. Image Source: Center for Educational Technologies |
|
|
|
|
If you enjoyed this post, please leave a comment or subscribe to the feed to receive future updates. You can also follow me on Twitter. Tell other people about this post. |
Strategy versus Tactic
September 6th, 2009 — Strategy
 A lot of us live by the market-driven sword and after reading the following post: What is a “Market-Driven” Product?, I wondered, is ‘being market-driven’ a strategy or a tactic.My initial thought was that it couldn’t be a strategy because it is not really measurable. I suspected that as you tried to find a deeper meaning to why ‘being market-driven’ was labeled as a strategy you would find that it is not a strategy, but a means to a strategy. Therefore, it has to be a tactic if we base the criteria of strategy being the ‘what for’ and tactics being the ‘how’. How do we achieve our revenue targets? By being market-driven. Not so fast. Tactics are activities to achieve needed to achieve the objective – implement the strategy. Is ‘being market-driven’ really an activity? It feels a bit high-level and not really actionable. I posed the question, is ‘being market-driven’ a strategy or tactic, to the #prodmgmt community on twitter and one of the first responses (of many good responses) was from Adam Bullied who said it was a philosophy. Interesting. We know from other articles and experts that strategies are really in place to guide decisions. We also know that three of the main components of a strategy (or a set of strategies more likely) is the mission statement, vision statement and values. When Adam mentioned it was a philosophy, my immediate thought was ‘being market-driven’ is better defined as a mission statement. It seems like more of an overall goal that is accomplished (in this case, maybe never completed) over time as other (real) strategies are achieved. In the end, I believe that ‘being market-driven’ is more of guiding philosophy used to help shape strategies versus an actual strategy or tactic. It is a useful principle for us to put a decision-making framework in place, but not for making actual decisions. P.S. I found this – Strategy and Tactics By Eli Goldratt, Rami Goldratt, Eli Abramov – really interesting. This too – Strategic planning. Image Source: Austin Cotton Company |
|
|
|
|
If you enjoyed this post, please leave a comment or subscribe to the feed to receive future updates. You can also follow me on Twitter. Tell other people about this post. |
Repost: Searching: Product Management Architect
September 4th, 2009 — Product Management
Sorry, not a job posting… I am all theory here. In times when people are reducing staff and cost cutting, it would seem odd that I am about to highlight another required role. I want to highlight an article to support a problem that I am seeing in medium to large sized organizations. From Pragmatic Marketing: Software Product Architect Job Description
Consider this situation… Two product managers who are based in different offices, organizationally on separate teams and each own one product. Both products are typically bundled and used at a customer site and except for the rare integration scenario neither product manager collaborates with the other. Imagine if you will, each Product Manager receives a separate enhancement request from a different customer asking for the same thing. Separately, they each run through basic sensing techniques to determine the pervasiveness of problem and articulate the problem statement for their product. Awesome! Now what? They have documented a problem for their product that should potentially be solved in one and only one of products. The challenge at this point, how do they recognize that they are on the verge of writing requirements, getting estimates, passing it through various validation stages for the same problem, in essence duplicating effort? This becomes a bigger problem if the development team builds the solution twice. In practice, we want one of the product managers to identify a problem, document it and the other product manager to identify a problem and recognize that the problem already exists. Technology can help, at least you will have a central repository for searching, but still required is discipline to collaborate, strong writing skills to ensure they are communicating in the same language and responsibility to do the right thing (make the right decision). On the development side of the organization there is usually an architect type role that binds everything together, someone who is ultimately responsible that the technical designs are consistent and within the existing framework to ensure efficiency on the development side (no one is duplicating effort). I think the Product Management teams need this role too (or someone with this responsibility). I want to think of this as a Product Management Architect. This is someone who has overall responsibility for the quality of the problem statements, someone who is responsible for the best solution for those problem statements, someone who holds the big picture for the product portfolio and someone who has the potential customers in the front of their mind, not the technology. The simplicity of my scenario doesn’t really do the problem justice but if you start to think about a 15 member product management team that parses maybe thousands of inputs into hundreds of problem statements how pervasive this problem can be. At the end of the day, as technology providers, operation efficiency is paramount to our success and maybe even a differentiator. Duplicating effort is the opposite of efficiency. The market sensing and problem identification is the bread winner of product management and the key to efficiency begins at the point of problem statement concept. Last point, for the smaller groups I’d like to see you begin to have problem statement regular (weekly) review sessions on a regular basis. No harm can be done by reviewing the problems experienced by your customers. | |
|
|
|
If you enjoyed this post, please leave a comment or subscribe to the feed to receive future updates. You can also follow me on Twitter. Tell other people about this post. |
