Mortal PM Sins - Part 1

Let's face it: product managers are some of the busiest people on the planet. Perhaps more than many other disciplines, we can be lulled into a sense of false security or even apathy that subtly puts us on the road to failure. We've all heard that a relatively high percentage of products and product development efforts fail. We as a community talk far less about failing as a product manager -- I'm not convinced it's any less common. Here's a list of mistakes that will almost certainly catch up with even the most talented product managers, putting them in an unwinnable situation before they're even aware they've made them. This post isn't about other product managers. It's about you.

Not managing all your critical stakeholders
I've mentioned it multiple times on this blog, but while it's easy to become enamored of the idea of delighting customers, they are only one constituency that influences your success. Not managing critical internal stakeholders, for example, may mean you don't get the budget you need to please your end customers, a mistake that can put you in an unrecoverable position with just one release.

Ignoring disruptive change instead of embracing it
We live in times of change. If you're product is sold directly to consumers as a service, you're probably aware of the rate of change around you and, if you're successful, are continuously adapting to it. Folks working in problem domains that are less dynamic, solving complex problems for enterprises, for example, have a bit more time to contemplate change, at times deluding themselves into thinking it doesn't apply to them. Are you thinking of Blackberry? I am. Really disruptive change may mean your product becomes irrelevant. Sometimes, being one of the first to acknowledge this fact and being one of the architects of the transition to the "new order" is a much better option than digging your heals in or sticking your head in the sand. For many reasons, this can be one of the most difficult mortal sins to resist.

Not knowing when it's time to move on
No one likes to talk about it, but the best of us can find ourselves in a situation that is simply unwinnable. There are obstacles that cannot be overcome with a positive attitude or any amount of hard work. Realizing you're in such a situation and transitioning out of it on your terms has implication not just for your job, but for your career. Here are a few factors that can indicated it's time to move on:

• You might find yourself babysitting one of the portfolio's "dogs", while other product managers are leading the strategic charge
• Other disciplines such as engineering may have been empowered to the point that, truth be told, they are driving the vision and roadmap
• You may have simply lost your passion for the problem space or the product itself. If you're not proud of the product you're shipping, it's time to find a more productive use of your time.

Not being a master user of your product
It seems counter-intuitive, but you can be a functioning product manager for years without really knowing how to use your product end-to-end. Sure, you can do the demos and with a combination of experience, limited knowledge and quick thinking can talk the talk, but if you really don't know all the obscure corners of your product and tend to get lost off the beaten path, there's a good chance folks like engineers and pre-sales don't respect you as much as they might and that there are functional aspects of the product you're not shaping the way you should.

I hope this give you food for thought. I have several more mortal sins I'll share in an upcoming post.

Have you made these mistakes? Are you making them now? What mortal mistakes have you or other made?

Find more information about my online training course on my site.

Gentle Reminder Product Managers: Mind Your Network!

Not sure what's going on, but I've been pinged regularly in the last couple of weeks by folks either looking to fill PM positions or PMs looking for their next challenge. There's a single word that leaps to mind during all these conversations: network. For such a self-evident message, I'm fascinated at how few people actively manage their professional network. Here's the thing: You can't create a network in short order when you need it. It's like a hardwood tree -- you have to plant it, care for it and let it grow slowly if you expect it to be strong.

This message is particularly relevant to folks who have "perm" positions (as opposed to those of use chasing down business for our services business). It's easy to get complacent and wonder why you would try to meet people on LinkedIn when you see essentially the same faces every day. I am certainly guilty of not leveraging social media to enhance my network when I was employed. I'd like to think that I've made up for lost time, but the inescapable fact is that my network would be even bigger if I'd been dedicated the time and effort to it that it deserves. On multiple occasions, I've heard from long-time employees who are surprised to find themselves looking for a job and realizing that they had been "asleep" for years with respect to the professional network. Don't be one of these people!

If you're not sure what to do to create, groom and retain your professional network, have a look at one of my previous posts. In this post, I would suggest the following to help you grow your network through social media.

