The choice between insightful and inciteful words

 

Civil society and civility

Non-profit organisations often characterise themselves as being part of ‘civil society’. Civil society has been defined and redefined over many years, but it broadly refers to “a wide array of organisations: community groups, non-governmental organisations (NGOs), labor unions, indigenous groups, charitable organisations, faith-based organisations, professional associations and foundations” (World Bank). As other ‘for-purpose’ and social enterprise models have emerged, alongside entities promoting transparency, sustainability, and accountability, the boundaries for ‘civil society’ have also expanded.

Historically, the purpose of civil society was to achieve eudaimonia – common wellbeing or flourishing. Aristotle used the term to refer to the highest human good, and defined this as the aim of practical philosophy (applied ethics). (Recommended reading: Practical wisdom: The right way to do the right thing, by Barry Schwarz and Kenneth Sharpe, Riverhead books, 2010)

In our interpersonal communications, being ‘civil’ simply means being courteous and polite with each other. In other words, treating others as we would like to be treated. Again, therefore, the term refers to common wellbeing.

Hijacked emotion

As advocates for various causes, non-profit organisations make extensive use of social media and various other methods to engage target audiences, and even to issue ‘calls to action’. Regrettably, sometimes when we appeal to emotions the intended outcome of advocacy action gets lost, with poorly managed emotions taking over.

We see this happening when advocates start attacking opponents (ad hominem arguments) rather than focusing on the issue or problem, and the associated evidence.

Separate the people from the problem

Calibrating our words (as suggested in the header image), whether in a meeting, in social settings, or in the heat of an advocacy campaign, requires some level of mindfulness, along with an unshakeable commitment to ‘the common good’. Even when provoked by personal attacks, we do no good for the cause we represent if we resort to insults and inciteful words.

The four key principles underpinning the negotiating method recommended in the seminal reference Getting to Yes: Negotiating agreement without giving in (by Roger Fisher and William Ury, Hutchison. 1982) are highlighted in the chart below.

The words we use and the ’emotional’ tone we employ (in written or oral forms) will reflect the extent to which we have internalised the principles recommended by Fisher and Ury. Negative emotions tend to impede effective engagement and the capacity to reach agreement. Conversely, positive emotions tend to enable agreement.

The notion that you can’t argue with an angry person applies to both parties of course. Just as you won’t persuade another person of the legitimacy of your views if they are angry, you won’t budge them if you are angry either.

The emotional dimension of negotiation (and advocacy too I suggest) is the subject of a later book by Roger Fisher, this time with Daniel Shapiro – Building Agreement: Using emotions as you negotiate. Core concepts that motivate people form the central themes in this very helpful sequel.

Beyond the arguments based on effective methods of helping people to better align with your perspectives, there are also of course risk management reasons for avoiding insulting or inciteful language.

Our words and actions need to be insightful rather than inciteful.*

*As noted in a previous post, homonyms are words that sound the same but have different meanings. ‘Insightful’ and ‘inciteful’ are homonyms, but they are also an example of homophones (a subset of homonyms), words that sound the same but have different spellings and meanings.

Trolling and cyberbullying

Public health and other advocates have become victims of trolling and cyber-bullying increasingly of late, particularly since COVID appeared. The UK Centre for Countering Digital Hate (CCDH) recommends the Troll Counterstrategy outlined in the chart below.

If you or your team have been victims of trolling or cyberbullying, seek support from local health and cyber-safety groups. In Victoria, the Better Health Channel offers resources and advice on these issues, including links to mental health helplines.

https://tinyurl.com/3b8w7946

How to argue

 The web is turning writing into a conversation. Twenty years ago, writers wrote and readers read. The web lets readers respond, and increasingly they do—in comment threads, on forums, and in their own blog posts.

Many who respond to something disagree with it. That's to be expected. Agreeing tends to motivate people less than disagreeing. And when you agree there's less to say. You could expand on something the author said, but he has probably already explored the most interesting implications. When you disagree you're entering territory he may not have explored.

The result is there's a lot more disagreeing going on, especially measured by the word. That doesn't mean people are getting angrier. The structural change in the way we communicate is enough to account for it. But though it's not anger that's driving the increase in disagreement, there's a danger that the increase in disagreement will make people angrier. Particularly online, where it's easy to say things you'd never say face to face.

If we're all going to be disagreeing more, we should be careful to do it well. What does it mean to disagree well? Most readers can tell the difference between mere name-calling and a carefully reasoned refutation, but I think it would help to put names on the intermediate stages. So here's an attempt at a disagreement hierarchy:

DH0. Name-calling.

This is the lowest form of disagreement, and probably also the most common. We've all seen comments like this:

