{"id":192768,"date":"2023-07-19T20:48:08","date_gmt":"2023-07-19T20:48:08","guid":{"rendered":"https:\/\/staging.rm.gfolkdev.net\/?page_id=192768"},"modified":"2023-07-19T20:48:08","modified_gmt":"2023-07-19T20:48:08","slug":"sample-chapter-product-management-for-ux-people","status":"publish","type":"page","link":"https:\/\/rosenfeldmedia.com\/sample-chapter-product-management-for-ux-people\/","title":{"rendered":"Sample Chapter: Product Management for UX People"},"content":{"rendered":"
This is a sample chapter from Christian Crumlish<\/a>\u2019s book\u00a0Product Management for UX People: From Designing to Thriving in a Product World<\/em>. 2022, Rosenfeld Media.<\/p>\n If you\u2019re not sure what product managers do, you\u2019re not alone. Quite a few hiring managers\u2014not to mention entire businesses\u2014are also confused about this job title and what exactly it means. It doesn\u2019t help that there are a wide variety of legitimate approaches to product management that tend to emphasize one or another of the constituent proficiencies at the expense of the others. As confusing as this may seem, there are multiple legitimate approaches to product management in practice today, because the work itself depends so heavily on context. That being said, every product manager has the same core responsibility: value.<\/p>\n The product manager is responsible for value, through the coordination and delivery of customer experiences, and for making sure that the experience being delivered to customers (and other stakeholders) provides enough value to be \u201chired\u201d by the user and developed as a sustainable concern, ideally in service of a broader vision.<\/p>\n OK, but sustainable in what sense? It\u2019s a broad goal. LinkedIn product lead and social change evangelist B. Pagels-Minor suggested at least one dimension of this: \u201cSomething the user values and repeatedly uses.\u201d In addition to that, for a system of any kind, business or otherwise, to become sustainable, it needs to find repeatable cycles of inputs and outcomes that literally keep the system going. Some of the inputs, usually those related to people or money, need to be at least steady and consistent, if not growing, Whatever you\u2019re building has to keep these cycles flowing.<\/p>\n So think of it this way: any sustaining value to the organization is derived by taking a fair share of the value created for the \u201ccustomer\u201d (or end user, subject, actor, protagonist).<\/p>\n Responsibility for value helps clarify a few roles that are often confused with product managers: project managers and product owners. Before digging into the building blocks of product management, let\u2019s first get those different titles defined and distinguished.<\/p>\n From the Trenches…<\/strong><\/p>\n What We Talk About When We Talk About Value<\/strong><\/em><\/p>\n The first person who taught me to focus on \u201cvalue\u201d as the lodestar of product management was Jay Zaveri, who was my chief product officer at the time, at a start-up called CloudOn, and now runs a product incubator at Social Capital, a VC firm in Palo Alto.<\/p>\n I checked back with him because when people ask what defines value, it\u2019s hard to avoid circularity of the \u201cyou know it when you see it variety.\u201d Some people emphasize value to the whole system vs. monetary value, or value that accrues to the owner of the organization alone. However, Jay put it this way: \u201cValue is something special that a person or customer experiences that never existed in the same way for them in the past\u2014it\u2019s a product that is useful, usable, and desirable. Value fulfills a deep need, desire, or want for the customer that they did not even know existed. It\u2019s apparent when something is technologically differentiated (\u2018cheaper, faster, better\u2019), abundantly available (\u2018accessible in a way that was only available to few before\u2019), and changes human behavior (in a way that is beneficial to the person or customer).\u201d<\/p>\n When asked who gets this value, he said, \u201cI think people get confused by adding financial metrics as value metrics. Some of those are necessary, but not sufficient, and some are pure garbage. No true value is created by just financial and growth metrics; in fact, we now know there are serious unintended consequences if you are focused only on them. Nothing beats staying focused on true value to your customer\u2014everyone wins!\u201d<\/p>\n Product managers<\/em> are frequently mixed up with project managers<\/em>. Even people who know the difference will occasionally confuse them in speech. Abbreviations are no help, as both are commonly referred to as PMs with only context making the meaning clear. (Sometimes that context is \u201cthis company doesn\u2019t have any project managers\u201d or vice versa; other times, it\u2019s based on the speaker, the team, and the conversation itself.)<\/p>\n Note: In this book, PM<\/em> means Product Manager<\/em><\/strong><\/p>\n To make things worse, project management can be one of the responsibilities of a product manager. PMs care a lot about schedules, know how to read a Gantt chart, strive to keep everything on track, and work to hold everyone to their commitments, but this should only be a sliver of their time and attention.<\/p>\n A project manager is a specialist whose subject matter knowledge helps them excel at understanding the fine points, but whose core expertise is keeping projects on track, on time, and on budget, not on defining the value of a product and driving the strategy to maximize that value.<\/p>\n Some project managers do become product managers and when they do, just as with UX designers, they must master a whole series of adjacent skills beyond \u201ckeeping the trains running on time.\u201d<\/p>\n Product consultant and author Matt LeMay, co-founder of Sudden Compass, put it this way: \u201cProduct managers have both the opportunity and the responsibility to ask \u2018why?\u2019\u201d<\/p>\n There are core differences between a product manager and a product owner. Although companies often use the terms indiscriminately to mean the same thing or apply their own meaning, for this book, we\u2019ll define them this way:<\/p>\n Originally, the product owner tended to be drawn from the company\u2019s engineering pool, and some teams used a specialized scrum master role that required training and certification and focused on the project management dimensions of an Agile scrum development environment. Product owners from the engineering team were often a team lead but not always. However, today, there are many different real-world uses of this title in practice, including teams where the primary business stakeholder is called the product owner<\/em>, or in some government contexts in which the \u201cproduct owner\u201d is the person ultimately responsible for what the team delivers, more akin to what Product owner activities likewise are often part of the work of a product manager, to the extent that some businesses even treat the product owner as an entry- or low-level product manager job title, but again this somewhat obscures the origin of the role from outside of the product management tradition.<\/p>\n So where did the tradition of a product manager come from? Why does everyone now seem to speak in terms of \u201cproducts\u201d at all in this digital age, and why are the people called upon to pull it all together called product managers<\/em>?<\/p>\n The deep history of product management came from the 20th century concept of marketing, which emerged as an attempt to really understand a potential customer and to be more scientific about measuring the size of the market, the reach of a product, and so on.<\/p>\n (Some of this should sound familiar, as new generations rediscover these ideas and frame them in terms of research, humans, users, experience, experimentation, or analysis.)<\/p>\n The product metaphor itself is a bit double-edged in the internet age. The value it offers is to help focus and concretize the offering you are building to meet the needs of real people, or do jobs for them, or ease their journeys, and so on.<\/p>\n But the very real need to be specific and clear about what you are making (and what you are not) can easily hide the slippery nature of online products, which differ from their industrial counterparts in two major ways that both fall under the heading of \u201cactually being a service\u201d:<\/p>\n Regardless of the subtext of the word product<\/em> and the mental frames that may get dragged along by its use, it has emerged as a way of talking about the product or service being built to meet the needs of real people in a valuable way.<\/p>\n A mid-20th century product manager would have usually been someone with a business background, if not a degree in business, and the earliest digital equivalents inherited some of that DNA.<\/p>\n Product management to this day is perceived by most people as a business discipline or practice. Core to the role of the product manager is the responsibility for the business case, business strategy, and financial viability of a product.<\/p>\n Unfortunately, this stereotype can be negative: for example, the \u201csuit,\u201d the bean-counter, or the boss man who only cares about the bottom line. Yes, there are plenty of people with product titles out there living up to those clich\u00e9s, but it doesn\u2019t have to be that way. UX designers interested in product management can start by embracing the realities, necessities, and even the joy of business. It doesn\u2019t have to be a dirty word.<\/p>\n When the product manager role first emerged in large software and other tech companies, it came with that business foundation and was often paired with technology or balanced by engineering and perhaps one or more other pillars (such as clinical expertise in a health enterprise, or editorial content in a media company, etc., depending on the nature of the business).<\/p>\n The equivalent role that emerged at Microsoft at the time was called program manager<\/em>. Today, program management usually refers to a separate discipline dedicated to operational execution of complex programs, generally consisting of multiple ongoing interrelated projects.<\/p>\n These PMs nearly always had MBAs and at times rubbed seasoned engineers and designers the wrong way when \u201cput in charge\u201d directly out of school.<\/p>\n A number of business titles and roles have contributed to how product management is practiced today, and along the way, many people have done product management work under these titles, roles such as business analyst, product marketer, customer success specialist, and others. Execution-related business skills, such as project management, decision-making, strategic alignment, and leadership factor in there somewhere as well.<\/p>\n Sometimes the business aspect of the role is summarized with a saying, \u201cThe product manager is the CEO of the product,\u201d but this really isn\u2019t true. The only value of that expression is that in an extremely broad way it suggests that the PM has a business responsibility for their product that is central and critical. The buck stops with the product manager.<\/p>\n But the expression is frankly more misleading than helpful because CEOs control the budget, CEOs can hire or fire the team, and just about everybody reports ultimately to the CEO. Product managers have business responsibilities, sure, but they do not wield anything like CEO power.<\/p>\n From the Trenches…<\/strong><\/p>\n MBA Not Required<\/em><\/strong><\/p>\n A couple of years ago, I was part of a team led by Matte Scheinker that was charged with raising the product bar at AOL, which had newly spun off from its disappointing Time\/Warner merger and was playing catch-up with a decade-old style of web development. One of the things we did was review and update the HR ladders for product managers and UX designers, indicating what level of accomplishment was required across a series of criteria to be hired at or promoted to each level\u2014from associate to VP (with an individual-contributor track leading to principal, at the director level for designers).<\/p>\n The old grid required the product managers to have an MBA. We removed this. The HR department asked if we could make it \u201cMBA preferred,\u201d but we said that this wasn\u2019t the case. If anything, we were MBA-neutral. An MBA might help make a PM better at the business side of the role, or it might not. The time spent getting the MBA yielded one set of experiences and contacts, and the equivalent time spent working yielded another. By itself, the degree didn\u2019t tell us much; however, we didn\u2019t penalize anyone for having an MBA!<\/p>\n Joff Redfern, a VP of Product at Atlassian (and formerly LinkedIn and Facebook) prefers to frame this aspect of the role as thinking like a general manager. It has some of the same limitations in terms of direct authority, but more closely matches the notion of one person with business-related responsibility for a coherent chunk of work.<\/p>\n Clement Kao of Product Manager HQ points out the GMs also have hiring and firing responsibilities, and he prefers to frame these operational and strategic leadership aspects as being \u201cboth coaches and janitors.\u201d<\/p>\n Alongside this business-focused type of product manager, the turn of the millennium saw some managers and lead developers emerge from engineering departments and take on product management roles, sometimes, at first, in the absence of a true product practice, but more generally as a new career path open to engineering managers.<\/p>\n Another antecedent of today\u2019s product manager roles lies in the concept of a marketing manager or even a product marketing manager, which is the historic origin of the role in 20th century business practices. Interestingly, the obsession with customer needs that is inherent in product management derives from this fundamental DNA. The obsessions today with addressing markets and achieving product-market fit are other elements of continuity with the market- ing orientation of early product management.<\/p>\n Both roles still exist as distinct positions in many organizations. This dichotomy can potentially lead to turf or coordination issues when the product manager wants to approach product\/marketing issues from a product-centric point of view and the product marketing manager wants to approach these same issues from a marketing-centric framework.<\/p>\n The article \u201cProduct Marketing Manager vs. Product Manager: Where Do You Draw the Line?\u201d (www.productplan.com\/learn\/product-manager-vs-product-marketing-manager\/) does a nice job of delineating these roles and making a case for them being separate, boiling down the essence to this:<\/p>\n Given that the context of all of this is software and technology, science and engineering, on some level any product manager in the internet age is a technical product manager, at least in the eyes of people who don\u2019t work in tech. (In practice, roles defined as technical product managers<\/em> almost always require a computer science or analytical or subject matter expertise with the specific technical approach of the business.)<\/p>\n Engineers with big-picture skills (such as technical design and architecture), a vision for the purpose and value of what the team is building, and the ability to debate pros and cons with other stakeholders to make the case for a specific direction, may find they have greater leverage and ability to steer the ship as product managers.<\/p>\n The influx of engineer-trained PMs into the field started rebalancing the mix of skills expected from product people, with the business sense still a core orientation and now coupled with a deep mastery of the technical issues involved in software development.<\/p>\n When the role is literally advertised as a \u201ctechnical product manager\u201d or at an engineering-led company such as Google or any of its many imitators, the job application will include several technical interviews involving puzzles and problem-solving questions very similar to the ones presented to programmers, without necessarily requiring them to write any code.<\/p>\n Questions involving sorting, efficiency, algorithmic complexity, etc. reflect product cultures that are heavily centered on engineering skill sets, experience, and frames of reference.<\/p>\n Google is famous both for making product managers \u201cearn\u201d engineering resources and buy in. There\u2019s no guarantee that producing a spec means anyone will build it for you. But Google is also famous for cultivating and empowering product managers. The Associate Product Manager program with its structured training and rotation that Marissa Mayer pioneered there has been widely imitated at other aspiring tech giants.<\/p>\n But again, the type of product manager favored in shops with Google or Google-adjacent cultures tends to be highly technical, hence these brain-teaser type interview sessions that really only make sense as a filter for programming-capable minds and not so much as the far-fetched notion that the PM will routinely debate the \u201cbig-O complexity\u201d of several competing algorithmic approaches.<\/p>\n Note: The Technical PM Interview<\/strong><\/p>\n And to be fair, nowadays most decent places that pose challenges like these encourage them to collaborate with you and help you along with your thinking. (If a role like that is your goal and you aren\u2019t a computer scientist, there are books to help you cram. More about choosing your career path in Chapter 2, \u201cDo You Want to Be a Product Manager?\u201d)<\/p>\n At Yahoo, the product organization was a peer to and equally as powerful as the engineering organization. From the beginning, Yahoo\u2019s websites were planned and built by people called producers (adopting terminology from media and broadcasting).<\/p>\n Over several years, these jobs gained in complexity and ultimately diverged into two distinct roles, one focused on planning and directing what got built (product managers) and the other doing the actual building (front-end engineers). It actually took some time for the front-end developers to be accepted as peers in the engineering organization, given prejudices at the time against HTML markup and the other front-end languages, but the significance here is that the product role, at least at one of the 90s era internet tech companies (\u201cdot coms\u201d), shared a common ancestor with a programming job.<\/p>\n Fast forward to today, and the role is still a highly technical one. A strong UX practitioner is going to take a serious interest in the technology they are designing with and for, just as an artist takes pains to understand their materials, but at the same time the designer is empowered to explore possibilities without constantly bringing to mind the apparent limitations of the existing technical stack and codebase.<\/p>\n Product managers (and not just \u201ctechnical\u201d product managers), by contrast, must delve even more deeply into the substance and properties and limitations of the technologies being worked with and never really have the luxury of putting those factors to one side. (PMs also spend much more time working directly with engineers than most UX designers do, which creates further pressure to demonstrate a thorough command of the technical factors that figure into any difficult decision.)<\/p>\n The new hybrid eng\/biz type product model still left a lot to be desired as practiced, as most companies still follow waterfall and command-and-control software development lifecycle practices, but in the first decade or so of the millennium a few influential practitioners studying what worked well in Silicon Valley started articulating a fresh model of \u201clean\u201d and \u201cagile\u201d and \u201cfully empowered\u201d product management.<\/p>\n Marty Cagan, a consultant with the Silicon Valley Product Group and author of the book Inspired<\/em>, made a strong case for empowering the product team to investigate problem spaces, conduct discovery processes, meet customers and prospects face-to-face, and seek to deeply understand what people need and what they will love to bring valuable products to the market.<\/p>\n Rich Mironov, a product consultant who advises companies, takes interim product executive roles (he calls this smoke jumping) and writes and teaches workshops. They and others have sought to raise the bar and to highlight the most effective techniques, approaches, and mindsets, while remaining clear-eyed and cautionary about the institutional patterns and incentives that can push back against these approaches.<\/p>\n For example, an empowered product team should understand the goals and outcomes it is seeking and be engaged in a process of iterating experimentally toward meeting those goals. The team should be capable of communicating to others what the current snapshot of the plan is, in the form of a roadmap (much more on this to come), expressed in terms of what is underway right now, what is coming up next, and what is expected to come later.<\/p>\n Many leaders in traditional organizations balk when they see a roadmap communicated this way, especially if what they had in mind when they asked to see the roadmap was really a set of firm release dates on which clearly defined features would be delivered and launched.<\/p>\n But committing to deliver a feature on a certain date, based on a fully baked specification, is a recipe for disaster. That process is too brittle and fails in the face of new information, data from users, stakeholders, and changing market conditions, just to name a few.<\/p>\n This is the same notion from the \u201clean\u201d movement, popularized by Eric Ries\u2019s book The Lean Startup<\/em>: The product manager in an empowered team is facilitating a constant cycle that involves learning from what is currently \u201cshipped\u201d and \u201cin the wild,\u201d feeding these insights back into renewed discovery processes driven by qualitative inquiry to explore hypotheses and seek understanding, redefinition of the problem space, identification of further opportunities or experiments worth exploring, decisions about what to build or fix next, and shipping to start the cycle anew.<\/p>\n This cycle shown in Figure 1.1 can be modeled in great detail but is most often reduced to \u201cBuild, Measure, Learn.\u201d<\/p>\n <\/p>\n Figure 1.1<\/strong> It\u2019s worth noting that despite the title and the fact that it\u2019s a cycle, you generally do not start with building. You start by learning something or by measuring (initially assessing) something, learning about something, and then building a thing.<\/p>\n This process of constant learning, feeding back into discovery, redefinition of problems and opportunities, and iterative design is applicable in the early stages while prototyping new ideas, as well as throughout the life of a product. The approach is still gaining adherents (for example, people like Jeff Gothelf and Josh Seiden have worked hard to bring lean ideas about experimentation to the UX community). Outside of innovative tech companies and start-ups, though, the idea of a product manager as an experimenter (or \u201cmad scientist\u201d) is not as fully distributed and accepted.<\/p>\n But all product managers work with data and spend hours every week studying it closely. Whatever the cycle of learning and iteration, the job cannot be done without accurate signals about what is working and how the software is actually being used, and this focus on managing what you can measure carries through all of these strands mentioned so far\u2014business, engineering, and entrepreneurial experimentation.<\/p>\n The most recent archetype to contribute their superpowers to the ideal product manager is one you should be familiar with: the designer.<\/p>\n The experimental product manager is already more of a creative type than a simple number cruncher or bean counter. This person is someone who is intensely exploring possibilities and looking for ways to discover new solutions to acute problems.<\/p>\n The rise of user experience design in all its various forms, alongside the business-school friendly notion of \u201cdesign thinking,\u201d coincided in the culture with widespread awareness of the creative mythology of the Apple computer, the heroic figure of Steve Jobs, and for design aficionados, Jobs\u2019s collaboration with industrial designer Jonathan Ive.<\/p>\n Suddenly, creative founders were getting funding for their own start-ups. Other start-ups were making their first design hires much earlier in the process. Design (or \u201cdesign thinking\u201d) offered proven methods for harnessing creativity and inventing innovative solutions to interesting problems.<\/p>\n Product management evolved as well. At first, PMs paid lip service to UX design, made their own wireframes based on zero research, and asked designers to, more or less, color them in. But now product practitioners take user experience research and design seriously as core disciplines with invaluable, necessary skills and techniques. They also foster mindsets that are required to develop product experiences that people will love and return to again and again.<\/p>\n The lean movement had already shifted its focus emphatically onto the customer (or potential customer). Conveniently user experience research and design revolves around this exact same obsession! UX has methods and traditions for learning from customers, and provides systems and models and tools for exploring and communicating solutions.<\/p>\n Design also excels at redefining problems and questioning prior assumptions, and much like UX design leads, product managers are charged with inspiring and rallying creativity in others. So alongside the business heads, coders, and founder types turning into product managers, some user experience designers, managers, directors, and VPs now jump to the adjacent product track as their careers evolve.<\/p>\n Great product managers tend to have the following personality They are curious<\/em> almost to the extent of feeling like a busybody, being nosy, wanting to \u201cknow all the things,\u201d keeping tabs on everything, and being incredibly \u201chigh context\u201d and thorough about understanding.<\/p>\n They are connecting<\/em> in the sense of constantly \u201cconnecting the dots\u201d to form the big picture, orchestrating the performance, keeping people in the loop, providing the glue or lubrication or the circulatory fluid or whatever metaphor you prefer for the combination of emotional intelligence, \u201csoft skills,\u201d and implicit ties that enable teams to thrive and work well.<\/p>\n And they are courageous<\/em> in the sense of being brave enough to take risks, make mistakes, face problems square on, evaluate failures coldly, and learn ferociously from every experience, good or bad. This courageous behavior sets a tone that encourages others to try harder and seek more difficult goals.<\/p>\n OK, so now you know what product managers are responsible for (value and focus), where product managers came from (from all over), and what makes a good product manager (business sense, entrepreneurialism, technical chops, experimentalism, creativity, inquisitiveness, emotional intelligence, and courage\u2014easy peasy, right?).<\/p>\n But how does a PM apply that mix of skills and aptitudes to fulfill these responsibilities? What are the primary activities, processes, and tasks of a product manager, or in other words, \u201cWhat exactly does a PM do all day?\u201d<\/p>\n For a day in the life of a product manager, check out the section \u201cA Typical Day\u201d in Chapter 2, \u201cDo You Want to Be a Product Manager?”<\/p>\n Back to Product Management for UX People<\/em><\/a><\/p>\n","protected":false},"excerpt":{"rendered":" This is a sample chapter from Christian Crumlish\u2019s book\u00a0Product Management for UX People: From Designing to Thriving in a Product World. 2022, Rosenfeld Media. Chapter 1: What Exactly Does a Product Manager Do? If you\u2019re not sure what product managers do, you\u2019re not alone. Quite a few hiring managers\u2014not to mention entire businesses\u2014are also confused … Continued<\/a><\/p>\n","protected":false},"author":150108,"featured_media":0,"parent":0,"menu_order":0,"comment_status":"closed","ping_status":"closed","template":"","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":""},"acf":[],"_links":{"self":[{"href":"https:\/\/rosenfeldmedia.com\/wp-json\/wp\/v2\/pages\/192768"}],"collection":[{"href":"https:\/\/rosenfeldmedia.com\/wp-json\/wp\/v2\/pages"}],"about":[{"href":"https:\/\/rosenfeldmedia.com\/wp-json\/wp\/v2\/types\/page"}],"author":[{"embeddable":true,"href":"https:\/\/rosenfeldmedia.com\/wp-json\/wp\/v2\/users\/150108"}],"replies":[{"embeddable":true,"href":"https:\/\/rosenfeldmedia.com\/wp-json\/wp\/v2\/comments?post=192768"}],"version-history":[{"count":1,"href":"https:\/\/rosenfeldmedia.com\/wp-json\/wp\/v2\/pages\/192768\/revisions"}],"predecessor-version":[{"id":192770,"href":"https:\/\/rosenfeldmedia.com\/wp-json\/wp\/v2\/pages\/192768\/revisions\/192770"}],"wp:attachment":[{"href":"https:\/\/rosenfeldmedia.com\/wp-json\/wp\/v2\/media?parent=192768"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}Chapter 1: What Exactly Does a Product Manager Do?<\/h2>\n
Product Management Is Responsible for Value<\/h3>\n
A Product Manager Is Not<\/em> a Project Manager<\/h3>\n
Forget PrM or ProM, too, as potential abbreviations\u2014still no distinguishing characters. And I haven\u2019t met anyone yet who wants to go around calling them ProjMs and ProdMs, or PjMs and PdMs for that matter. In this book, PM stands for product manager.<\/ul>\n
A Product Manager Is Not<\/em> a Product Owner<\/h3>\n
A product manager orchestrates the efforts of a cross-disciplinary team to ship software experiences as part of accomplishing strategic business goals.<\/ul>\n
A product owner is a person who shapes and guides the engineering team as they develop software. In this model, they are a bit like a very tactical product manager, but one who is primarily focused on the tracking tasks. This is an engineer-centric role invented in the absence of true product managers.<\/ul>\n
\nmost businesses would call a head of product<\/em> or what some academic
\nprojects would call a primary investigator<\/em>.<\/p>\nWhere Did Product Managers Come From?<\/h3>\n
\n
\nweb and sometimes with native app clients, and resistant to some of the finite constraints of the manufacturing process (sunk costs, waterfall processes, and limited ability to make affordable changes once the product starts shipping).<\/li>\nProduct Manager as Business Manager<\/h4>\n
Product Manager as Marketing Manager<\/h4>\n
\n
Product Manager as Engineering Manager<\/h4>\n
\n
I still fondly recall a day I spent on the Google campus being interviewed and taken to lunch by a sequence of 11 white men of varying ages and hair colors and degrees of athleticism or geekiness. Many of the interviews were a lot of fun and, to be honest, I\u2019ve always liked puzzles, although not so much under pressure with big bucks at stake. They rotate these questions over time so that you can usually find expired examples with a little searching. For example, I was asked at one point how an algorithm might work to efficiently zero in on the correct five-digit passcode on a keypad, given certain rules or constraints about the numbers (to do with repetition, etc.). As I said, it was almost fun.<\/ul>\n<\/li>\n<\/ul>\n
Product Manager as Experimental Explorer<\/h4>\n
\n\u201cBuild, measure, learn\u201d is a simple but powerful model that lies at the heart of lean product management, with its bias to action and emphasis on learning and experimentation.<\/em><\/p>\nProduct Manager as Creative Artist<\/h4>\n
Three Other Traits Shared by All Great Product Managers<\/h3>\n
\ncharacteristics:<\/p>\n\n
So What Does a PM Do?<\/h3>\n
Key Insights<\/h4>\n
\n