• Consider starting a blog. The more specialized the better. Try to write a one-page post every month (that's probably the minimum you need to create a "fan base"). There are tons of free platforms (like Blogger).
• Start connecting with folks on LinkedIn. I'm not talking about building a network of farmers, perfume salespeople and rocket scientists. I'm talking about finding other professionals working on similar topics or in similar companies and sending them a request to connect. If they are hesitant because they don't know you, simply say "I find it valuable to network with people who have professional interests similar to mine."
• Join relevant groups on LinkedIn and participate. Like interesting posts and every once in a while share something you've stumbled across.
• Consider using Twitter. Tweet interesting tidbits related to your work a couple of times a day. With tools like TweetDeck, you can even schedule Tweets weeks in advance.
• Use all your social networking channels to promote your blog (just point people to new posts)
• Set up Google Alerts for topics that are relevant to your work. I get TONS of great information delivered daily to a dedicated e-mail folder. These alerts are the source of most of my posts on social media.

I hope this post encourages you to be more diligent about growing and maintaining your professional network. A tiny bit of effort now can make all the difference in the world when you need it.

For more information on me and my offerings, please visit http://www.prickril.com.

BTW, if you're looking for a PM position or trying to hire a PM and having a tough time, feel free to hit me up. I've got a lot of unconnected people in my network lately!

The "New PM" Test

As a product management consultant, I've spent a fair amount of time trying to get myself up to speed on what an organization's goals and plans are, not to mention understanding what their products do and how they build them. When teaching or consulting on product manager, I encourage individuals and organizations to document their offerings and intent in a way that a new person to the team could get a nice overview in half a day. It's what I call the "New PM Test". In my experience, a new person joining the team exposes all kinds of organizational "weaknesses" in terms of sufficiently documenting their offerings and practices. Here are a few thoughts:

• Create a strategy document with a 10 page/slide summary that explains where you are, where you want to go and how you'll measure success. You should document insights about the markets you serve and alternatives available to your customers, especially competitors. It's also important to give some insight into financial measures.

• You should have a functional description of your product, including whom it serves, what it does and what the key moving pieces are (marketecture). It should describe important stakeholders, including the people who buy and those who use it (who, in the B2B space, are often different). This document isn't a user manual; it doesn't have to describe every feature and function, just the most important ones. A few screenshots can really help the reader picture how your product works.

• For complex products, you should have internal training available. Sometimes you can leverage training that's been developed for customers or sales people. New people in your organization should take the training as quickly as possible so they deepen their understanding of your products function, strengths and weaknesses. Too often we "hit the beach" at a new job and put of these seemingly time-consuming activities.

• You should have a release plan document (word processing or presentation) that describes the planned scope, resources involved and the schedule. It should identify key roles and provide their contact information. I'm not talking about a huge Project file here; I'm recommending a document that in less than 15 pages provides someone like a new PM a solid overview of the current release.

• You should create and maintain a SWOT analysis of your product. It helps keep you honest about areas for improvement and can remind you to invest in the opportunities you've identified. SWOTs for your strongest competitors can also be invaluable.

If you already have these artifacts and a functioning practice for keeping them current, congratulations! If not, get busy. A practice I've used successfully in the past is to put new people in charge of updating the material and finding gaps in "coverage" (information that would help them ascend the learning curve quickly and get productive).

Please visit my site for more information on my product management consulting and training offerings (including an online course with certification).

How to win engineering hearts and minds as a product manager

Influencing engineering is a critical skill for product managers in the tech field. It should come as no surprise that being influential is much easier when you are respected and liked. A question that new (maybe all?) product managers must ask themselves is how they can develop credibility with the technicians they depend on to implement their product ideas. In this post, I'd like to talk about the basis for influence itself and share a few ideas on how you can "win the hearts and minds" of your development counterparts and enjoy a more productive relationship with them.

Firstly, it's interesting to think how we influence people in general. Psychologists French and Raven developed a model describing the "bases" of power, which they define as the ability to influence people. Although a full description of their model is beyond the scope of this post, their concept of "referent" power most closely approximates the relationship of PM to development. Referent power is based on relationships and perceptions rather than the ability to directly reward or punish others. Here's some food for thought on how you can increase your referent power and thus your influence on engineering:

1. Providing External Insight

You should ask yourself if development sees you as a key source of not just information about customers and markets, but real, meaningful insight. Notice that I make a distinction between customers, who in this context refer to people or organizations that have purchased your product, and markets, a much broader group of people who have the means and potential interest in purchasing your product but haven't yet taken the plunge. It is market insight that is often sorely missing on product teams. To derive this insight, you need to collect information directly and indirectly and carefully analyze it, adjusting the way you communicate your findings to the audience you're sharing it with. Here are a few things you can do to communicate the insight you've gained:

• Take extensive notes when you talk to external stakeholders like customers and present your findings to the development team.
• You should probably have a periodic, standing slot in the dev "all hands" so that the entire organization sees you from time to time.
• Try to always take someone from development with you when you meet with customers. They deserve direct exposure to the folks they ultimately serve and the time together can strengthen your relationship with them.

2. Defining and Driving Strategy

Have you documented an explicit, compelling product strategy incorporating input from all relevant stakeholders (including engineering) and reviewed the final product with them, assuring they buy in? As I've said before, roadmaps are important but are not a strategy. To define a strategy, I like the concepts defined in OMG's Business Motivation Model spec. Define a comprehensive business motivation model for your product and share the highlights with engineering on a regular basis, including progress against measurable objectives. Some folks might tell you that development doesn't care about business metrics, but I that has literally never been the case in my experience. Developers want to know that their work is generating value for the company.

3. Understanding Technology

In the tech world, especially with respect to software, being the "business person" who doesn't take time to learn technology can make you highly susceptible to the whims of development and will do little to increase your influence. Having a reasonable understanding of the latest technologies, development models et. allows you to talk to development in their language and demonstrate you're not a clueless "suit". Staying on top of technological developments even at a shallow depth is work that never ends. Here are a few tips that can help:

• Stay abreast of what development is doing and the technology and tools they're evaluating. Learn from them to the extent you can and do your own research.
• Make time to browse technology periodicals and blogs and do some Googling on new terms and concepts you come across.
• Try to read a few books a year that are more technology than business focused. Books on new and improved development methodologies count as technical literature.

4. Networking

You need to invest time in getting to know the development organization. That means casual coffees, lunches and even "off-campus" activities with developers, architects and quality professionals at all levels of the organization. Overlooking relationships with individual contributor-level development is a common mistake. These folks are the future of your development organization and can often provide "unspun" information on what's really going on with engineering. Their insight into new trends and their enthusiasm can be educational and inspiring.

5. Demonstrating Empathy

Nothing helps build relationships and trust like genuine empathy. If you've never been in development yourself, you'll need to spend time with developers, almost treating them like customers in the sense that you need to understand and have some compassion for their challenges. Understanding that developers are people who make mistakes even when they're trying their hardest can help prevent anger and frustration when they have unpopular news to share.

What are your experiences? How do you increase your influence with development? Have you ever failed to win development's "hearts and minds"?

Learn more about my software product management consulting and training offerings on my site.

From Managing Tech

http://managingtechcartoon.blogspot.de/2016/09/ive-talked-to-customers.html

Recruiting (from Managing Tech)

http://managingtechcartoon.blogspot.de/

Managing Tech: The Dark Side of Social Media

http://managingtechcartoon.blogspot.de/

Biggest Mistakes Orgs Make When Establishing Product Management

Those in my homeland (USA) and from other mature software markets may find it difficult to believe that product management isn't well established in some corners of the world. I now live in Central Europe and can tell you with some authority that product management here ain't what it is back West. Many organizations in these markets are faced with the daunting task of implementing an effective product management function from near scratch. It may be a bit more intuitive to those of us that came up in mature software shops to consider startups that must make the transition from founder-led product definition to proper product management. Regardless of the motive, I've seen multiple organizations attempt to implement product management and have seen plenty of missteps and outright failures. Here are the biggest mistakes I've seen:

Assuming a good technician will be a good product manager
For a variety of reasons, including tight budgets and pressing deadlines, the typical shortlist of candidates for conversion to product management comes from development. What many organizations fail to realize is that just because someone shows impressive leadership in a technical role DOES NOT mean they will make a great product manager. I think about roles in product development in terms of functional and technical perspectives. The former considers products outside-in, the way customers see them; the latter is all about implementation. One of the most difficult transitions that technicians must make when becoming product managers is acknowledging this difference and developing the reflex to let go of the obsession on implementation ("the how") and think deeply about "the why" and "the what".

Not giving PM sufficient autonomy
To create sustainable success, product development organizations must develop a healthy balance between the functional and technical perspectives I just mentioned. Essentially, product managers must be free to reason over what the market needs without unduly constraining themselves with technical viability; this is the basis for much technical innovation. Creating a product management organization and having it report directly to development leaders will, in most cases, compromise this delicate balance, resulting in a technology-led rather than a market-led product development organization. If you decide a dedicated PM organization is worthwhile, give it the autonomy in needs to effectively advocate for the product's stakeholders, including customers. Otherwise, you will create an odd class of custodians instead of true business leaders.

Not setting reasonable expectations across the organization
Product management is an inherently hard job. If that statement doesn't resonate with you, I'm unlikely to be able to convince you of this fact in a blog post. The associated complexity and nuance mean that it takes time for product managers to "find their legs" so they can have maximum impact. During the early phase of establishing the role, product management will need "air cover" from leadership and a bit of understanding and even compassion from the multitude of organizational functions who will come to rely on them. As with any new initiative, it can be tempting to oversell the short-term benefits of establishing product management, setting this team up for failure. Leadership and product managers themselves need to set realistic expectations regarding what they can deliver. The obvious goal should be to continuously improve until PM adds the value its stakeholders expect.

Confusing Product Ownership with Product Management
I've written on this topic before so I'll avoid belaboring it. Product ownership is a role defined as part of Scrum. The Scrum Guide dedicates fewer than 250 words to its description. Product management is a discipline that is decades old and is not methodology-specific. At scale, you'll likely need people in both roles.

Assuming PMs can learn everything on the job in the lab
Product managers need to get out of the lab to develop into mature professionals. They should be spending time with customers, attending training and seminars and engaging with communities. Failure to make these investments will result in PMs that lack the external perspective they need to be effective.

Not inviting an external perspective
Organizations creating or empowering product management can often benefit by consulting someone outside the organization that is familiar with this transition and its pitfalls. This isn't a plug for a long engagement with a high-priced consultant, but a bit of coaching and guidance can easily pay off in the long run.

Have you experienced "the birth" of PM in an organization? What was your experience?

You can learn more about me and how I help organizations with software product management at prickril.com.

Managing Tech: Prioritization Tools

http://managingtechcartoon.blogspot.de/2016/07/prioritization-tools.html

Value: A trickier concept than it seems...

I really enjoyed Ellen Gottesdiener's recent post on value. Although we throw that term around a lot in the product management community, it remains a bit of a tricky concept for many. The key problem is that the value we perceive is often different that the value our customers' realize. Here are a few examples I refer to in my product management classes. I'm not sure about the veracity of the Concorde example, but I find it illustrative regardless.

Examples:

• A survey revealed that people wanted to buy milkshakes in the morning instead of traditional breakfast items because they last longer, keeping them occupied during their commute. [value beyond taste]
• A survey of Concorde passengers revealed that they thought their tickets were much more expensive than they actually were. Response? Raise prices! [greater perception of value than airline assumed]
• Have you ever realized that the time it takes for the waiter to deliver your meal doesn't necessarily go up if the delay goes down? How does it make you feel to have a meal delivered to you just minutes after you order it (we're talking sit-down situation or room service here)? [Some KPIs generate negative value beyond a certain point]
• Many customers value a relationship with a big vendor over superior features and functions from smaller vendors. Frustrating for the "little guy", but true in my experience. [features/functions not as important as security]

