Why Companies Need Full-Time Product Managers (And What They Do All Day)
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.
No comments:
Post a Comment