What is the difference between a value proposition and positioning?

Help keep the social in social media

Your company's most important business process

The future of product management: Part 1

As a long-time product manager, I think it's only normal that I ponder the future of this fascinating discipline from time to time. I actually began this journey a few years ago when Prof. Dr. Alex Maedche and I wrote an article on the topic. Interestingly, we had trouble finding the right publication for the article. As far as I know, there are still no traditional publications, e.g., magazines, dedicated to PM (please correct me if I'm wrong).

In this post, I'd like to lay the foundation for this discussion by describing what I consider a fundamental challenge to our profession. I first need to describe an age-old paradigm for reasoning over almost any activity: the why, the what and the how. These dimensions are particularly important to the accountabilities associated with product development. "The why" describes our motivation for performing an activity. From a product development perspective, it encompasses questions like "What do we want to accomplish by developing the product?" and "What difference to we hope to make in the markets we serve?". "The what" refers to a functional (outside-in) description of the offering we'd like to take to market. For product managers, this means describing our product in enough detail that engineering can implement it (which we refer to as "the how").

Conventional wisdom holds that PM "owns" "the why" and "the what", with engineering carrying "the how" banner as previously noted. Herein lies the problem. It turns out that both "the why" and "the what" can be more than full-time jobs. The former involves defining the business motivation (strategy etc.), managing strategic relationships and doing business planning; the latter involves managing requirements, scoping releases and creating the roadmap. The following figure depicts these accountabilities graphically.

A natural question that follows from this paradigm is, "Would product teams be better served if there were independent disciplines accountable for each element?". I know this assertion will seem like heresy to many.

To repeat, the upshot of Part 1 of this series is that covering both "the why" and "the what" is a ton of work and, in practice, may stretch what is feasible for a single person. In my own experience, I found that at scale, much of the "driving" associated with the why was done by management while I was overwhelmed simply defining a product I thought the market would love.

What is your experience? Have you seen or been a victim of "why-what" overload?

Is product management art or science?

Are product managers confined to the problem space? PUH-lease...

Your approach to validation is broken

There's been tons of buzz about "validation" in the past several years. Lean and design-centric approaches such as Design Thinking encourage entrepreneurs to build things and incrementally validate them, correcting course as necessary. When I think about how, at the beginning of my career, we worked for months before validating anything, this increased focus on getting feedback from those who will use our product is most welcome. However, this obsession to validate what we build has, in practice, at least a couple of massive flaws that I'd like to highlight.

Firstly, I see almost exclusive focus on end users. While the people who directly use our products are important, the fact is that they are just one type of stakeholder. This point is a little less obvious in the Internet-based consumer space, where the user and economic buyer are the same and the buying process is much, much simpler than in the enterprise space. An individual consumer paying a couple of bucks for an app may (often?) make a decision based on little more than impulse. Those toiling away in the complex problem space where millions may be invested in a solution and with a fiduciary responsibility to stockholders tend to have buying processes that are dizzyingly complicated. We, as product managers must, therefore, validate ideas not just with end users, but with most or all stakeholders. Have we expressed our value proposition in a way that resonates with executive leadership? Do we have the right business model? Does our pricing model provide enterprise purchasing departments with the required financial flexibility? Overlooking these types of questions for these stakeholders may result in massive failure of a product that delights its end users.

Secondly, I find that most of what's written about validation focuses on the solution space. The idea is to build something quickly, test it, and "pivot" while it's still relatively cheap to do so. The problem is that we rush through our analysis of the problem space without validating that we clearly understand our stakeholders' key pains. Just like in solution validation, we rarely get it right on the first pass. Often, our understanding comes from anecdotal evidence ("I was talking to a customer the other day…") and flawed intuition. The first thing we should validate with stakeholders (not just users), is that we truly understand their problems. And here I'm not just talking about the problems we intend to solve. Understanding stakeholders' pain broadly helps us uncover acute pain we may have overlooked and helps put the problems we intend to solve in proper context. Laser-focused on our objectives, we begin to assume we are solving stakeholders' most critical problems although in many cases our solution, although important, is way, way down on our stakeholders' list of most pernicious issues. Before we even conceive of a solution (much less validate it), it is wise to validate our understanding of the problems that are holding our stakeholders back.

Problem validation entails the following steps:

1. Open, problem-oriented discussions with all important stakeholders
2. Distilling problems into a concise, consumable form
3. Validating our understanding of problems directly with stakeholders
4. Adapting our expression and understanding of problems as necessary

Just as fixing a prototype is far less expensive than fixing a shipping product, correcting misinterpretations of problems is much cheaper that reformulating a misguided solution, even as a prototype, later. I've blogged previously about the "Problem Profile", a valuable tool for considering problems holistically and validating them with stakeholders.

Your challenge is to resist the urge to validate too late, once you've already invested in the solution space. You will find that problem-centric analysis will yield insights that will never come from a solution-oriented approach.

What is your experience? Do you have practices in place to ensure you have a grasp of stakeholders' problems before you begin trying to conceive of and develop solutions?

You can read more about my strategic approach to product management on my site.