Have you thought about what customers really value in your products (or how much they value it)? It may not be what you're thinking.

The trick to discovering customer value is actually talking to customers about value beyond what you typically perceive as valuable. It helps us develop empathy, something for which there is no true substitute. We have a tendency to talk about features and functions (which makes sense), to the detriment of deeper understanding of their problems and perceptions. Although customers use our products' features, they base their perceptions on a broader "customer experience". Are you on top of it?

In a previous post, I suggested a few creative questions you can ask your customers to better educate yourself. Doing a little reading on customer experience is also a good idea.

What are your experiences with customer value? What were your biggest surprises?

For more information on my consulting and training offerings, including a complete online software product management course, please see my site.

PM Hell

http://managingtechcartoon.blogspot.de/2016/06/pm-hell.html

Questioning Product Management Training

As someone who offers software product management courses (along with consulting and other services), I realize this post may seem a bit self-serving. Regardless, I'd like to address a few questions and even misconceptions I encounter frequently on social media and in person on this topic.

Q: Can PM training help me if I'm an experienced product manager?

A: Sometimes phrased as "Is training just for newbees?". I would say about 80% of my "foundation-level" students have at least 3 years of product management experience. Some have considerably more. What I've found is that many of them "fell into" the role without any formal training or even organizational norms to guide their work and professional development. The value of getting an end-to-end perspective exploring those areas of the profession many organizations overlook or undervalue cannot be overstated. It's extremely gratifying as an educator to see virtual light bulbs ascending above people's heads as disjointed bits and pieces from their knowledge and experience come together into a coherent picture.

 Q: Is the value of the course in the content, e.g., slides, templates examples?

