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.