An interview on orchestration with yours truly...

Product Manager: Are you being DDoS'd?

There are lots of reasons that product managers aren't as effective as they could be. However, in my experience, the number one culprit by a huge margin is "operational overload". I usually describe it (somewhat euphemistically) as "lack of strategic execution" to my consulting clients. The syndrome is all too familiar to most of us: we're being pulled in so many directions by so many stakeholders that we become highly reactive and, truth be told, ineffectual. Eventually, we're left with the feeling of running on the proverbial hamster wheel. At the end of a long day or week, we're exhausted but not at all convinced that we've made the difference we hope for. When you're in the middle of it, this situation can feel like a distributed denial of service (DDoS) attack: so many requests for your "resources" that you can't serve anyone!

Symptoms

• > 50% of your calendar is overbooked
• > 60% of your time spent in meetings
• > 60% of overall meeting content seems irrelevant to you
• A high level of stress (this can be dangerous as some folks thrive on this feeling)
• A sinking feeling that bad things are happening but you don't even have time to analyze what's happening
• You are convinced you're letting others down professionally and feel helpless to change it

It's very easy to feel helpless in this situation and lose hope. You might be surprised however that consistently applying some simple approaches and techniques can make your more effective, lower your stress level and make you a much happier professional.

IT'S YOUR ACCOUNTABILITY TO GET ON TOP OF THE SITUATION! Here are a few tips:

Understand your motivation and how success will be measured!

Write down your goals and objectives and invest in activities that will help you achieve them. If you're not prioritizing your time, you're setting yourself up for failure.

Actively manage expectations

As a PM, you have many stakeholders. Make sure you set clear expectations with those who are most important and adjust them as necessary. People can be very forgiving of missed deadlines if they know they're coming. Always apologizing after the fact will quickly erode your credibility.

Analyze your agenda for strategic activity

Go through the appointments in your calendar for a week and mark those that represent strategic work. You might be surprised how much of your time is occupied by operational issues.

Let go of lower priority stuff

One of the traits I've seen in professionals I've admired over the years is a willingness to simply abandon activities that won't help them achieve their goals. See if you can delegate some of these activities to others for whom they may be a growth opportunity. Carefully assess the consequences, but you might be surprised how little practical impact there is from simply not doing some of the low-priority tasks that are on your plate.

In summary, we as product managers seem especially vulnerable to the DDoS. In my experience, there's no one else who will step up to save you. If you don't get on top of your time, a career as a PM can be a very long, unrewarding road.

Why do we keep confusing customers and markets?

As a product management consultant and educator, I continue to be surprised by the conflation of the terms "customer" and "market". As anyone who has taken any of my courses knows, these terms are not synonymous! Let's start with some simple definitions:

market: the entities with the interest and means to buy your product

The term "market" is an aggregate concept. It is all the entities, consumers, for example, who might be interested in your product (because they assume it will delight them or solve their problems) who also have the means (financial means, usually) to purchase your product. Understanding markets must be done by finding proxies; the market doesn't have the means to express its pains to you. From a product management perspective, you must infer requirements from the market.

customer: An entity that has bought your product

Customers represent the segment of the market that has purchased your product. It's worth noting that the term "customer" is an aggregate concept referring to a multitude of customer stakeholders, e.g., economic buyer, influencers, end users. You can actually talk to customers and they, unlike markets, are capable of expressing their requirements and other desires. Communicating with customers, while itself challenging at times, is a much more straight-forward affair than divining the desires of a market.

So where do I see folks getting confused? Well-known examples include the traditional Venn diagram showing that PM lies at the intersection of customers, technology, and business. I would say that substituting "markets" for "customers" in this diagram makes much more sense. The Business Model Canvas also seems to confuse them. It defines a building block called "Customer Segments", for example. While it may be beneficial to segment your customers, I would say segmenting markets makes a lot more sense when you're fleshing out a business model.

The third case of confusion is a bit more subtle. I've worked with companies with significant market share, i.e., their customers comprise a large percentage of their market. In these cases, it is common for product managers to engage deeply with their customers at the expense of gaining an understanding of the broader market. This tendency is understandable but can hinder growth beyond your customer base, generating a type of chasm for even mature products.

I would say inferring the desires of a market is one of a PMs most challenging tasks. Although you can always try to validate your hypothesis, markets are, by their nature, unpredictable and often full of surprises. My challenge to the PM community is to think deeply about the distinctions between these two concepts and, as importantly, to stop conflating or confusing them.

What do you think? Are my definitions inline with yours? Have you seen people confuse these terms?

UPDATE: Began reading Blank's "The Four Steps to the Epiphany" and it becomes a bit clearer how these concepts get confused: "Broadly speaking, Customer Discovery focuses on testing whether a company’s business model is correct, specifically focused on whether the product solves customer problems and needs (this match of product features and customers is called Product/Market fit.)". I think the point is valid, but talking about customers and calling it "market fit" may not be the clearest way to express the idea.

Roadmapping: Your customers don't care about your team's development schedule