u r a fag!!!!!!!!!!

But it's important to realize that more articulate name-calling has just as little weight. A comment like

The author is a self-important dilettante.

is really nothing more than a pretentious version of "u r a fag."

DH1. Ad Hominem.

An ad hominem attack is not quite as weak as mere name-calling. It might actually carry some weight. For example, if a senator wrote an article saying senators' salaries should be increased, one could respond:

Of course he would say that. He's a senator.

This wouldn't refute the author's argument, but it may at least be relevant to the case. It's still a very weak form of disagreement, though. If there's something wrong with the senator's argument, you should say what it is; and if there isn't, what difference does it make that he's a senator?

Saying that an author lacks the authority to write about a topic is a variant of ad hominem—and a particularly useless sort, because good ideas often come from outsiders. The question is whether the author is correct or not. If his lack of authority caused him to make mistakes, point those out. And if it didn't, it's not a problem.

DH2. Responding to Tone.

The next level up we start to see responses to the writing, rather than the writer. The lowest form of these is to disagree with the author's tone. E.g.

I can't believe the author dismisses intelligent design in such a cavalier fashion.

Though better than attacking the author, this is still a weak form of disagreement. It matters much more whether the author is wrong or right than what his tone is. Especially since tone is so hard to judge. Someone who has a chip on their shoulder about some topic might be offended by a tone that to other readers seemed neutral.

So if the worst thing you can say about something is to criticize its tone, you're not saying much. Is the author flippant, but correct? Better that than grave and wrong. And if the author is incorrect somewhere, say where.

DH3. Contradiction.

In this stage we finally get responses to what was said, rather than how or by whom. The lowest form of response to an argument is simply to state the opposing case, with little or no supporting evidence.

This is often combined with DH2 statements, as in:

I can't believe the author dismisses intelligent design in such a cavalier fashion. Intelligent design is a legitimate scientific theory.

Contradiction can sometimes have some weight. Sometimes merely seeing the opposing case stated explicitly is enough to see that it's right. But usually evidence will help.

DH4. Counterargument.

At level 4 we reach the first form of convincing disagreement: counterargument. Forms up to this point can usually be ignored as proving nothing. Counterargument might prove something. The problem is, it's hard to say exactly what.

Counterargument is contradiction plus reasoning and/or evidence. When aimed squarely at the original argument, it can be convincing. But unfortunately it's common for counterarguments to be aimed at something slightly different. More often than not, two people arguing passionately about something are actually arguing about two different things. Sometimes they even agree with one another, but are so caught up in their squabble they don't realize it.

There could be a legitimate reason for arguing against something slightly different from what the original author said: when you feel they missed the heart of the matter. But when you do that, you should say explicitly you're doing it.

DH5. Refutation.

The most convincing form of disagreement is refutation. It's also the rarest, because it's the most work. Indeed, the disagreement hierarchy forms a kind of pyramid, in the sense that the higher you go the fewer instances you find.

To refute someone you probably have to quote them. You have to find a "smoking gun," a passage in whatever you disagree with that you feel is mistaken, and then explain why it's mistaken. If you can't find an actual quote to disagree with, you may be arguing with a straw man.

While refutation generally entails quoting, quoting doesn't necessarily imply refutation. Some writers quote parts of things they disagree with to give the appearance of legitimate refutation, then follow with a response as low as DH3 or even DH0.

DH6. Refuting the Central Point.

The force of a refutation depends on what you refute. The most powerful form of disagreement is to refute someone's central point.

Even as high as DH5 we still sometimes see deliberate dishonesty, as when someone picks out minor points of an argument and refutes those. Sometimes the spirit in which this is done makes it more of a sophisticated form of ad hominem than actual refutation. For example, correcting someone's grammar, or harping on minor mistakes in names or numbers. Unless the opposing argument actually depends on such things, the only purpose of correcting them is to discredit one's opponent.

Truly refuting something requires one to refute its central point, or at least one of them. And that means one has to commit explicitly to what the central point is. So a truly effective refutation would look like:

The author's main point seems to be x. As he says:

<quotation>

But this is wrong for the following reasons...

The quotation you point out as mistaken need not be the actual statement of the author's main point. It's enough to refute something it depends upon.

What It Means

Now we have a way of classifying forms of disagreement. What good is it? One thing the disagreement hierarchy doesn't give us is a way of picking a winner. DH levels merely describe the form of a statement, not whether it's correct. A DH6 response could still be completely mistaken.

But while DH levels don't set a lower bound on the convincingness of a reply, they do set an upper bound. A DH6 response might be unconvincing, but a DH2 or lower response is always unconvincing.

