Quantcast

Bruce McCarthy is Founder and Chief Product Person at UpUp Labs, where he and his team are at work on Reqqs - the smart roadmap tool for product people.

« NetProspex Is Looking for a Great Product Manager | Main | Netflix Abandons Quikster »
Saturday
Oct222011

A Product Manager Persona

Young Jedi product manager

Surveys from Pragmatic Marketing, Jama and Quantum Whisper paint a pretty detailed picture of a product manager and his or her job. I've assembled this composite persona from that information, my own experience, and many discussions with other PMs over coffee or beers.

I've recorded it here to get your input and feedback. Is this you? Is it like other PMs you know? With your help, this will form the core user and buyer persona for a simple, affordable requirements and roadmap tool. Let me know what you think in the comments below.

Luke the Product Manager

Luke is a product manager in the software industry. He’s 39 years old and has a college degree. He wonders if he should go back to get his MBA because many of his colleagues have one but he doesn't have the time because he is already working 50-60 hours a week. He makes $117k per year in total comp, including a bonus he gets most of, most of the time.

Luke's Team

Luke is one of a group of 6 product managers at his company, reporting to the VP of Product Management who reports to the CEO of his company. Luke is responsible for 3 products and $23 million in annual revenue.

He works as part of a small development team of 18 people. The team is spread out over multiple locations and time zones, so Skype and Microsoft SharePoint are every day tools for him. Recently, however, he’s also been looking at Google docs for sharing.

Luke's Job

He’s good at his job but puts in long hours, including frequent evening and weekend work, and never feels as though he’s really caught up. He wants to spend more time talking with customers, doing win/loss analysis and thinking strategically about the future of his market and where his product should go. Instead, he spends many hours composing, organizing, prioritizing and communicating requirements to engineering and to the many other constituencies around the company that need to know about them.

As part of his job, Luke must gather information about market requirements and communicate information about these requirements and the status of development efforts to meet them to a variety of stakeholders, including people in marketing, sales, sales engineering, customer support, finance, development, architect, C-level management, partner, customer and prospect roles.

He’s getting more attention from the C-level execs at his company, which is gratifying and he assumes will be good for his career, but it is also creating more work in preparing materials suitable for that audience.

Luke is managing his first nominally Agile project, learning as he goes. The team is not following a pure Agile process, however, preferring to retain some of their established methods, habits and tools.

Luke's Process and Tools

Luke is a gadget hound, carrying iPhone and iPad wherever he goes. He meticulously records interview notes with customers in Evernote and captures feature requests in Excel. He dashes off UI mockups in Balsamiq.

Luke writes requirements in Word as a single Product Requirements Document, uses Excel to prioritize those requirements, and uses PowerPoint to communicate the committed roadmap.  Luke’s PRDs and Prioritized Feature Lists contain a lot of information and a large number of features to manage. He usually has to make multiple versions of each type of document as projects evolve, and it is a challenge to keep them all up to date and in sync. 

Luke enters features into JIRA one at a time once they’ve been agreed to. In that process, he modifies and makes the requirements more detailed, obsoleting those parts of the PRD and leaving unimplemented features orphaned in a doc no one will look at again.

Luke wishes he had a tool for managing requirements that was easier to use because it would save him a lot of time and effort in maintaining and publishing his many disparate documents.

Luke's Work Style

Luke is fairly technical, thanks to his background in engineering and as a sales engineer. He is also an excellent communicator, which makes him good at bridging the gap between business problems and what Engineering needs to know to solve them.

He is a good listener, very easy to approach and talk to. He likes learning about people's jobs, their challenges and goals. Luke asks good questions. He is also very analytical and does a good job synthesizing all he learns into a coherent plan. His most difficult challenge is prioritizing the myriad requests and ideas he gets for features, bug fixes and other work in a way that serves the strategic needs of the company, keeps customers and other stakeholders happy, and can be explained clearly and defended using objective criteria.

Does this sound like you? Post your thoughts in the comments.

References (5)

References allow you to track sources for this article, as well as articles that were written in response to this article.

Reader Comments (13)

Luke can't tell you how many times he's wanted to take his lightsaber to the salesperson who passionately demanded a feature one day only to be unmoved when it shipped, saying: "oh, we lost that deal anyway."

October 22, 2011 | Registered CommenterBruce McCarthy

Its gud that luke has all qualities which a product manager should have.

Nice Job. This is a great composite.
Luke is also very creative and likely dabbles in Art, Music, or etc. He is very open minded, loves to learn, and especially loves to imagine what the future will be like. But he doesn't just want to imagine it, he wants to create it. He has a passion for bringing things from his somewhat overly active imagination into the real world.

October 23, 2011 | Unregistered CommenterTom S. Coleman

Good additions, Tom. A creative, artistic temperament didn't turn up in the research but it certainly matches up with the people I know!

October 23, 2011 | Registered CommenterBruce McCarthy

I think it's also worth mentioning Luke's discretionary budget is small. While he is responsible for millions in revenue and may drive a multi-hundred-thousand-dollar OEM deal, his ability to make a case for purchasing and adopting tools is quite limited. To avoid a protracted and risky negotiation with the CFO, he would need a tool to be sub-$100 one time or sub-$50/mo recurring.

October 23, 2011 | Registered CommenterBruce McCarthy

Need to say more about Luke's company culture. Not all orgs are right for Luke and Luke won't be right for all orgs. How large is Luke's company? Is it growing fast? If so, how quickly? Steep company growth curve is a huge benefit for many pms but can be daunting for those used to more bureaucracy. Is Luke's org very customer centric (prone to more on the fly, incremental innovation)? Product centric (prone to more bold, qualitative innovation)? Is it a turnaround situation? Fortune 500 with Wall Street and Sarbanes-Oxley to deal with. You get the picture, Yoda, right? ;-)