A: Although I (obviously) believe the content of my courses is valuable, the most consistent feedback I get from participants is that even greater value comes from:

My sharing my real world experiences
Meeting other product managers and getting insight into how other organizations operate.
These are a couple of things you simply can't get from a book or blog or by working a million years in the lab. As product managers, we can get so wrapped up in operational demands that we don't network enough. That means we're not learning from more experienced people or improving our performance based on other organizations' experiences. Meeting others who have similar ambitions and face similar challenges can be an enlightening and invigorating experience. BTW, some of my stories are as entertaining as they are painful. :)

 A: Can PM training help me in my startup?

Product managers' core competency is turning ideas into viable product businesses. Is that relevant to you as an entrepreneur? Probably. There are a host of other skills you'll need to be a successful entrepreneur, but spending a few days learning the basics of conceiving and delivering products will give you insight that might help you avoid all-too-common, fundamental errors that hobble many startups.

I've had multiple entrepreneurs take my course and I've always been impressed with the quantity of notes they take! Their direct feedback has convinced me that the limited time they spent in the classroom was highly valuable.

Q: Will training make me an effective product manager?

 A: Although most people wouldn't take this question seriously, I hear and read people reminding others that training can't make you a world class PM. What a revelation! Some folks grasp of the obvious is most impressive. If years of medical school can't make you a great doctor (you also need talent and experience), then a few days in a PM course aren't going to radically change your competency. However, training can give you an end-to-end perspective and insights into practices that you can extend on the job to make a significant, positive change in your performance as a PM.

Q: Is training as valuable as an MBA?

A: While I hesitate to address such a ridiculous questions, I have heard people make such comparisons. Most PM course are a few days and cost a couple thousand Euros (give or take). Even thought this is a drop in the bucket compared to the investment in an MBA, there are things PM training can deliver that you won't get in most (any?) MBA program. A few days of laser focus on the PM topic is in no way a substitute for an MBA, but can still be highly valuable and give you perspective and information you won't get from a more generalized approach"on campus".

So what are your experiences with PM training? Do any of these points resonate?

For more information on my training (including distance learning!) and consulting offerings, please see http://www.prickril.com

Capturing the lighter side of software product development

http://managingtechcartoon.blogspot.de/2016/06/managing-requirements.html

Software Leaders: 4 Reasons Your Next Big, Transformative Initiative is Going to FAIL

I've spent my career in ENORMOUS software shops so have suffered through more than my fair share of failed initiatives to fix long lists of ailments, real or perceived, ranging from lack of productivity to lack of agility to lack of customer focus, to, well, there was no lack of things that were lacking. Having spent a great deal of time lately researching the transformative process of scaling Agile and even attending training on the subject (I'm now a certified SAFe Program Consultant), a rush of unpleasant memories assailed me, compelling me to take pen to paper (literally) and create a list of the biggest causes for failure of these initiatives that I've experienced.

Here are my top 4 reasons why your next big transformative initiative will in all likelihood fail (and by fail, I mean fail miserably). Being a perennial candle-lighter and an undiagnosed sufferer of Don Quixotism, I'll offer a few tips from my perspective on what you can do to begin overcoming these challenges.

1. Your organization lacks leadership
Since the dawn of civilization and probably before, we as a species have confused achieving positions of power with the ability to lead. If I ask a group of managers at most organizations how many of them are poor leaders, it is unlikely, for a variety of reasons, that many or any of them would raise their hand. In my experience, this phenomenon isn't just a product of peer pressure: most people who have the word "manager" in their title or job description believe that, after a transition period lasting between 2 minutes to 2 months, they magically become good leaders. I've got some unsettling news for all organizations: About half your managers are below average leaders. If we were to assess them based on a less relative scale, I'm sure the percentage of good leaders in most organizations would not cross 20% (and I believe I'm being generous.). When pressed for proof that they are actually good leaders, most of these folks will, at best, point to  the results they've achieved. Good for them. Mussolini made the trains run on time but, oddly, is rarely quoted in books and articles I read on good management practices.

My silver bullet for bursting managers' self-inflated bubble is to ask when the last time the people who reported to them were given an opportunity to anonymously rate their leadership ability. I've worked for organizations that regularly did 360 reviews; I've never seen any other practice that had such a profound effect on behavior. Are you providing your leaders with this critical reality check?

2. You're not prepared for the inevitable dip in forward velocity
So you read the book, took the seminar and drank deeply of the newfangled panacea's Kool-aid, convincing yourself in your boundless excitement that it is the solution to a myriad of problems. Your new framework or approach or methodology is almost certainly going to increase productivity and customer satisfaction while decreasing defects and time to market (all while finally giving you the visibility as the visionary you always knew you were). Although not too many people like to talk about it and, at best it appears in the footnotes of outrageously misrepresented and self-serving case studies, when you make big changes, you can bet there is going to be a non-trivial period of time during which all the things you're trying to fix will actually get worse! That's right, your folks'  productivity will go through the floor and their flagging morale  may drop while their cynicism, honed to razor sharpness by bearing witness to the plethora of previously failed initiatives, will spike.  Instead of lightning speed to market, your products may languish in a no-man's land of confusion and general inefficiency. It is in this valley of despair that most organizations will abandon the new approach or hobble it lethally by reverting to previous, safe practices, however suboptimal.