The most obvious advantage of classifying the forms of disagreement is that it will help people to evaluate what they read. In particular, it will help them to see through intellectually dishonest arguments. An eloquent speaker or writer can give the impression of vanquishing an opponent merely by using forceful words. In fact that is probably the defining quality of a demagogue. By giving names to the different forms of disagreement, we give critical readers a pin for popping such balloons.

Such labels may help writers too. Most intellectual dishonesty is unintentional. Someone arguing against the tone of something he disagrees with may believe he's really saying something. Zooming out and seeing his current position on the disagreement hierarchy may inspire him to try moving up to counterargument or refutation.

But the greatest benefit of disagreeing well is not just that it will make conversations better, but that it will make the people who have them happier. If you study conversations, you find there is a lot more meanness down in DH1 than up in DH6. You don't have to be mean when you have a real point to make. In fact, you don't want to. If you have something real to say, being mean just gets in the way.

If moving up the disagreement hierarchy makes people less mean, that will make most of them happier. Most people don't really enjoy being mean; they do it because they can't help it.


Thanks to Trevor Blackwell and Jessica Livingston for reading drafts of this.

https://tinyurl.com/2zam6atx

Getting on board with employee engagement

 

Starting a new job is a little like being a tourist visiting another country, where they speak another language and have different customs.

Learning the language and understanding the culture are just parts of the process of onboarding, which is itself only one aspect of the organisation’s talent management and employee engagement system.

A basic framework for learning about an organisation is suggested in the header image above. The context and environment surround the organisation’s structures, activities, and relationships, all linked by systems (including processes) and shared purpose. At each stage of the onboarding process, from pre-boarding, through onboarding to being fully engaged, these elements are addressed.

Initially, they are introduced in a high-level abstract way, then progressively more details and nuances are added until a more comprehensive ‘insider’ view is achieved. This progression also embeds onboarding activity within your organisation’s staff welfare, organisational development, and professional development systems. It can therefore be recognised as part of an ongoing talent management framework rather than as an isolated orientation ‘event’ or ‘probationary period’.

Regrettably, some non-profit organisations limit their thinking about their new employees’ experience to a brief orientation program, and an occasional touch-base to see how the new hire is settling in.

Herzberg’s Two Factor (Motivation) Theory helps us to think about the risks associated with an overemphasis on hygiene (control) factors such as policies, procedures, and compliance obligations. These extrinsic motivators tend to dominate orientation activities, so it is important to balance them with intrinsic motivators like building relationships, recognition of achievements, and offering pathways to challenging work and greater autonomy.

We know that high-performance work systems require employees who are highly engaged, who trust each other and work together effectively to achieve quality outcomes. We also know that it can take some time to become familiar with the complexity of our organisational systems – both in theoretical terms (what we say we do), and practical terms (what we actually do).

The Dreyfus Model of Skill Acquisition (the chart below references both the Herzberg and Dreyfus models) remains helpful in thinking about the staged onboarding of new employees. Your new employees will doubtless have the skills and qualifications to do the kind of work you need to be done. Their high-performance capacity though will depend at least partially on their effective use of your systems, processes, and technology, along with effective communication and relationships with colleagues and key stakeholders.

Employee engagement requires, amongst other things, paying attention to socialisation processes and interpersonal dynamics. It also benefits from thinking about the emotional journey experienced by each employee as they progress through the pre-boarding, onboarding, and onboard stages. The focussing questions suggested below may offer a useful starting point for this reflection, along with discussions with your current employees about their experience.

Most non-profit organisations have considered and refined their member/client journeys as they engage with the services offered, but it remains quite rare for non-profits to reflect on their employee journeys as they seek to become part of the organisation, rather than a mere ‘tourist’.

At a minimum, reviewing the measures, resources and responses invoked the first time an employee experiences key events or circumstances, is highly recommended. The following list of first-time events may assist you in performing this important planning activity. Thinking about these trigger events as opportunities to more effectively engage your employees is far preferable to merely cataloguing a set of risk prevention (control) measures.

https://tinyurl.com/mr6fcewj

The Ultimate Guide to Product Management

 

The question, “What is product management?” comes up pretty often, even from experienced business people. One reason is that product management encompasses a wide-ranging area of responsibilities. Indeed, the role itself means very different things in different organizations.

Here is the most concise response we’ve come up with for the “What is product management?” question: Product management is the practice of strategically driving the development, market launch, and continual support and improvement of a company’s products.

Of course, that is an abstract explanation of the role. So what is product management? What does the job entail?

What is Product Management?