I continue to be surprised and somewhat disappointed in most of the roadmapping tools I see aimed at product managers. Working primarily in the enterprise space during my career, I created "milestone" style roadmaps that showed when the team would deliver new capabilities to the market. What I see in the tool market today are inward-facing Gantt style roadmaps which, I assume, help the team manage their development work. Although this style is no doubt valuable to the team, in my experience, customers, in general, didn't much care when or how I worked on features: they wanted to know when they would get them. I would also say that many, if not most, internal stakeholders weren't that interested in our development plan.

I'm sure some will say that changes in delivery models, e.g., SaaS, mean that teams continuously deliver to the market and milestones are now irrelevant. I maintain that customers still don't care about your development schedule and that when software is mission critical, continuous delivery isn't the boon it is in other contexts. There are certainly exceptions to this rule (in the security domain, for example).

What I believe is needed are tools that allow product managers to generate different product roadmaps based on the same set of "investments". Such a tool would allow certain things to be excluded or renamed and, above all, would show traditional delivery milestones.

What is your experience? Have I simply overlooked good roadmapping tools that already do what I describe?

Managing Complex Solutions: When Product Management Begins Breaking Down

I've spent most of my career working as a product manager in huge software companies (IBM, Microsoft, SAP) and as a product management consultant and trainer with vendors that deliver complex solutions in the B2B space. Perhaps it's just me, but when I look at most of the content being generated in the field of product management, I can't help but thinking that something is missing. To my eyes, most of it seems startup-centric (in the consumer space mostly), so, to someone who's been slugging it out in trenches of highly complex problem spaces, much of the talk of MVPs, A/B testing, continuous delivery and other hot topics seems a bit, dare I say, naïve.

 What I consider a lack of emphasis on what I've labeled the "enterprise space" has inspired me to begin thinking deeply about the unique challenges of effectively managing products that must address some of the world's stickiest business and technical problems. Often, these complex problems require complex organizations to deliver the associated solutions, which in itself brings a boatload of obstacles that a PM in a startup can only imagine (in nightmares for the most part).

 Here are just a few of the differences between the enterprise and consumer-oriented startups that are top of mind:

 The Myth of the Customer

In the enterprise space, the people who evaluate, buy and use the software are often different. Buying decisions may take years and the solution may be required to function (almost perfectly) for years or even decades. When we use the term "customer", it is a conversational convenience. The truth is, the enterprise customer comprises a complicated set of stakeholders we have to identify, understand and appease.

 The Dysfunctional Family

Big, stable organizations with highly specialized roles tend to create "families" that are (often highly) dysfunctional. Familiarity, procedural inertia and contention for resources make vendors that deliver complex products and solutions highly political, to the point that a majority of a PM's time may be spent on "political overhead", generating negative value for customers. Navigating the fraught waters of a politically charged and entrenched organizational hierarchy requires a level of diplomatic adeptness that is rarely optional.

 The Curse of Mission Criticality

A lot of the more nimble practices espoused by the startup community are quickly exposed as not viable when the products or solutions being delivered can cause losses of millions of dollars or much worse, lives, when they fail. Add the fact that many of these "high assurance" scenarios are strictly regulated and you have the proverbial straw that can easily break the product manager's back.

 In the coming months, I'll talk extensively about the enterprise space and offer some food for thought on how to tackle some of its most daunting challenges. Take heart enterprise product manager, together we can be inspired by what's happening in the startup world but move beyond it to make our community happier and more effective.

 You can read more about related topics on my site and blog.

The fine line between an interview question and free consulting

Absolutely LOVED this article by Liz Ryan in Forbes. I too have been put in the ridiculous situation of being asked to do specific strategy work in the context of a job interview. Luckily, I've never been desperate for a job when it happened. Probing questions that help a hiring manager determine if I have a solid grasp of some part of the job she expects me to perform make sense. Asking me to invest my time to formulate a strategy for your current situation in anything but the most general terms is not OK. Lest I belabor what I consider fairly obvious point:

1. If you're hiring: Using a job interview as an excuse to get free consulting from a candidate is simply not ethical behavior. There are plenty of ways to validate that someone knows their stuff without asking them for a free lunch.
2. If you're being interviewed: I realize how much stress a job search creates for a candidate, especially when you really need the work. However, resist the urge to give away your hard-won knowledge and creativity to someone who has essentially no skin in the game. An ethical organization and hiring manager will have better sense than to expect this.

I think there are more tactful ways to handle the situation described in the article (I assume the "victim" was convinced this guy was ONLY trying to pry knowledge out of her). For example, I was asked to develop a strategy for an online travel company thinking about expanding into business travel. I told the hiring manager that I was more than happy to discuss key factors that might increase their chances of success but that I simply wasn't willing to develop a strategy for him. I didn't get a call back and felt great about it. I didn't think I'd been rude in the least and managed to send him a clear signal that what he was asking for was unreasonable.

BTW, my opinion changes a bit for second-round interviews. If you're convinced you'be been selected from a broader field, you might consider being a bit more forthcoming. I would still stop short of doing free, strategic work for an organization who has invested little more in you than an interview slot or two.

I realize this is a touchy topic. What are your experiences?

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/