To avoid this type of painful, embarrassing setback, you should prepare yourself for a temporary drop in productivity and set expectations appropriately. Having a clear set of KPIs and associated decision points can also help avoid giving up too early or, even worse, too late.

3. You haven't defined the metrics by which you'll measure success (and don't have a baseline anyway)
As I mentioned in the previous section, having a clear way to measure success is critical. While this seems self-evident, many initiatives hope to improve slippery measures such as "productivity", a metric for which most organizations have no reasonable baseline nor definition. Before you launch your initiative, determine what specific impact you expect it to have, define related KPIs and make sure you can actually measure them. KPIs that have a baseline in the organization are (obviously) more valuable.

4. You think improving engineering's performance is enough
No one will argue that engineering (development) is an important part of the equation when it comes to getting great software out the door. This (and the fact that many software leaders started in development) makes this function a logical target for improvement initiatives. However, without the right processes for defining what they should build, generating demand for it and finally selling it, development and its work product are, in most cases, useless (actually, worse than useless as they consume massive amounts of resources). If you're exploring Agile, you need to think deeply about how eventually increased velocity will impact the folks up- and downstream of development. Adopting SaaS and want to deliver new features weekly? Make sure marketing, sales and support can keep up.

To avoid local optimization in the product delivery value chain, think about the end-to-end process and make sure to include the key contributors to your products' success.

Conclusion

There you go. These are the top 4 reasons behind the most spectacular "new initiative" failures I've witnessed first-hand. What are yours? Have you experienced these issues too?

For more information on my software product management consulting and training services, please visit my site: http://www.prickril.com

6 non-obvious things you should do before building a roadmap

I consider the product roadmap an absolutely critical, strategic artifact. I further believe that product management must be in the driver's seat relative to its definition and communication. Here are a few steps I often see overlooked when PMs find themselves creating or updating a product roadmap.

1. Define a Business Motivation Model at the appropriate level of abstraction
Your roadmap should demonstrate how you will deliver offerings to the market that achieve your business objectives and move your organization toward its vision. I've blogged previously about the Object Management Group's Business Motivation Model as a great approach to defining key motivational concepts like vision, mission and goals and driving alignment on the team as to their meanings and the relationships between them. It's impossible to assess if your roadmap is helping you achieve business objectives if you haven't defined them. As a product manager, it is your accountability to define business motivation at the product level and align it with those at the business unit and company levels as appropriate.

2. Identify market and customer segments
Market segments represent groups of consumers (whether consumer or B2B) who share common requirements or prioritization thereof. In my experience, all product markets can be divided into segments. Although a critical input to planning, many product managers have insufficient understanding of relevant market segments both from a needs and business impact perspective. This lack of understanding make release investment prioritization sub-optimal, bordering on randomness at times. You might even consider a version of the roadmap that groups investment by segments (typically for internal consumption).

Customer segments are like market segments but represents groups of customers you've already done business with. Because you typically have deeper knowledge of them, further segmentation is possible and may be valuable. For example, it's nice to know what characteristics of existing customers make them most likely to upgrade immediately to new versions.

3. Assess investments in terms of their ability to delight customers
Prioritizing the requirements we'll satisfy and in turn the features we'll develop is a key competency of successful product managers. Due to a variety of factors such as late entry to market or leftovers from a previous release, our high priority investments may be of little direct customer value or simply boring. Tools like the Kano Model can help you categorize your investments to ensure you'll deliver something exciting enough to include in the press release.

4. Perform Formal Stakeholder Analysis
Although we canonically think of the roadmap as an artifact for communication of our intent to customers, it actually represents, sometimes indirectly, commitments we must deliver to a broader range of stakeholders like executive leadership and other product groups in the company. Stakeholder analysis is the process of identifying your stakeholders and what they expect from your product. An important part of stakeholder analysis is prioritizing stakeholders with respect to their influence on your success. Take a look at the interest-influence matrix for guidance on doing this prioritization.

5. Define Key Roadmap Consumers
Once you've defined and prioritized stakeholders "all up", you need to ponder which types of stakeholders will be most interested in your roadmap. When different stakeholders have significantly different interests in your product, you should consider creating multiple versions of the roadmap to highlight the elements that are most interesting to each. In my career, we've always had at least three versions of the roadmap:

• one for the core product development team that reflected reality (including all "warts")
• a roadmap for executive leadership, often highlighting integration with other parts of the portfolio and, truth be told, showing only the warts we wanted them to see
• the typical roadmap for customers, which was typically higher level and showed almost no warts.

BTW, don't forget that your competitors are would-be consumers of your roadmap! Make sure you have the proper governance around these artifacts to ensure only the right audiences see them.

6. Create a roadmap roll-out plan
The roadmap is a critical artifact for many stakeholders. Planning how you will present it and to whom is an important activity that is often overlooked. I would suggest you share it with the development team, executive leadership and then external stakeholders like customers and partners. Other audiences you'll need to include in the plan are other product groups and other organizational functions like marketing and sales. BTW, these functions should be involved in developing the roadmap from the beginning.

So that's a quick list that actually represents quite a bit of work. What is your experience with preparing to create roadmaps?

For more information on my consulting and training offerings, please see my site: http://www.prickril.com

Product Managers and the No-win Situation

Last month I had a coaching session that, I must admit, brought back some rough memories. The "coachee", an experienced, competent product manager, was feeling un-empowered and frustrated and was looking for ways to increase his impact on the product he was managing. After suggesting options from both strategic and operational perspectives, it became clear that he had unsuccessfully tried all the approaches I suggested. Furthermore, he shared that he was caught between two important stakeholders with conflicting goals (addressing installed base vs. new customers). He then shared that many of the people with execution power relative to product development actively avoided any contact with customers. To make matters worse, these people had no customer empathy and weren't concerned that the organization was regularly failing to meet customer expectations (software wasn't making it out of the lab on time or at the level of expected quality).