October 25, 2011 | Unregistered CommenterLarry Friedberg

Good thoughts, Larry. I'm thinking the org is small (because most are) and fast-growing with no established penchant for customer or product-centricity. I have little hard data for this other than conversations with other PMs, though.

I'm also thinking the analyst in him can't help but want some process around things but is often overruled by his internal entrepreneur that wants to get things out to market.

October 25, 2011 | Registered CommenterBruce McCarthy

If all of Luke's teams were really using agile, his job would be a lot easier, and his needs from the tool would be a lot different, I think.

Awesome example of a persona. I'm not qualified to comment on how well it describes a Product Manager, but I'd work with Luke any day! (Does he need a project manager?)

October 27, 2011 | Unregistered CommenterJaron Lambert

I'm an agile fan myself. I definitely see it helping teams I've worked with to move faster, deliver more and better product, and work as a more cohesive unit. That said, it seems every organization has its own flavor due to personalities, history, dependencies on other parts of the organization or a variety of other factors.

I think that presents a real challenge to any tool designed to support the PM or any other member of the team. I've worked a lot with JIRA and it tackles this problem with extensive customizability. That comes with its own cost, though, in complexity and manageability.

I'd like to propose that an alternative way to deal with this - at least for a single-purpose tool like a requirements manager - is to go in the opposite direction and provide a very, very simple tool that doesn't implement any particular methodology but is lightweight enough to support any.

Product managers need to manage requirements. Those might be in the form of "the system shall" or "as a user, I want to," but the process around gathering, prioritizing them is the same. They might be output onto a PRD, into a bug-tracking system or into Kanban cards, but the basic job of the PM is the same.

That's my theory, anyway, FWIW.

October 27, 2011 | Registered CommenterBruce McCarthy

Bruce,

As much as I appreciate the comparison to a Jeti Knight, Product Managers have no "Force" with which they can influence their constituents, stakeholder or engineering. Product Managers do, however, have perspective into the worlds of both constituents and are in the best position to "define the road map", "call the shots", "tip the scale". Unfortunately, I think many PMs become nothing more than scribes of the agreements between stakeholders and engineering. Then, they become the whipping boy when the agreement breaks down.

To avoid this spiral, the stakeholders and engineering teams must accept the PM as, in fact, the guy that calls the shots. This requires a great deal of trust. The PM has to be enough of an engineer to be accepted by engineering as "one of them" and enough on a businessperson to be accepted by the stakeholders as "one of them" too.

More than that, I think PM's should be able to imagine the future - connect need with technology in an elegant way or at least an efficient way. The PM should stay current in both realms, their industry and the applicable technologies.

More often than not, I suspect the PM is likely to have begun life as an engineer and migrated toward business. Though, I suppose the opposite is possible. The engineer with a BA or MBA should be worth more than $117k - don't you think? Otherwise, why would the engineer leave coding?

I'd me interested to hear your thoughts on PM growth path Sr. PM? Exec PM? VP PM? CEO?

Thanks for including me!
Dave

November 7, 2011 | Unregistered CommenterDSprogis

I think you've got that balance between engineering and business right. In the end, the PM won't understand the technology as well as the engineers and won't understand the ins and outs of revenue recognition as well as finance people and won't be able to sell or market the product as well as the folks in those departments, but the PM is the hub where all those spokes come together.

Calling the shots is definitely part of the role, but in my experience a good PM can't do that alone. A PM has to effect change via influence rather than fiat. He or she must get input and provide a fair hearing to all of these folks because none of them report to him or her. But yeah, in the end the organization has to accept that the person is in the job to make decisions about what the product will and won't do. And it takes time for the PM to earn the necessary respect. The best way I've found to gain that respect is to have the best and most complete data about the market, preferably in quantitative form (75% of customers have x problem vs. only 25% that have y). This is where a good data-driven prioritization model comes in.

To quote a recent posting on LinkedIn, I think PMs are worth their weight on gold. $117k is the average salary according to Pragmatic Marketing's last survey, though. I understand they are working on the latest survey so we should have an update to that soon.

Career progression for PMs is problematic and inconsistent from my observation. PM teams are often small and though their influence is felt company-wide, compensation and promotion are often based on how many people work directly for you. So it can take some time in the field to become a director or VP of product. I've seen intermediate titles like senior, principal and so on. At ATG we even had managers of product management (team leaders). I've also met a number of PMs who haven't followed a linear path but have been directors and then gone back to individual contributor roles.

Although it's often said the PM is the CEO of their product, I have not met a product manager who was promoted to CEO of their company. That role seems to come almost exclusively from sales. On the other hand, PMs are entrepreneurial by nature and I know quite a few who have started their own company. Present company included. :)

November 7, 2011 | Registered CommenterBruce McCarthy

Luke hopes that Siri can listen to User discussion and lay it out in terms of a use case and a requirement doc so that he can travel to tradeshow and conferences :-)

November 21, 2011 | Unregistered Commenteranonymous

NAILED IT!!! Though I am a outlier to the demographic...I've passed through the faze described. Update on Luke: Being a proactive and well-connected gadget guy, Luke researched and found a number of low cost subscription SaaS tools to aid his requirements management and communications tasks. He is now facing difficulty and building a case to get approval to "add yet another tool" from a company heavily invested in Sharepoint and [fill in the blank] CRM platforms.

February 3, 2012 | Unregistered CommenterPat Scherer

PostPost a New Comment

Enter your information below to add a new comment.

My response is on my own website »
Author Email (optional):
Author URL (optional):
Post:
 
Some HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <code> <em> <i> <strike> <strong>