The day-to-day tasks include a wide variety of strategic and tactical duties. Most product managers or product owners do not take on all these responsibilities. At least some of them are owned by other teams or departments in most companies. 

But most product professionals spend the majority of their time focused on the following:

• Conducting Research: Researching to gain expertise about the company’s market, user personas, and competitors.

• Developing Strategy: Shaping the industry knowledge they’ve learned into a high-level strategic plan for their product—including goals and objectives, a broad-strokes overview of the product itself, and maybe a rough timeline.

• Communicating Plans: Developing a working strategic plan using a product roadmap and presenting it to key stakeholders across their organization: executives, investors, development teams, etc. Ongoing communication across their cross-functional teams throughout the development process and beyond.

• • Coordinating Development: Assuming they have received a green light to move forward with their product’s strategic plan, coordinate with the relevant teams—product marketing, development, etc.—to begin executing the plan.
  • Acting on Feedback and Data Analysis: Finally, after building, testing, and introducing the product to the marketplace, learning via data analysis and soliciting direct feedback from users, what works, what doesn’t, and what to add. Working with the relevant teams to incorporate this feedback into future product iterations.

What isn't Product Management?

Product managers owning the day-to-day details of a product’s development is a common misconception. As we describe on our product management vs. project management page, this is the role of a project manager.

Product management’s strategic function

Product management is a strategic function. Tasking product managers with determining a product’s overall reason for being—the product’s “Why?” 

They’re also responsible for communicating product objectives and plans for the rest of the company. They must ensure everyone is working toward a shared organizational goal. 

Product management encompasses a broad set of ongoing strategic responsibilities. They shouldn’t be responsible for the ground-level details of the development process.

Innovative organizations separate this function and assign tactical elements to project managers, such as scheduling and managing workloads. This distinct division leaves the product manager free to focus on the higher-level strategy.

What is the Product Management Process?

There is no single “right” way to manage a product. Processes will evolve and adapt to the organization, the product lifecycle stage, and product team members’ and executives’ personal preferences.

But the discipline has developed some consensus regarding best practices. So while rigid adherence isn’t required and there isn’t the same level of zealotry as one might find when discussing Agile, the basic tenets are widely accepted.

Defining the problem

It all begins with identifying a high-value customer pain point. After that, people or organizations are trying to do something, and they can’t. Or, if they can, it’s expensive or time-consuming or resource-intensive or inefficient, or just unpleasant.

Whether it’s moving a person or thing from Point A to Point B, finding the perfect gift, reaching the right audience, keeping people entertained, or some other objective, what’s currently available isn’t quite cutting it. People want something better or something they don’t have at all.

Product management turns these abstract complaints, wants, and wishes into a problem statement looking for a solution. Solving that problem and easing that pain is the spark and motivation for everything that comes next. Without a clearly articulated goal that directly impacts that pain point, there’s not much hope that the product will gain traction or staying power.

Quantifying the opportunity

There are many problems and pain points, but not all are worth solving. This is when product managers swap their customer-centric hats for a business one.

To justify investment in building a new product or solution, product management must answer the following questions and be able to build a business case based on the answers they find:

• What is the total addressable market?
• Is the problem or pain severe enough that people will consider alternative solutions?
• Are they willing to pay for an alternative solution (or is there another way to monetize the solution)?

Once product management has evaluated the potential market, they can then try to address it if there’s a significant enough opportunity.

Researching potential solutions

With a target in mind, product management can now thoroughly investigate how they might solve customer problems and pain points. They should cast a large net of possible solutions and not rule anything out too quickly. For example, suppose the organization already has some proprietary technology or IP or a particular area of expertise to give the company an advantage. In that case, those potential solutions will likely leverage that somehow.

However, this does not mean that product managers should start drafting requirements and engaging the product development team. They’ll first want to validate those candidates with the target market, although it is prudent to bounce some of these ideas off the technical team to ensure they’re at least feasible. Product management will often develop personas to see whether there’s actual interest among those cohorts using any of the table’s ideas. 

Skipping this step and jumping right into building something can be a fatal flaw or cause severe delays. While there are no guarantees, getting confirmation from potential customers that the idea is something they’ll want, use, and pay for is a critical gate in the overall process and achieving product-market fit.

Building an MVP

After validating a particular solution’s appeal and viability, it’s now time to engage the product development team in earnest. First, the bare minimum set of functionality should be defined, and then the team can build a working version of the product that can be field-tested with actual users.

Many bells and whistles will intentionally be excluded from the Minimum Viable Product, as the goal is to ensure the core functionality meets the market’s needs. Nice-to-haves can wait for a later stage in the product lifecycle since there’s little point in expending additional resources on an unproven product.