This conversation reminded me of a time in my career when I had spent months fighting to make a difference in vain. The organization was a mess in terms of accountabilities, we had massive development execution problems and we were being stretched in too many directions in terms of requirements (many from internal stakeholders). I remember how over a weekend I finally came to the realization that I was simply in a no-win situation. We as professionals don't like to talk about it and product managers are especially resistant to throwing in the towel (as they should be). However, I've since realized that the ability to recognize a no-win situation and react accordingly is an important career skill.

There is no checklist for identifying a no-win situation as a PM. Here are some of the symptoms I've encountered:

• You're accountable for the product but completely un-empowered to set priorities
• Those who are making decisions about scope and priorities don't understand software development and/or the markets you serve
• Multiple organizations are vying to drive the product roadmap and the level of management above them is unable or unwilling to grant charter and/or resolve conflicts
• Product management is staffed by people who are simply unable to do the job (whether from an experience, knowledge or core competency perspective)
• Product development execution is consistently failing to deliver a quality product on time and no one is addressing the associated issues
• You are prevented from effectively engaging with customers, sometimes by the imposition of an intermediary or unfavorable "rules of engagement"

If your organization is suffering from 3 or more of these symptoms and repeated efforts on your part haven't yielded the results you expect, you need to do be honest with yourself about the likelihood of the environment changing sufficiently to give you a fair chance at success. It's important to note that I simply assume that most professionals are clever and, over time, will take reasonable steps to identify key challenges and attempt to address them. Making generalizations about how to handle the realization of your plight obviously isn't possible, but here are few thoughts that I hope help:

• Realize that some situations are simply so dysfunctional that no amount of heroic effort on your part can change the organization's prospects
• You are not alone nor the first person to face a no-win professional situation
• Accepting what is happening and making plans in a relevant timeframe can make a big difference in your career (not just your job)
• Your career is a marathon, not a sprint -- conserve your energy and passion appropriately

This is a tricky topic. As I said, product managers tend to be the last folks to accept that they can't overcome the challenges before them. While it's an uncomfortable predicament to find oneself in, losing years tilting at windmills only to ultimately fail and, even worse, be blamed for the failure is a much worse fate. On a hopefully more constructive note, here is what I consider a reasonable way to approach situations in which you don't have the influence you feel you need to realize your and the product's potential:

• Identify and analyze the key obstacles in your way (in priority order)
• Identify the minimum set of conditions that must change for you to be successful
• Make reasonable efforts to bring these obstacles to the attention of those who can help clear them and make a genuine effort to be part of the solution
• Continuously assess the realistic chances of your and the organization's overcoming these obstacles
• After honest reflection, plan accordingly, including finding an environment in which you can have greater impact (and ultimately be happier).

What's your experience? Have you found yourself in a no-win situation as a product manager?

You can discover more about my consulting and training offerings at prickril.com

Getting Strategic Marketing Input: A Product Manager's Challenge

I've run across as many approaches to marketing as organizations I've belonged to. While I've met some very impressive professionals and have seen stellar execution in terms of communication at the tactical level, I must admit I haven't had the same luck getting market-oriented strategic input from marketing. To be fair, I think this gap was due more to organization setup and motivation than the skills and knowledge of the professionals involved. Regardless, although I've never felt at all that I could/should rely completely on marketing for strategic insight, I've always been convinced getting some insight is a reasonable ask.

This quandary had lead me to think about what other expectations I can reasonably have of marketing from a strategic perspective. For example, I've also rarely gotten good insight on the competitive landscape. Once again, I don't expect marketing to serve me up a platter of perfect information: I expect to contribute to knowledge about competitors too -- I just expect something. Anything.

One might think that given my background in huge shops, a well oiled marketing machine would inundate me with market insights. Sadly, nothing could be further from the truth. One might expect these mature, fairly bureaucratic organizations would force marketing to at least go through motions of penning a marketing requirements document (MRD). Once again, one would be wrong in my case.

I'm very curious what others think are reasonable expectations of marketing in terms of strategic insight. Please don't respond with the obvious observation that we PMs are accountable for gathering this information. I have always accepted this accountability but couldn't help expecting a bit of support. Here's a short list of things I would have liked some relevant insight into:

• "Mega trends" shaping related markets
• Input on defining the market segments we should target
• Key functional trends in related products (new capabilities, for example)
• Key players in the competitive landscape
• Fodder for at least the OT dimensions of a SWOT analysis

What are your experiences? What strategic insight do you expect from marketing? What kind of insights have you gotten?

5 Smart and Creative Questions You Should Be Asking Your Customers

As product managers, we're expected to interact with customers but, in my experience, typically receive little formal training on how to do it right. While some folks are naturals at this type of communication and often it's not difficult to find topics to discuss, I have the impression that I could have or should have gotten more out of customer interactions during my career. On balance, I have to admit that much of what I discussed with customers was fairly tactical, e.g., specific issues they were facing, input on investments for the next release.

I did a quick thought exercise, trying to uncover more open, creative and even perhaps strategic questions that I either stumbled upon or wish I had stumbled upon earlier. Reviewing them now, they're probably biased toward the enterprise market where I spent most of my career. I hope they provide food for thought.

1. What would it take for you to switch to a competitor?

This question can be intimidating or scary to ask, but has the potential to give you insight into what really differentiates your product in the mind of the customer. Their response (much of it nonverbal) may also give you some insight into the extent to which they've already pondered this query.

2. How would you characterize the business value of using our product?

