{"id":184112,"date":"2016-01-28T14:16:51","date_gmt":"2016-01-28T14:16:51","guid":{"rendered":"https:\/\/staging.rm.gfolkdev.net\/?p=184112"},"modified":"2023-07-12T22:31:10","modified_gmt":"2023-07-12T22:31:10","slug":"product-teams-who-does-what","status":"publish","type":"post","link":"https:\/\/rosenfeldmedia.com\/product-teams-who-does-what\/","title":{"rendered":"Product Teams – Who Does What?"},"content":{"rendered":"
When we started talking about putting on the <\/span>PM + UX Conference<\/span><\/a>, the first thing we asked was, \u201cWhat sorts of things should we talk about?\u201d Since the folks at <\/span>Rosenfeld Media<\/span><\/a> are, not surprisingly, extremely user-centered, the obvious answer was, \u201cWe\u2019re not sure. How about we do some research and find out what questions our attendees might have?\u201d So we did. <\/span><\/p>\n The most interesting thing to me was that a lot of the questions people asked boiled down to \u201cWho does what on a product team?\u201d<\/b> This was curious. I mean, we\u2019re all working on product teams or we\u2019ve worked on them in the past, right? Shouldn\u2019t we know what our jobs are? Shouldn\u2019t we know what everybody else is doing? Well, yes! We should! And yet\u2026 when I started to dig around and have conversations with people, I got very, very different answers about how things really worked. <\/span><\/p>\n That was odd. <\/span>It turned out that, although we all have job titles like Product Manager or UX Designer, many of us have very different ideas about what it is that we\u2019re supposed to actually do all day.<\/b> Do designers talk to customers? What about PMs? Who decides what features go into a product? Who makes wireframes? Does anybody do usability testing? If not, could they please start? <\/span><\/p>\n Like any good team faced with more questions than they started with, we did some more research. Ok, first we had a couple of stiff drinks. Then we did some more research. I was volunteered to lead the way. <\/span><\/p>\n I wanted to make sure that we hadn\u2019t gotten weird data or misinterpreted the questions being asked- after all, it was a survey – so I conducted several qualitative interviews with PMs and UX designers in various sized organizations. I asked about what PMs and UX designers did at their companies. Incidentally, I also got a lot of \u201cbut the way we SHOULD do it is\u2026\u201d answers, but I was focused on reality for the moment. And reality seemed just as confused as the survey results. <\/span><\/p>\n After talking to a dozen or so people, I decided I wanted to collect exactly what tasks were performed at different companies so that we could see how much overlap existed. To get as many data points as possible, I sent out a very simple survey asking people what their role was, which tasks they thought were performed by UX Designers and which tasks they thought were performed by PMs. <\/span><\/p>\n I got dozens of responses from people on different product teams\u2013mostly UX, PM, and researchers\u2013and even some engineers, marketers, founders and managers. Of these responses, I got <\/span>hundreds <\/span><\/i>of different things that are being done by product teams.I am not exaggerating. It seems that PMs and designers are performing a dizzying array of tasks from generative research to making roadmaps to managing stakeholders to visual design. <\/span><\/p>\n I got curious. Who on these teams are doing all of these things? Seriously, most product teams just aren\u2019t that big, so how do they get hundreds of things done? Who\u2019s got that kind of time?? I narrowed down all the responses by deduplicating things that were similar. I picked the things that were mentioned the most, narrowed it down to 73 discrete tasks or processes\u2013which is still a LOT of things for a team to be doing. <\/span><\/p>\n Next, I did a card sort: I asked people to review each task and tell me whether it was mostly done by designers, mostly by PMs, done about equally, or generally done by nobody or somebody besides these. I also said you could make your own categories for things that didn\u2019t fit. <\/span><\/p>\n I ran the card sort remotely using <\/span>OptimalSort<\/span><\/a>, which was handy, since that meant that I could gather a lot more input than if I\u2019d had to travel around with a set of index cards and watch each person do the sort. It also made it a lot easier to categorize, and you\u2019ll see in just one second why that was important. <\/span><\/p>\n 82 of you weighed in with how things worked at your company. And, surprise surprise, there was virtually no agreement. I mean, there were a few similarities. Everybody agreed that visual design was done by someone in the design department (except for those of you who said it was done by outside people or people in marketing). And almost everybody agreed that roadmaps were made by PMs. Or by execs. Or by managers. Or by someone else. <\/span><\/p>\n Oh, and nobody agreed about who was supposed to do user research, except that a lot of people made a category called something like \u201cthings we aren\u2019t doing enough of\u201d and stuck user research into it. So, that was fun. <\/span><\/p>\n Here are a few of the things people actually agreed on mostly.<\/b><\/p>\n Interestingly, there was far more agreement about what designers do than about what product managers do across companies.<\/span><\/p>\n <\/a><\/p>\n <\/p>\n The most agreed upon tasks were things like visual design, design specs and style guides, image manipulation, illustration, and branding. Almost everybody agreed that these were mostly done by designers. <\/span><\/p>\n The unfortunate part about this particular agreement is that, while it\u2019s true that these are more \u201cdesign\u201d tasks than they are \u201cproduct management\u201d tasks, it tends to confirm the idea that many organizations still see design as limited to visual design.<\/span><\/p>\n <\/a><\/p>\n <\/p>\n It has \u201cdesign\u201d right there in the title, but 10% of the respondents said that interaction design is done equally by product managers and designers, and one sad person said that it\u2019s not being done at all. <\/span><\/p>\n Other tasks that were mostly done by designers were what you might expect:<\/span><\/p>\n Interactive prototypes were also very high on the list of tasks mostly done by designers, although at a few companies they\u2019re still being made by engineers or developers. This may reflect the huge number of new prototyping tools available these days. <\/span><\/p>\n There was a lot less agreement across \u00a0companies about what PMs were doing, frankly.<\/span><\/p>\n <\/a><\/p>\n <\/p>\n The most agreed upon task for product managers was creating and maintaining feature roadmaps, with 63 people saying that this was almost always done by product managers. In twelve cases however, roadmaps were maintained equally by designers and PMs, and in six cases, they\u2019re being made by someone else or not being made at all. Project and program managers are sometimes the keepers of the roadmap, but very infrequently.<\/span><\/p>\n <\/a><\/p>\n <\/p>\n Many of the most common product management tasks, unsurprisingly, are things that involve defining and prioritizing features, creating revenue models, or project management and scheduling tasks like sprint planning. <\/span><\/p>\n But there were really only a few of these tasks where more than half of the respondents agreed that they were done mostly by product managers and there were no tasks where more than three quarters of the respondents agreed were all or mostly done by product managers. <\/span><\/p>\n Business strategy, for example, was reported to be done primarily by PMs in only 50 of the 83 cases. In five cases, it was done equally by PMs and Designers and the rest of the time was done by anybody from executives to finance to nobody at all. In one case, the entire team worked together on setting business strategy. <\/span><\/p>\n The most inspiring part of the study for me was how many tasks people are doing together – either as a whole, cross-functional team, or at least across the PM and Design roles. <\/span><\/p>\n In 13 cases, the entire team reported brainstorming new features together, and in 51 cases, brainstorming was done about equally by PMs and UX designers. Hopefully that means that more people are getting involved in figuring out which new features to build for users. <\/span><\/p>\n Perhaps the most evenly split task was customer discovery, which worked out like this:<\/span><\/p>\n I don\u2019t like to see customer discovery not getting done almost 20% of the time, but it\u2019s good that when it\u2019s happening it\u2019s a shared task. Needs finding had a similar split, as did most forms of generative research. At least, when user research is getting done, it\u2019s getting done by the whole team rather than being entirely run by one group. <\/span><\/p>\n Having a shared understanding of what we do and what we\u2019re supposed to do is hugely important to creating a well-functioning team. Imagine trying to build a baseball team where nobody agreed on what shortstops were supposed to do or what made somebody a great pitcher. It would be chaos. <\/span><\/p>\n And yet, every day, we hire people, add them to our teams, and give them titles like product manager or UX designer or researcher, without realizing that the last company where they worked might have had an entirely different definition of the role. Then we\u2019re shocked when somebody who was a fantastic PM at their last company isn\u2019t succeeding. Or we can\u2019t believe that the new designer can\u2019t do what we consider to be a trivial task. Worse, sometimes we have no idea what our coworkers are doing or what they\u2019re supposed to be doing, which is why important tasks can fall through the cracks. <\/span><\/p>\n There is actually one more bit of research that I\u2019ve been doing in parallel for awhile now as I work on my new book, <\/span>Build Better Products<\/span><\/i><\/a> (Rosenfeld Media \u201816). I\u2019ve been talking to teams in order to understand which ones are most effectively delivering value to users. There seems to be a very strong correlation between good outcomes and the teams that report doing certain of these tasks together. Teams that conduct research together are more likely to understand their users. Teams that use that research to ideate together are more likely to come up with feature ideas that users want. Teams that decide business strategy together are less likely to get into arguments about what should be prioritized. <\/span><\/p>\n If you want to learn more about how your team can work together more effectively, check out the upcoming one-day online conference devoted exclusively to <\/span>Product Management + User Experience<\/span><\/a>. I\u2019ll be sharing activities you can run yourself to build team cohesion and get everybody working together. Your ticket gives you all-day access plus recordings to <\/span>the full program<\/span><\/a>. There are only a few spots left. Hope to see you there!<\/span><\/p>\n <\/p>\n Laura Klein <\/i><\/b>is a Lean UX and Research expert in Silicon Valley who teaches companies how to get to know their users and build products people will love. She’s a Rosenfeld Media expert and author of UX for Lean Startups (O\u2019Reilly). Her newest book, <\/span><\/i>Build Better Products<\/span><\/i><\/a>, is set for release later in 2016. Follow her on <\/span><\/i>Twitter<\/span><\/i><\/a> or subscribe to her blog and podcast at <\/span><\/i>Users Know<\/span><\/i><\/a>. <\/span><\/i><\/p>\n","protected":false},"excerpt":{"rendered":" When we started talking about putting on the PM + UX Conference, the first thing we asked was, \u201cWhat sorts of things should we talk about?\u201d Since the folks at Rosenfeld Media are, not surprisingly, extremely user-centered, the obvious answer was, \u201cWe\u2019re not sure. How about we do some research and find out what questions … Continued<\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_seopress_robots_primary_cat":"","_relevanssi_hide_post":"","_relevanssi_hide_content":"","_relevanssi_pin_for_all":"","_relevanssi_pin_keywords":"","_relevanssi_unpin_keywords":"","_relevanssi_related_keywords":"","_relevanssi_related_include_ids":"","_relevanssi_related_exclude_ids":"","_relevanssi_related_no_append":"","_relevanssi_related_not_related":"","_relevanssi_related_posts":"","_relevanssi_noindex_reason":"","footnotes":""},"categories":[26],"tags":[793],"acf":[],"_links":{"self":[{"href":"https:\/\/rosenfeldmedia.com\/wp-json\/wp\/v2\/posts\/184112"}],"collection":[{"href":"https:\/\/rosenfeldmedia.com\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/rosenfeldmedia.com\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/rosenfeldmedia.com\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/rosenfeldmedia.com\/wp-json\/wp\/v2\/comments?post=184112"}],"version-history":[{"count":2,"href":"https:\/\/rosenfeldmedia.com\/wp-json\/wp\/v2\/posts\/184112\/revisions"}],"predecessor-version":[{"id":186440,"href":"https:\/\/rosenfeldmedia.com\/wp-json\/wp\/v2\/posts\/184112\/revisions\/186440"}],"wp:attachment":[{"href":"https:\/\/rosenfeldmedia.com\/wp-json\/wp\/v2\/media?parent=184112"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/rosenfeldmedia.com\/wp-json\/wp\/v2\/categories?post=184112"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/rosenfeldmedia.com\/wp-json\/wp\/v2\/tags?post=184112"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}The Research Methodology<\/span><\/h2>\n
The Research Results<\/span><\/h2>\n
What Are Designers Doing? <\/span><\/h3>\n
Visual Design<\/span><\/h4>\n
Interaction Design<\/span><\/h4>\n
Other Mostly Design Tasks<\/span><\/h4>\n
\n
What Are PMs Doing? <\/span><\/h3>\n
Roadmaps<\/span><\/h4>\n
Feature Definition, Business Strategy, and Scheduling<\/span><\/h4>\n
What are People Doing Together? <\/span><\/h2>\n
\n
Why Does this Matter? <\/span><\/h2>\n
Learn More<\/span><\/h2>\n
\n