MVPs can test how the product works and the overall messaging and positioning of the value proposition in conjunction with product marketing. The key is finding out whether this nascent product is something the market wants and if it adequately meets its core requirements.

Creating a feedback loop

While customer feedback is essential throughout a product’s life, there’s no time more critical than during the MVP introduction. This is where the product management team can learn what customers think, need, and dislike since they’re reacting to an actual product experience and not just theoretical ideas tossed out in a conversation.

Product management must make it easy for customers to provide feedback and create frequent prompts soliciting it. But, just as importantly, they must process, synthesize, and react to this feedback, turning this input into actionable ideas that make their way into the product roadmap or backlog.

And, not to be forgotten, product management must also establish a method for closing the loop with customers so they know their complaints and suggestions were heard and, when applicable, have been addressed.

Setting the strategy

Assuming the MVP is well received, it’s time to invest in a product strategy. The team now knows they’re onto something that can get some traction, so goals and objectives must be established to improve the product, bring it to market, expand its reach, and align with the overall company strategy and desired outcomes.

The strategy should be based on reasonable, incremental progress toward achievable goals, with key performance indicators and other metrics defined to evaluate success. These measurables should track with the organization’s general objectives and complement what the company already does well (assuming it’s not a startup still in its infancy).

More than anything else, the strategy is where product management must secure stakeholder alignment and buy-in. If there’s no solid, shared understanding of this fundamental element of the product, then the groundwork is already being laid for future conflicts and disagreements.

Driving execution

With a viable product concept, a scalable feedback management system, and a sound strategy, it’s time to turn ideas into reality. This means prioritizing potential development items and plotting out the product roadmap.

Product management can utilize various prioritization frameworks to decide which development activities will help the product meet its most important goals quickly and efficiently, cueing things up for near-term work. Of course, everything can’t be first, so basing these decisions on which items have the greatest impact on critical objectives is key, including representatives from across the organization. With the initial priorities set, product management can then build out their product roadmap. This powerful tool enables stakeholders to visualize what’s on the horizon and why it’s relevant to the strategy, particularly if structured around themes and outcomes versus specific features and delivery dates.

The People of Product Management

Product management doesn’t have too many subspecialties, primarily because product people are expected to do a little bit of everything. However, this career has some variety, along with expected tiers of seniority and additional responsibility.

First, some jobs often get lumped in with product that doesn’t belong there. This includes project management, program management, product marketing, and scrum masters.

Each of those critical roles interfaces with the product management team quite a bit. Some organizations may even arrange those jobs into the same groups, such as making product management and product marketing part of the overall marketing organization. But these positions aren’t product management jobs, as they don’t actively define what is in the product or report to the people who do. 

Product Management Jobs

The ideal product management job is—unsurprisingly—being a product manager. A product manager will usually own one or more products or a horizontal function across multiple products, such as “user experience” or “e-commerce.” 

Associate product managers and junior product managers are typically new to the domain and have more limited responsibilities. A senior product manager will have a little more seasoning and a broader scope of their role. But these are essentially slightly different flavors of your basic product manager.

Technical product managers are another critical variation of the role. These individuals are often transitioning from a role in the engineering or IT teams and tasked with managing aspects of one or more products requiring a deeper understanding of technical issues, such as infrastructure and APIs.

Agile product managers

In an Agile organization, product owners also may be part of the puzzle. While there’s some debate, product owners are often considered part of product management. However, they are distinct from product managers. A product owner is embedded in one or more scrum teams, but their focus is mainly tactical, helping ensure the strategy laid out by product managers is appropriately executed. 

As one moves up through the ranks, more senior product management roles have more significant distinctions. For example, a product line manager will own multiple products that are typically related to each other, sometimes overseeing individual contributor product managers that manage a single product or sub-component.

The Product Executive Track

The executive track begins with Director and Senior Director roles. Depending on the company’s size, this may be a loftier title for a “lone wolf” product management professional. But, on the other hand, it may indicate an even broader portfolio of products and the corresponding direct reports to support that. 

Vice President and Senior Vice President are similar escalations up the corporate ladder. Those holding these jobs may see more diversity on their staff as they may also end up owning business analysts, UX, product marketing, or other related functions. The apex of a product management career is Chief Product Officer. Although not as common, this increasingly seen role elevates product management to the C-suite. It gives the product the same political weight as Engineering or Marketing, which often indicates an organization is committed to product-led growth. A CPO is typically supported by a larger team and provides directional guidance and coaching rather than diving into the nitty-gritty details of particular products.

What are the Most Important Product Management Skills?