This question can give you important insight into how your customer quantifies or qualifies the value of your product. Do they make a strict business case or are there other intangibles that they find valuable? As PMs, it nice to see both. You can then ask yourself if the benefits/value they perceive are based on factors that are likely to be stable and long-lived. If not, you've got some thinking to do. These types of conversations can help you understand your product's value proposition and create effective positioning that resonates with other similar customers.

3. Can I watch some people using our product?

We sometimes are hesitant to make a request that we perceive as disruptive to our customers'  business, but simply watching people use your product "in the wild" will give you insights that won't come from an artificial environment like a lab and will help you understand the broader business/operational context in which your product is used. You may also get input from stakeholders that you don't normally speak to (end users as opposed to decision makers, for example).

4. What would be the immediate impact on your company if you couldn't use our product tomorrow?

The answer to this question can be humbling. If the answer is "not much", you've got some soul-searching to do. Regardless, this question can help you understand the criticality of your product to the customer and may help you better prioritize development investments, including the typically neglected "stepchildren" of feature prioritization, topics like supportability.

5. If you could change one thing about our business relationship, what would it be?
This question shows sensitivity to your customers' non-functional challenges and may give you insight into adoption blockers that are generally reserved for sales professionals. For on-premise products, you may get insight into the potential value of other delivery and pricing models. You can also get insight on price point or the licensing model that would probably never come up in discussions about the product's functionality.

For more information on my training (including online options) and consulting offerings, please visit my site, www.prickril.com.

Lies product managers tell themselves (Prickril Edition)

I enjoyed Mark Silver's post on the Spechtechular blog on the lies product managers tell themselves. Let's face it, product management is normally a grind. We shouldn't be too hard on ourselves if we tell ourselves a few white lies to help us "get through the night" from time to time. As some of us learned in "The Big Chill", rationalizations are more important than almost anything. ("When was the last time you went a week without a rationalization?").

Mark's post inspired me to do a bit so soul searching. Here are a few ugly and pernicious lies I can now admit I've told myself over the years:

1. I talk to customers all the time so I obviously understand them.

It's self-evident to most product managers that we should be talking to our customers. But let's face it, operational demands back at the lab and unfortunate constraints such as travel budget often make it difficult to engage with customers as often or as deeply as we'd like. This paucity of interaction with customers can create an exaggerated sense of value from the engagement we do have. That means sometimes we find ourselves actually believing that because we had some interaction with them that we really understand them. A few questions that can help us dispel this illusion:

• Think of a customer contact you have and list their top three professional pains (not necessarily related directly to your product).
• List the three biggest customer problems your product solves. This one leaves many an overconfident product manager scrambling for an answer when they're put on the spot.
• Are you talking to customers that are representative of important market segments or just the usual set of "groupies" (folks who love you and your product are perhaps too careful in giving you the feedback you need to radically improve your product).

