Why Companies Need Full-Time Product Managers (And What They Do All Day)
Email Newsletter
Weekly tips on front-end & UX.
Trusted by 200,000+ folks.
Take a break with a 3D game built on Netlify!
Check the frontend report!
Sponsor OWD on GitHub
Click here to kickstart your project for free in a matter of minutes.
Start with a free demo —What is a product manager? What do product managers do all day? Most importantly, why do companies need to hire them? Good questions.
The first confusion we have to clear up is what we mean by “product.” In the context of software development, a product is the website, application or online service that users interact with. Depending on the size of the company and its products, a product manager could be responsible for an entire system (such as a mobile app) or part of a system (such as the checkout flow on an e-commerce website across all devices).
This is confusing because, in most contexts, a product is a thing you sell to people. Particularly in e-commerce, product managers often get confused with category managers, which are the team that sources and merchandises the products sold on an e-commerce website. So, yes, “product” probably isn’t the best word for it. But it’s what we’ve got, and it’s the word we’ll refer to in exploring this role.
To define the role of a product manager, let’s start by looking at Marc Andreessen’s view of the only thing that matters in a startup:
"The quality of a startup’s product can be defined as how impressive the product is to one customer or user who actually uses it: How easy is the product to use? How feature rich is it? How fast is it? How extensible is it? How polished is it? How many (or rather, how few) bugs does it have? The size of a startup’s market is the the number, and growth rate, of those customers or users for that product.… The only thing that matters is getting to product-market fit. Product-market fit means being in a good market with a product that can satisfy that market."
Even though Andreessen wrote this for startups, the importance of that last sentence about product-market fit holds truth for every organization — whether the organization is getting a new product to market or redesigning an existing experience or anything in between. It is a universal road map to success, and it is the core of what product managers are responsible for.
With that as the backdrop, my definition of the role of a product manager would be to achieve business success by meeting user needs through the continual planning and execution of digital product solutions.
This definition summarizes all of the things that a product manager needs to obsess over: the target market, the intricacies of the product, what the business needs in order to succeed, and how to measure that success. It also encapsulates the three things that a product manager should never lose sight of:
- The ultimate measure of success is the health of the business and, therefore, the value that the product provides to users.
- Everything starts with a solid understanding of the target market and its needs, so that the focus remains on the quality of the product experience.
- A continual cycle of planning and execution is required to meet these market needs in a sustainable way.
So, how does this translate to what a product manager does every day? That question is way too big to answer here, but as an introduction, Marty Cagan has a great list of common tasks that product managers are responsible for in his ebook Behind Every Great Product (PDF). The tasks include:
- identifying and assessing the validity and feasibility of product opportunities,
- making sure the right product is delivered at the right time,
- developing a product strategy and road map for development,
- leading the team in executing the product’s road map,
- evangelizing the product internally to the executive team and colleagues,
- representing customers through the product development process.
But before a product manager is able to do these things, a couple of awkward questions have to be asked. First, do companies really need product managers? And, if we can agree on that, what are the characteristics of a good one? Also, where does this role fit in an organization’s structure? Let’s explore these questions.
Why Companies Need Product Managers
The role of product manager can be a hard sell for some companies. Common objections to it include:
- “We have various people in the organization whose roles fulfill each of these functions.”
- “I don’t see how the role would make us more money.”
- “Product managers would just slow us down.”
- “I don’t want to relinquish control of the product to someone else.” (OK, this one is not usually said out loud.)
These appear to be valid concerns, but only if the role is not well understood — or if the organization has bad product managers who perpetuate these perceptions.
The truth is that, to be effective, the role of a manager for a particular product or area must not be filled by multiple people. It is essential for the product manager to see the whole picture — the strategic vision as well as the details of implementation — in order to make good decisions about the product. If knowledge of different parts of the process resides in the heads of different people, then no one will have that holistic view, and all value will be drained of the role.
Let’s look at two major benefits that product managers bring.
Product Managers Ensure A Market-Driven Approach
The key argument in favor of product managers is that they help companies to be driven by the needs and goals of the target market, not the forces of technology or fads. As Barbara Nelson puts it in “Who Needs Product Management?”:
"It is vastly easier to identify market problems and solve them with technology than it is to find buyers for your existing technology."
If done right, a market-driven focus results in long-term, sustainable, profitable business, because the company will remain focused on solving market problems, as opposed to looking for things to do with the latest technologies. A market-driven focus is important because companies that have one are proven to be more profitable than those driven by other factors (31% more profitable, according to George S. Day and Prakash Nedungadi).
This doesn’t mean focusing on incremental change to the exclusion of product innovation. Identifying market problems is about not only finding existing issues to improve (for example, “60% of users drop off on this page, so let’s fix that”), but also about creating new products to satisfy unmet needs (“Cell phones suck — let’s make a better one”).
Product Managers Improve Time-To-Everything
The second major benefit of product managers is that they reduce the time an organization takes to reach its goals. A well-defined and appropriate product development process run by effective managers will improve both the time-to-market as well as the time-to-revenue.
The reason for the faster turnaround time is that a product manager is responsible for figuring out what’s worth building and what’s not. This means less time spent on the spaghetti approach to product development (throwing things against the wall to see what sticks) and more time spent on building products that have been validated in the market. This approach also sharpens the organization’s focus, enabling the organization to dedicate more people to products that are likely to succeed, instead of spreading people too thin on projects that no one is sure will have a product-market fit.
Characteristics Of A Good Product Manager
Now that we’ve covered the importance of product managers, the next question is, “Who are these people?”
Most of us are familiar with the idea of T-shaped people: those who have deep knowledge in one or two areas, with a reasonable understanding of a variety of disciplines related to their main field of focus. In 2009, Bill Buxton wrote an interesting article for Businessweek in which he calls for more “I-shaped” people:
"These have their feet firmly planted in the mud of the practical world, and yet stretch far enough to stick their head in the clouds when they need to. Furthermore, they simultaneously span all of the space in between."
This is a good description of the unique blend of skills that product managers need. First, they need to have their head in the clouds. They need to be leaders who can look into the future and think strategically. They need to be able to develop a vision of where a product should go, and they need to be able to communicate that vision effectively. Furthermore, product managers need to show their teams how they plan to get to that vision. And I do mean show: through sketches, prototypes, storyboards, whatever it takes to get the message across. They also need to be flexible and be able to change course when needed; for example, when market needs or expectations shift substantially or a great business opportunity presents itself.
But a good product manager also has their feet on the ground. They pay attention to detail, and they know the product inside out. They are the product’s biggest user — its biggest fan and critic. They understand every aspect of the complexity that needs to be worked through in each product decision. And they’re able to make those decisions quickly, based on all of the information at their disposal.
Most importantly, a product manager knows how to ship. They know how to execute and rally a team to get products and improvements out into the world, where the target market can use it and provide feedback.
In short, a product manager is a visionary as well as a doer, a manager as well as a maker. And they need to move seamlessly between those extremes, sometimes at a moment’s notice. Sound difficult? That’s only the beginning. Let’s look at some more characteristics of a good product manager.
Leader And Collaborator
Being a leader and a collaborator at the same time is a difficult balance to strike. The first challenge is that collaboration is often mistaken for consensus. That’s not the case. Consensus cultures often produce watered-down, unexciting products, products whose endless rounds of give-and-take have worn down the original idea to a shadow of what it was. Consensus cultures also wear down the teams working on the product, because they don’t really get what they want, only some of it.
Collaboration is different. In collaboration cultures, people understand that, even though everyone has a voice, not everyone gets to decide. People are free to air their opinions, argue passionately for how things should be done, and negotiate compromises. But that certainly doesn’t mean that everyone has to agree with every decision.
The first step to building a collaboration culture is to have a good leader. As you’ve probably surmised by now, the product manager is the ultimate decision-maker. But that only works if they are a trusted and respected leader in the organization, someone who can get the team excited about the vision, as well as make decisions that are best for the company and its customers. A good leader also readily admits when they have made a wrong decision, and they own up to it and do whatever they can to fix the mistake.
This isn’t a post about leadership — there are plenty of those to go around. But I’ll still share one piece of leadership advice from French writer and aviator Antoine de Saint Exupéry that has helped me over the years:
"If you want to build a ship, don’t drum people up together to collect wood, and don’t assign them tasks and work. Rather teach them to long for the endless immensity of the sea."
What does “the endless immensity of the sea” mean in your context? Instead of telling people to build a bunch of features, how can you inspire them to think about how the product will help users accomplish their goals? That’s how you’ll be able to unite teams around a common vision.
So, how does a good leader foster this kind of collaboration culture? By creating an environment and creating processes that allow collaboration to feed on itself, and by understanding that every person is different and will react unpredictably at some point.
To create the right environment and processes for collaboration, focus on the physical environment first. Make sure that physical workspaces allow team members both to have impromptu discussions with each other and to shut out all distractions and focus on work for a period of time. The MailChimp office is a great example of this. The team created a collaborative workspace based on the following principles:
- Commingle and cross-pollinate. Instead of segregating teams, mix people up according to their personalities and the projects they’re working on. This will lead to valuable discussions that might not have happened if everyone was stuck in their own silo.
- Facilitate movement. Open desks, couches, standing tables: these are all elements that encourage people to move around and work together when needed.
- Ideas everywhere. Cover walls and whiteboards with sketches, designs, prioritization lists and road maps. This will not only contribute to better communication, but also leave the door open for anyone to improve ideas that others are working on.
- Create convergence. A common space for lunch (and coffee!) is important because it will allow people to run into each other, even people who don’t normally work together on projects. Again, this can lead to great ideas and perspectives.
- Create retreats. The hustle and bustle of collaboration spaces has great energy, but it is sometimes distracting. Individuals and teams occasionally need a quiet space to work, so make sure they have meeting rooms or quiet retreats that prevent any interruption.
Workspaces are more important than we might think. We went to great lengths to create a welcoming, creative space at the studio I used to work at, and the effort is paying off. Most clients prefer to come to us for meetings, and they cite two reasons: the excellent coffee (we went a little overboard on the coffee) and the great atmosphere to work in.
Steve Jobs understood the value of physical spaces very well. He is quoted in Walter Isaacson’s biography as saying this about the design of Pixar’s new campus:
"If a building doesn’t encourage [collaboration], you’ll lose a lot of innovation and the magic that’s sparked by serendipity. So we designed the building to make people get out of their offices and mingle in the central atrium with people they might not otherwise see."
Of course, physical space is only one part of the equation. A lot of work happens remotely now, and we have enough tools at our disposal to make that an effective and rewarding experience for everyone involved. From communication tools like Campfire, HipChat and Slack to collaborative project-management tools like Trello, Basecamp and Jira to source-code repositories like GitHub and Bitbucket, we have no excuse anymore to force everyone to be in the same physical space at all times. There is still much value in talking face to face and in collaborating during certain stages of the process, but even that can happen in digital spaces.
So, what’s next after you’ve worked on the physical and digital environments? Next is a feared word. Many people think “process” is synonymous with “things I have to do instead of working.” But a lot of appropriate, or “right-fidelity,” processes are possible. To quote Michael Lopp: “Engineers don’t hate process. They hate process that can’t defend itself.” When it comes to creating a culture of collaboration, several processes — defendable processes — can make life easier for the whole team.
One essential process to get right is regular feedback sessions on design, development and business decisions. The challenge is that feedback sessions can get out of hand quickly, because we’re just not very good at providing (or getting) feedback. We are prone to seeing the negative elements of someone’s ideas first, so we often jump right into the teardown. This puts the person on the receiving end in a defensive mode right away, which usually begins a spiral down into unhelpful arguments and distrust.
There is a better way. In an interview on criticism and judgment, French philosopher Michel Foucault laid out the purpose of any good critique. In his view, criticism should focus not on what doesn’t work, but on how to build on the ideas of others to make them better:
"I can’t help but dream about a kind of criticism that would try not to judge but to bring an oeuvre, a book, a sentence, an idea to life; it would fight fires, watch grass grow, listen to the wind, and catch the sea foam in the breeze and scatter it. It would multiply not judgements but signs of existence; it would summon them, drag them from their sleep. Perhaps it would invent them sometimes — all the better. Criticism that hands down sentences sends me to sleep; I’d like a criticism of scintillating leaps of the imagination. It would not be sovereign or dressed in red. It would bear the lightning of possible storms."
Keeping this purpose in mind, let’s turn to the process used by Jared Spool and his team at User Interface Engineering. The team uses this process specifically for design critiques, but it could be applied to any kind of feedback session:
- The person presenting their idea or work describes the problem they are trying to solve.
- If everyone agrees on the problem, the team moves on. If there is not agreement on the problem to be solved, some discussion is needed to clarify. Hopefully, this step isn’t needed, though.
- Next, the presenter communicates their idea or shows their work to the team. The goal is not only to show the finished product, but to explain the thought process behind it. The presenter should remain focused on how the idea will solve the problem that everyone has agreed on.
- The first step in giving feedback is for the people in the room to point out what they like about the idea. This isn’t a ruse to deliver a crap sandwich (you know, start and end with something positive and eviscerate in the middle). Rather, this step highlights which approach to the problem is desirable.
- Critique ensues, not as direct attacks or phrases such as “I don’t like…,” but as questions about the idea. Team members will ask whether a different solution was considered, what the reason was for a particular choice and so on. This gives the presenter a chance to respond if they’ve thought through the issue already, or else to make a note to address it for the next iteration.
- At the end of the meeting, the team reviews the notes, especially what everyone liked and what questions they had. The presenter then goes away to work on the next iteration of the idea.
As the product manager, you are responsible for making sure that feedback sessions happen and that they are respectful and useful.
The goal of collaboration is for participants to make ideas better by building on the best parts of different thoughts and viewpoints. As long as people trust that the decision-maker (that’s you, dear product manager) has the best interests of the product and company at heart, then they won’t have a problem not getting their way every once in a while. Be confident, trustworthy and decisive — and make sure that everyone feels comfortable raising their opinion with the team.
All of this is much easier said than done, of course. Product managers need to steer the team through the collaboration process, and sometimes the trust just won’t be there in the beginning. That’s OK — trust takes time. Live these values, lead by example, and the culture will come.
Communicator And Negotiator
A more accurate label for this section might be “Overcommunicator and Negotiator,” because if there’s one thing a product manager never gets tired of, it’s telling people what’s happening. But instead of sending a ton of email, a better way is to work in the open as much as possible. Make sure that notes, sketches, plans and strategies are all accessible to everyone in the company at all times. This could take the form of whiteboards that are placed across the office or in a company wiki or in project spaces. Working out in the open has the added benefit of giving context to conversations: All comments and decisions will be in one place, instead of spread out over multiple emails (or, worse, in meetings where no one remembers to take notes).
Being a product manager sometimes feels like you’re being torn limb from limb. Most stakeholders have only their own department’s interests at heart (as they should — they’re paid to fight for what they care about). In contrast, a product manager needs to negotiate the best solution from all of the different directions that stakeholders want to take, and then communicate that decision effectively and without alienating people who don’t get their way. That’s not an easy job.
The design community has a phrase to refer to the difficult process of managing the expectations (and assertions) of a variety of stakeholders: design by committee. Like consensus culture, decision-by-committee cultures are pervasive, particularly in large organizations. I’ve always liked the approach that Speider Schneider proposes in his article “Why Design-By-Committee Should Die”:
"The sensible answer is to listen, absorb, discuss, be able to defend any design decision with clarity and reason, know when to pick your battles and know when to let go."
This is not as easy as it sounds. So, over time, I’ve developed the following guidelines to deal with decision-by-committee in a systematic way.
Respond To Every Piece Of Feedback
Responding to every demand, criticism, question and idea takes time. But failing to respond will waste even more time and energy down the road. Someone listening to another person’s idea and deciding not to use it is one thing. Someone not even listening is something else entirely. Instead of dealing with the political ramifications of not hearing people out, take the time to respond thoughtfully whenever someone offers feedback or an idea (no matter how unfeasible).
Note What Feedback Is Incorporated
When you implement a good idea, don’t do it quietly. It’s an opportunity to show that you’re flexible and open to good feedback. Let people know when and how their ideas are being used. Also, this should go without saying, but don’t take credit for someone else’s idea.
When Feedback Is Not Incorporated, Explain Why
Most of the feedback you’ll receive can’t realistically be incorporated into the product. Don’t sweep those decisions under the rug. By forcing yourself to be clear and straightforward about which feedback won’t be incorporated, you’ll also force yourself to think through the decision and defend it properly. Sometimes you’ll even realize that what you initially dismissed as a bad idea would be an improvement after all. People are generally OK with their feedback not being used, as long as they know that they’ve been heard and that there’s a good reason for the decision.
Use A Validation Stack To Defend Decisions
In their book Undercover User Experience Design, Cennydd Bowles and James Box explain the user experience validation stack, yet another method that can be used to defend product decisions. When defending a decision, always try to cite user data as evidence, such as usability testing and website analytics. If you don’t have direct access to user data, look for research — either research you’ve done or third-party research into related areas. If all else fails, fall back on theory. The principles of visual perception, persuasion, psychology and so on could be very handy in explaining why you’ve made certain decisions.
These guidelines should make it easier to negotiate different needs and requests from internal stakeholders. But remember Speider’s recommendation in his article: Pick your battles, and know when to let go. That’s the art of being a good negotiator and communicator.
Passionate And Empathetic
Product managers love and deeply respect well-designed, well-made products, both physical and digital. And they live to create such products. They are the people who go to parties and can’t shut up about a new website or app or, more likely, can’t shut up about how cool what they’re working on is.
They’re passionate not only about product, but about users, too. They understand the market well: their customers’ values, priorities, perceptions and experiences. Passion for product is useless without empathy for its users. Building a great product is not possible without getting into the minds of the people who will use it. If we want to anticipate what people want and guide them along that path, then empathy is non-negotiable.
Qualified And Curious
Product managers usually come from specialist backgrounds, such as user experience design, programming and business analysis. To apply their specialized knowledge to this new field — in other words, to become more I-shaped — they will need to be able to learn new skills very quickly (and under great pressure). Insatiable curiosity is a prerequisite for this ability to learn quickly. Why? Cap Watkins puts it well:
"If you’re intensely curious, I tend to worry less about those other skills. Over and over I watch great designers acquire new skills and push the boundaries of what can be done through sheer curiosity and force of will. Curiosity forces us to stay up all night teaching ourselves a new Photoshop technique. It wakes us up in the middle of the night because it can’t let go of the interaction problem we haven’t nailed yet. I honestly think it’s the single most important trait a designer (or, hell, anyone working in tech) can possess."
A good product manager does whatever it takes to make a product successful. They constantly worry about the tiniest of details, as well as the biggest of strategy questions. Rather than feeling overwhelmed by the sheer amount of what needs to be done, their curiosity pushes them to remain committed and to become as qualified as possible to make the right decisions.
Trustworthy And Ethical
A good product manager inspires trust in their team with every decision they make. To be trustworthy, they need to be fair (more on this later) and consistent, and they need to always take responsibility for their decisions. They also have to admit when they’re wrong, which is difficult at the best of times.
On the one hand, a product manager needs to be confident in the decisions they make. They need to constantly learn and grow and hone their craft. Theory and technique need to become so ingrained that they become second nature, the cornerstone of everything they do.
On the other hand, they need to be open to the fact that some of their decisions will be wrong. In fact, they need to welcome it. They should hang on to a measure of self-doubt every time they present a solution to the team or to the world. Admitting that someone else’s idea is better than yours and making changes based on good criticism will do wonders for improving the product — and it will build trust among the team. John Lilly phrases what should be a mantra for all product managers: “Design like you’re right; listen like you’re wrong.”
The best product managers are those who are guided by a strong and ethical perspective on the world. An discussion of ethics will only get me into trouble here, but it would be wrong not to at least touch on the subject. In short, we’re not just making products; we are putting a stamp on the world, and we have an opportunity to make the world a better place. Perhaps no one says it better than Mike Monteiro in Design Is a Job:
"I urge each and every one of you to seek out projects that leave the world a better place than you found it. We used to design ways to get to the moon; now we design ways to never have to get out of bed. You have the power to change that."
How do we identify projects and problems that fit these criteria? One way is to watch out for what Paul Graham calls “schlep blindness”: our inability to identify hard problems to solve, mostly because we’re just not consciously looking for them. Paul’s advice to combat this? Instead of asking what problem you should solve, ask what problem you wish someone else would solve for you.
Another great source of ideas for worthy projects is the field of social entrepreneurship (i.e. pursuing innovative solutions to social problems). Meagan Fallone has a great overview of the nature and importance of this type of work:
"We in turn can teach Silicon Valley about the human link between the design function and the impact for a human being’s quality of life. We do not regard the users of technology as “customers,” but as human beings whose lives must be improved by the demystification of and access to technology. Otherwise, technology has no place in the basic human needs we see in the developing world. Sustainable design of technology must address real challenges; this is non-negotiable for us. Social enterprise stands alone in its responsibility to ensuring sustainability and impact in every possible aspect of our work."
The book Wicked Problems is a great source of ideas on how to put our effort towards meaningful work.
Of course, people define socially important work differently. That’s OK — what’s important is to think it through and to clearly delineate the work you want to be involved in.
Responsible And Flexible
To garner sympathy from others, product managers like to say that the most difficult part of their job is that they have all of the responsibility but none of the authority. In other words, even though product managers are responsible for the success and failure of their products, no one normally reports to them. This is why good communication and collaboration skills are so crucial.
The danger of all having all of the responsibility for a product is rigidity: not letting go of tasks that could easily be delegated and stubbornly sticking to the plan when circumstances have changed. That’s why product managers must remain flexible. Planning is critical, and an essential part of planning is allowing for the right information to change the plan if needed.
This need for flexibility can unnerve some product managers, but it’s a necessary part of the process of building a great product. So, get comfortable with ambiguity. This job has a lot of it.
In Fairness
This one is the most important characteristic of a product manager — the one that rules them all. I once had a discussion with a colleague in our development team about the development process for new products that we had rolled out a few months before. One of the words he used to describe the new process is “fair.”
It was a passing comment, and I didn’t really think much of it at the time, but since then I’ve kept going back to that conversation and the importance of fairness in product management. All of the characteristics I’ve talked about are great, but fairness is the one that a product manager simply cannot do without.
Let’s look at one definition of the word and consider what it means in product management:
"fair (adjective) free from favoritism or self-interest or bias or deception."
Free From Favoritism
One of the fastest ways for a product manager to become ineffective is to play favorites with a team, product line or user base. As soon as people sense that you are not looking at all ideas equally and fairly, their trust in you will inevitably erode. And without trust, you’ll have to work a lot harder (and longer) to get people to follow your road map.
Free From Self-Interest
If you start doing things purely for reasons like “Because I want to” or “Because my performance is being measured this way,” then trust will erode again. You cannot be effective by nursing your pet projects and ignoring the needs around you.
Free From Bias
This often happens when product managers receive news they don’t want to hear, especially from the user research or analytics teams. If something doesn’t test well, don’t make up reasons why you are right and users are wrong. Do the right thing and realign the design.
One of the hardest skills for a product manager to learn is to take their own emotions and feelings out of the equation when making decisions. Yes, a lot of gut feeling goes into a product vision, but that should not be based on personal preference or preconceived ideas. This is much easier said than done, but it’s something to strive for and to be aware of at all times.
Free From Deception
This one seems obvious, but you see it often, especially with metrics and assessment. Don’t ignore or distort negative data or blame a problem on someone else. Your job is to own the product, and this means owning its successes and its failures. You’ll gain trust and respect only if you acknowledge the failures as much as the successes and commit to doing better next time.
A product manager is often referred to as “the great diplomat,” and with good reason. Our responsibility is to balance the variety of needs from inside and outside the company and to somehow turn that into a road map that generates business value and meets user needs. A focus on fairness will help to accomplish that goal:
- Fairness to users. Approach users with respect, openness and transparency. Understand their needs, and explain to them why you might need to do something that will make it more difficult for them to meet those needs.
- Fairness to the company. Do everything you can to understand the needs of marketing, merchandising, customer support and other departments. Pull them into the planning process; be clear about how projects are prioritized; and help them adjust to that process so that they can define their project goals in a way that gets them on the road map.
- Fairness to technology. Don’t try to force the development team to make the product’s technology do things it’s not capable of doing. Understand the technical debt in the organization, and work actively to make those improvements a part of regular development cycles.
A lot of this comes naturally with good product managers, but we need to be conscious of it every day. Fairness is a prerequisite to building great products. If you’re not fair, you’ll be dead in the water, working with a team that has no reason to trust that you’re doing the right thing.
A Prerequisite For Success
One last topic needs to be addressed. An organization can hire the best product managers in the world and implement the best development processes, but it will still fail if one prerequisite for success is not met. There needs to be an executive mandate and company-wide understanding that, even though everyone has a voice, decisions about product ultimately rest with the product manager.
This one is hard to swallow for many companies. When I mention this part in training courses on product management, the mood in the room often changes. This is when people start complaining that, even though they see the value in the role, it would never work at their company because team leaders aren’t willing to give up that ultimate control over the product. The strategies for dealing with this warrant another article. For now, here’s what Seth Godin reportedly once said: “Nothing is what happens when everyone has to agree.” The product manager is there to make sure things happen — the right things.
Executive teams and individual contributors have to buy into this role. If they don’t, then the product manager will become impotent and a frustrated bystander to a process that continues to spiral out of control. And they’ll end up going somewhere where their value is appreciated.
What Now?
We’ve covered a bunch of what might be considered “soft issues” in product management: what product managers are like, how they work with other people, what differentiates a good one from a bad one. It’s tempting to skim over these issues to get to the how — the processes and day-to-day activities of the role. But that would be a mistake. I haven’t seen a role in product development that relies more on these soft skills than that of the product manager. A product manager could have the best strategy and could execute brilliantly, but if they’re not able to work well with people and rally them around a cause, they will fail. So, if you’ve skipped over any of those sections, consider going back and reading them.
We can’t stop here, of course. Now that the foundation is in place, it’s time to move on to how product managers spend their day. If you’d like to read more about product planning (how to prepare for and prioritize product changes) and product execution (how to ship those changes), then check out my book Making It Right!
Further Reading
- Hold A Kickoff Meeting Before Diving Into The Design
- Fitting Big-Picture UX Into Agile Development
- How To Effectively Communicate With Developers
- The Consequences Of Working In Isolation
(al, il, mrn)