With a shared understanding of product management’s scope, we can dig into what it takes to be a product manager. Product managers find their way by following the paths of those who came before them. And those more experienced in the profession have plenty of lessons to offer their peers and newcomers. 

You can’t get a degree in product management. There’s no single career path to get there. It’s more about the skills required to do the job well than a particular pedigree. Here are some of the key hard skills in product management.

Communication 

Communication skills leap to the top of the list when considering what it takes to be a successful product manager. So many aspects of the job rely on prowess in this domain. 

To solicit and gather feedback, product managers need to be great listeners. They must also know how to work those relationships and exhibit significant customer empathy.

Of course, customers aren’t the only source of input to the prioritization process. Product managers must also work with various stakeholders to understand their goals and needs. 

After that, product managers must succinctly convey the product’s mission. It should be a synthesis of all those inputs turned into something easily consumable that others can be inspired by.

Evangelizing and alignment

With vision, goals, and the roadmap defined, product managers must socialize and evangelize these pillars of the product to the entire organization. It’s all about creating alignment, generating buy-in, and getting the whole company on the same page, including leveraging public forums such as all-hands meetings, as well as smaller forums and one-on-one sessions.

Once the product plans begin taking shape, product managers must work extensively with the product development organization. This collaboration includes engineers along well with product managers, architects, and quality assurance teams. 

Collaboration

To create a fantastic user experience, product managers must also collaborate with UX designers. Nurturing a true partnership and not being merely transactional is key to delivering exceptional products. 

Finally, as the product gets ready to launch, there’s another round of communication and coordination. Product management must educate and edit marketing plans for the product. They also must provide the sales team with the necessary training and talking points they’ll need.

Technical skills 

There may be no debate quite as polarizing in the product management community as this subject. Just how technical must a product manager be? Will non-technical product managers become extinct?

There’s no debating that a product manager must have some level of technical understanding. Luddites don’t make great product managers, at least not for software products.

Product managers must be conversant enough in the fundamentals for meaningful dialogue with engineering. They must understand if they’re creating a massive amount of technical debt with their decisions and managing down existing debt. And they should probably be knowledgeable enough to use their product and relate to the customers it’s intended to serve. 

However, there’s no rule that product managers must know how to code or run an SQL query on a database. While those might be practical skills, a product manager won’t be doing those things daily.

And in organizations where there is an actual need for product managers with in-depth technical know-how, they can always hire a technical product manager to fill that role. 

Business savvy

When product managers dub themselves the “CEO of the product,” they’re generally referring to this category of skills. Product managers may or may not carry responsibility for a product’s revenue. But they’re integral to making sure the product is financially and strategically successful.

It starts by defining a vision and goals for the product. While these may come from the founder or executive team, product management must own them once established. Then, translating those abstract ideas into the tactics required to make them a reality is all part of the job.

Other duties, such as finding product-market fit and assessing requests from customers and prospects, also require keen business smarts. 

To do so, product managers must think strategically, even when dealing with minutiae. No choice is inconsequential. They must dynamically consider all possible repercussions to avoid negative impacts on the customer experience or sales.

And then there are the numbers. Product managers must be conversant in the metrics that matter. They must use data-driven decision-making to propel the product forward. Growth, revenue, and profitability all fall under product management’s purview, even if they’re not directly responsible for them.

Product Management and Roadmaps

We might be a bit biased, but there’s no single aspect of product management as pivotal as a product roadmap. It’s the culmination of countless hours of research, negotiations, strategizing, and consensus-building.

Watch the webinar, Key Ingredients for Successful Product Roadmaps, for more on what goes into a roadmap.

Product roadmaps set the agenda and set expectations for the entire organization. They set a course for the future and provides a point of reference to inspire the whole organization. They turn the mission and vision into a concrete plan for making grand ideas a reality. 

But what’s on the roadmap is only half the battle. The other part is figuring out what kind of roadmap makes the most sense for the audience, the product’s maturity, and the timeframe it covers. One size does not fit all (although one tool can help you with every kind of roadmap you might want to create).

The first step is prioritizing the various initiatives and features using a prioritization framework. Define the parameters of your roadmap. Will it be feature-less? Based on themes? 

Setting the ground rules for the roadmap’s scope and level of detail are the hard part. Plugging in everything is easy. Then it’s time to rely on those communication skills and showcase the final product.

Product Management Tools

Product managers have more options than ever when it comes to tools. They cover a wide range of tasks and areas that product managers are responsible for.

But a product manager’s job involves a lot more than gather product insight, tracking the backlog, and reviewing the product roadmap. Whether you’re a new product manager or a seasoned PM just wanting to make sure you’re not missing a key component of your role because you’re lacking the proper tool—the following is a list of product management tools to help you excel in your role.