2. Writing down a strategy is unnecessary because things around here change so often (and I've got a product roadmap!).

Good leaders will tell you that volatility is no excuse for not planning. Perhaps you need to tweak your planning horizon, but defining a vision and set of measurable, supporting objectives is critical and, moreover, one of your key accountabilities as a product manager! Be careful about falling into the trap that your vision and objectives are obvious to every one. You should also be wary if all your objectives are purely financial. Sustaining business success in the world of software will typically require more than short-term margin. Consider your reputation as a though-leader and your desired impact on the markets you serve. Shouldn't you define related objectives? BTW, your roadmap should be a delivery-centric expression of your strategy; it is not the strategy itself! Structurally, I like to define strategy using OMG's Business Motivation Model. This spec is, for the most part, undiscovered gold.

3. I'm extremely busy so I'm obviously getting a lot done.

Product managers are infamously busy people. I believe there are few (if any) other roles that stretch a person in so many different directions, e.g., functional vs. technical, tactical vs. strategic, inward- vs outward-facing. The shear volume and breadth of work means that we can easily delude ourselves into thinking that all this activity actually represents progress. Here's a simple exercise to help cut through "the fog of activity": Look at your calendar for the week and identify everything you're doing that has clear strategic importance. If you're not doing something strategic every day, consider reevaluating your priorities and asking yourself why your investments in your most important resource, time, are so tactical.

4. Everyone seems happy at the lab, so things must be going well for the product.

It's so easy for us to get lulled into a false sense of security during those sometimes rare periods of calm at the lab. Things are going swimmingly with development, executive leadership is happy with developments (or distracted with bigger priorities) and even the quality manager, who had been disrupting your sleep for months, seems content. It is at these times that successful product managers reflexively, even compulsively, assess what's going on "beyond the firewall" to make sure all this calm and contentedness is well-deserved. You should be asking yourself if you're getting regular, high quality information from the outside world about sales, customer satisfaction and other meaningful KPIs.

5. There are million reasons my product isn't performing like I expect it too, none of which have anything at all to do with my poor design, strategy or execution.

Much like a restaurant owner who can think of a million reasons why diners are scarce on a given evening ("There's an ice dancing special on TV tonight and Mars is in retrograde."), it is easy for us to surmise reasons why our product isn't performing at the level we expect. The hardest to accept is that we are simply not delivering what the market expects. This mismatch may be a product of simply not understanding the problem space sufficiently or failing to design the right solution. We might not have a strategy (see point 2 in this post) that is focusing our efforts on winning based on an explicit set of objectives we define. When your product is under-performing, focus you efforts on discovering why and addressing it, not concocting elaborate excuses and staying the same path. 

Lies Worthy of Honorable Mention

• My product offers enough functionality to really address my customers' pain.
• I'm clearly delivering what the market wants, not just what appeals to me.
• Every roadmap pitch I've ever made to execs. :)

So what do you think? What are the biggest lies you've told yourself over the years?

You can get more information on my consulting and training offerings on my site, www.prickril.com.

Lest we forget...

While it's clear that Agile can make you faster, make sure your efforts are guided by the right vision and strategy!

From Data to Wisdom

I've been looking for an intuitive way to make these distinctions for a long time. I think I'm on my way. 

The Role of Women in the Software Industry: A Global Disgrace

When it comes to gender equality, most industries, including (or maybe particularly) the software industry, have a lot of work to do. When we characterize the status quo from a statistical perspective, the current problem is daunting or even depressing:

• A recent study of 11 high-tech American companies revealed that only 30% of their workforce is women
• A relatively small percentage (of this already small percentage) of these jobs are technical (16%) or leadership roles (22%)
• Some data indicate that these numbers are getting worse, not better
• (for more information, see this great CNET article).

Anecdotally, most of us need do little more than look around the average conference room during a meeting to see an appalling representation of the gender gap. As a software product management trainer, my experience is that women only 15% of my students are women (something I'm committed to change going forward).

In this post, I'll share my perspective on this problem and suggest a way that organizations can frame the problem as an initial step in addressing this unfortunate situation. I'm not an expert on gender equality but am passionate about the problem and hope my (possibly naïve) observations will generate much-needed discussion.

Are men and women really different?
Although there is evidence that men and women have biological differences and are subject to the significant influence of culture, I make the assumption in this post that any gender-related differences, whether they are real or perceived, are essentially irrelevant to the discussion of gender equality in the workplace, i.e., I assert that men and women are equally capable of contributing positively to an organization's success at all levels of the organization. If you don't share this perspective, it is unlikely that the rest of this post will be persuasive or even meaningful.

What is the cost of gender inequality?
The value proposition of improving gender equality can be hard to determine in a scientific or objective manner, but a reasonable entry point to this discussion from my perspective is based on what I'll call "unrealized potential". The assertion that men and women are equally capable begs a critical question: "Can any organization afford to have an important voice underrepresented in realizing its potential?" I feel strongly that a key factor in determining the success of any enterprise is realizing the full potential of all its members, regardless of gender.

Addressing Gender Inequality
Although acknowledging that gender inequality exists and has an adverse impact on software organizations is an important first step, addressing this issue remains a difficult endeavor, replete with issues common to addressing other types of inequality, including age and race inequality. Given the best information I've been able to find, I simply acknowledge that gender equality is a real issue that has a significant, adverse impact on business success and thus, in practice, on our society as a whole. As a corollary, I would say that if gender inequality is impacting society as a whole, we are all stakeholders in its resolution regardless of our gender {or any other factor}). 

One way to consider how the gender gap could be addressed relates to the level in the organizational hierarchy at which change is planned and implemented. In this post, I'll address the genesis of this change from two perspectives: bottom-up and top-down.

Addressing Gender Inequality Bottom-up
Personal Commitment
I think the most important bottom-up driver for gender equality is awareness of the problem and a personal commitment from each of us to help eradicate it. This step takes some research, perhaps some training or professional guidance, and, most important, some introspection. We are all stakeholders in this problem and must each play a part in improving the situation.

Preparation
Women themselves can also play a part by taking advantage of opportunities to increase the leadership skills and strategic perspective. I believe that the role of product management can play an important role in preparing women for leadership roles given the breadth of knowledge required and the inherently strategic nature of this role.

I believe that product management is in a special position to address gender inequality as it provides an opportunity for developing leadership skills in women without immediately impacting an organization's explicit leadership roles. At the bottom of the post, I list how we product managers can help improve the situation.

Addressing Gender Inequality Top-down
Addressing gender inequality top-down means acknowledging that leadership's interpretation of the problem and its willingness to address it are absolutely critical. In short, organizational leadership must approach gender inequality with an open mind and accept multiple inconvenient truths.

Gathering the Data
A relatively straightforward step in addressing gender inequality lies in understanding via data the magnitude of the problem. Organizational leadership must define a reasonably simple model for measuring the participation of women in the organization. Gathering statistics on the number of women in the workforce and their representation in leadership roles is essential. The latter requires a fair and comprehensive definition of what constitutes leadership, whether measured by reporting relationships, accountability for business success such as influence on revenue. More nebulous measures such as overall influence on organizational decision-making might also be enlightening. If the data demonstrates that gender inequality exists, a likely outcome given generalized statistics, I believe there is a leadership imperative to address it.

Creating the right culture
Organizational leaders, in my opinion, have an obligation to create an organizational culture that acknowledges gender inequality as a problem and demonstrates a willingness to address it. Some organizations like Google are arranging workshops to increase awareness.

Proactive measures
In an attempt to address gender inequality, many organizations have embarked on programs to address it by setting gender-related goals. From the perspective of fairness, related policies can be controversial. While a comprehensive treatment of the desirability or efficacy of such programs is beyond the scope of this post, given the magnitude of the problem and its consequences, I applaud organizations that undertake such efforts. Organizational leadership is responsible for carefully considering such policies and, as appropriate, implementing them in a fair and transparent manner.

What can we as product managers do?
The good news is, we as product managers can help our industry address this problem. A few thoughts off the top of my head:

• As I said before, make a personal commitment to addressing the problem (or at least not contributing to it)
• Consider mentoring a woman interested in product management as a career path. I'm doing it and have found it rewarding.
• If you're in software organization leadership, put gender equality on the agenda and make it a priority
• If you interact with girls that are still school age (your daughters maybe), encourage them to pursue math and science or other technical fields
• If you're a product management trainer (I realize this is a small community), consider special programs that help address the (likely) gender gap in your courses. I'm in the process of doing this and couldn't be more excited about it!

I must admit writing this post made me unusually self-conscious. As I said before, I'm not an expert on the topic and have undoubtedly left out important aspects of the issue and its treatment. If this post encourages discussion on the topic, I'll consider it a great success.

Are you ready to address gender inequality in your organization? Are you already addressing it? Please share your experiences.