These include solutions for tracking user behavior, including heat mapping and session replays. Plus, there are surveying tools for gathering feedback. There are also a host of new options for collaboration. It encompasses asynchronous messaging, voice chats, file sharing, and document editing.

For demos, presentations, and onboarding, product managers can turn to web conferencing tools that support screen sharing and recording. These can also be co-opted for low-budget usability testing, as product managers can “ride-along” while users complete tasks using their products. Quickly visualize concepts and workflows with wireframe tools and flowcharts.

Project management tools have also made a massive impact on how product managers keep track of things. There’s no excuse to be managing your life and projects in a spreadsheet.

And, of course, there’s a pretty good tool for creating roadmaps we’re quite fond of. By relying on some of these solutions, product managers can increase their efficiency, become better collaborators, and make sure nothing falls through the cracks. Roadmapping software is a must-have item on any list of product management tools. Using any non-native roadmap application to draft and maintain your product roadmap (such as spreadsheets or slide decks) will create far more work, be far less flexible and easy to share, and more prone to version-control issues that can slow your product’s progress. This is exactly why we built ProductPlan.

Asking for a tools budget

Product managers shouldn’t be shy about asking for a tools budget; their time is just as valuable as other contributors. Requesting budgets for a tool is still a relatively rare occurrence for product teams, who traditionally haven’t had any dedicated budget and rarely ask for anything financial other than approving travel expenses or a new laptop. So, how do you successfully broach this subject with the executives holding the purse strings?

1. Make assumptions

2. Strength in numbers

3. Acknowledge the alternatives

4. Try the free-trial

5. Overcome the uncomfortable ask

B2B vs. B2C Product Management

One common belief in product management is that there is a vast difference between working on B2B and B2C products. While there are certainly some distinct aspects between those two worlds, they have plenty in common.

For B2C, your users are generally also your buyers, and you’re serving a single persona. For B2B, the person controlling the budget is often unrelated to the person who regularly uses the product. After identifying each persona, product managers can tailor the product and the pitch for each one of them. 

Both situations require multiple value propositions. Even single consumers are looking for numerous reasons to buy and use a product. Therefore, messaging should always speak to practical, emotional, and financial justifications for taking the plunge. 

It impacts the sales process, as B2B sales take a lot more convincing and win over many hearts and minds for a single transaction. And the cost of acquisition will be higher, and the growth rate slower for a B2B product.

But with proper expectations, there’s no reason the same skills and experiences can’t be transposed from one market to another. Product managers shouldn’t feel pigeonholed into only working in one market or the other. It just might take a little more convincing during the hiring process to shake them out of their false preconceptions.

Optimizing Product Management Operations

Product managers have an often overwhelming amount of obligations. Time is a precious commodity. They must be efficient and organized to conduct the necessary conversations and meetings while still having enough bandwidth actually to get some work done.

Process around decisions

Making decisions—and getting internal consensus on those decisions—can be a huge time suck. To get through them all promptly, product managers must find a scalable way to get to an agreement quickly. Clearly defined roles and a consistent process let the parties involved focus on the subject at hand.

A divide-and-conquer approach is another tactic for getting more done in less time. Recognizing the core strengths of everyone available, splitting up tasks, and delegating things lets product managers focus on what they do best while not neglecting anything else that’s important. 

Product managers can also borrow some useful skills from their project management counterparts. This includes defining explicit scopes and sticking to them, cutting down on diversions and ratholes. It’s additionally helpful to create clear action plans and communicate them to relevant colleagues to be sure everyone knows what they’re responsible for and understand the expectations.

Even how product managers schedule their day can lead to increased output and higher-quality working sessions. By minimizing context switching, product managers can cluster similar tasks together to maintain focus and limit distractions.

This includes making time for strategic thinking. It’s tough to take a deep dive into a particular subject when there are constant interruptions. Product managers must carve out time for this critical task and create an environment where they can concentrate.

Product Management Meetings

Meetings are unavoidable for product managers. They have the potential to offer tons of value. But when mismanaged, they can turn unproductive and suck up time they don’t have to spare.

Among our meeting tips for product managers, the focus is on efficiency. Whether it’s limiting attendance or defining a narrow scope, the goal is to have a purpose, stick to the plan and get it over with as fast as possible.

Follow-through is also essential. Product managers should take notes, circulate key information, and clarify any action items before everyone leaves. Of course, the best advice might be skipping the meeting altogether if it proves to be more distracting than beneficial.

Capitalizing on Customer Meetings

While internal meetings may seem like a chore, meeting with customers is one of the best parts of the job. It’s an opportunity to capture an unfiltered influx of feedback, ideas, and inspiration that can help product managers power through the less-than-awesome aspects of the situation.

Meeting directly with customers is always preferable to relying on coworkers in sales or support to funnel information back to the product team. Of course, this may not always be possible, but product managers should seize these opportunities when they arise. 

While sales and support might bring back valuable tidbits, they’re conducting conversations with customers through the lens of their particular jobs. The sales team is trying to gin up more business; support aims to solve the customer’s problems and move on quickly.

As a product manager, the only goal is to understand the customer better so the product experience can be improved and enhanced. These conversations can yield invaluable context for using the product and where they’re encountering challenges. Product managers should also take some worthwhile detours to explore other ancillary opportunities where the product could potentially be even more valuable or helpful to users.

Product management needs an established process for handling this feedback. First, ideas worth pursuing must be captured and tracked. Whether they’re eventually slotted into a release or discarded, customers who provided suggestions should be informed either way. This follow-up will encourage future feedback, and it shows customers their input is appreciated.

And while it may not always be pleasant, it’s also great to have conversations with ex-customers. Using “exit interviews” to collect churn feedback can shine a spotlight on key product flaws or shortcomings that might cause other users to call it quits. It may also uncover disconnects in product-market fit or pricing that motivate some customers to abandon the product.

Agile Product Management Operations

Agile has been around for a while in the product development world. However, Agile Transformation is a newer concept that brings the dynamic, nimble, responsive qualities of Agile to the entire organization.

One permutation of this approach is the concept of product squads. Pioneered by Spotify, they are autonomous teams with a group of developers and one product owner. Assigned to a particular functional area of the product, they’re able to attack the challenge freely. As a result, they can rapidly deliver value to the market while building in-house expertise on the subject.

Product squads may or may not make sense for a particular company or product. But they’re a great example of how product teams can reconfigure themselves to respond to opportunities more dynamically. Freed up from bureaucratic oversight, ad hoc or permanent groups can take ownership and drive rapid innovation.

Product Launch Responsibilities

After the product ships, product managers don’t get to kick up their heels and relax. There’s still plenty of work to be done.

Before the dust settles

Quickly following a launch, product managers should lead a product retrospective session. This post-mortem meeting looks back on how the release went. It ensures lessons are captured and brought forward to improve things the next time around.

These aren’t just sessions for finger-pointing and blaming others for what went wrong. Instead, it’s an opportunity to offer praise, recognize good work, and collaboratively identify best practices and the areas needing improvement.

As things mature

While everyone’s always excited about version 1.0, a product’s lifespan will include many ups and downs along the way. Likewise, the role of product management also evolves as a product matures and travels through the various phases of its lifecycle.

Before launch, subject matter expertise was the priority for product managers. So they’re trying to learn as much as they can from as many sources as possible. In addition, they’re prioritizing features for the MVP to make sure they’re delivering something with real benefits to the market. 

After the initial launch, the focus quickly shifts to growth. Product management worries about scale while adding functionality that continues to propel growth.

Once all those new users are onboard, the emphasis transitions to retention. It’s all about what’s required to keep customers happy and minimize churn. 

Most products inevitably begin to decline in usage, which presents new challenges. Product managers must consider how the product can be repurposed, extended, or pivoted toward new verticals. This maximizes the company’s value for an asset they’ve invested time, effort, and dollars into over the years.

Final farewells

Sadly, sometimes it’s time to say a final goodbye to a product. Product managers don’t get to skip out on the tasks related to the end-of-life process, either. They must take the lead, bringing the same consideration they spent on the product’s birth and subsequent iterations. 

A proper shutdown requires extreme attention to detail. Product managers must map out all possible ramifications that may arise from pulling the plug. From contractual and financial obligations to data portability and migration assistance — there’s plenty to juggle.

Most important of all is how the event is communicated. Customers must be handled carefully (particularly if you want to retain their business with other products). Stakeholders, customer service, strategic partners, and sales all require education, talking points, and escalation plans.

Conclusion: Product Management Strategy

Ultimately, our answer to the “What is Product Management?” question is that the role is all about strategy. First, product managers develop the product’s strategy and persuasively communicate it. Then they ensure all decisions concerning development, marketing, etc., reflect and support the strategy.

If you are interested in what makes a competent, successful product management professional, read the “Five Traits a Successful Product Manager Needs” section on our What is a Product Manager’s Job? page. Also, check out our ultimate guide to resources for product professionals to help you in your career development with all the best books, podcasts, and conferences our team recommends. Curious to learn the trends of product management in the upcoming year?

https://tinyurl.com/bdwf9cez