Joan Tyner at Thomson ReutersI'd like to download this presentation for some work I'm doing for a client; will definitely attribute material appropriately, joan.tyner@gmail.com4 weeks ago
Are you sure you want to
JEL888Hello, anyway to get a copy of this in pdf to use internally to share with PM team and Dev team. Need to show them a number of the slides during training to help everyone see who needs to do what. If I use any material verbatim, I'll definitely source you.2 months ago
aykhanVery good overview. For NEWBIES to PM function - focus on slide 10, 11 and 19. Not all PMS are equals - the scope of skills can range from high level functional to very technical knowledge (use case, demos, troubleshooting, etc.), a PM must also be good in sales and customer facing presentation, must be able to answer to PR, perform at public speaking event, etc. Make sure you understand the company, the products and the space - A solid PM must be politically very strong, has the ability to manage execs. up and across, always be customer connected,and excellent negotiators (comes handy with Engineering during scope creep bring in Sales and/or Customer's Requirements to reprioritize or provide options), enjoy public speaking, attention graber - good or bad, yes, take the blame and resolve all kinds of issues.1 year ago
Specifically talking about software, but in the broader context. We see all kinds of companies shipping products/services for revenue that include software, bundle software, depend on SaaS, etc. Let’s assume for now that almost all products are software, depend on software, or build in software.
So place to start is the basics of what a product manager does, then compare it to a product owner. We’re about two years behind. Dev doesn’t understand PM, and went ahead without us. In some ways, takes us back 25 years to the evolution of software product management
Emphasize three audiences, three languages, three challenges. Rest of talk is broken up into three sections, one each for customers, executives and development.
Pragmatic has done a great job of identifying what needs to happen. If you expect to make money on a product or service, these must get done by someone. Lots of ways to carve this if resources allow more than one person, after we acknowledge the necessity. (if this is new to you, lots of material on the prag site.)
For instance, “triad” configuration often recommended by Steve Johnson. Note that entire grid is covered. Or split left (PM) and right (PMM).
We know that we have impossible jobs.
See http://www.scrumalliance.org/articles/39-glossary-of-scrum-terms#1122 From CSM class materials. See http://www.controlchaos.com/certification/cspo.php CSPO: certified scrum product owner. 1-2 days classes, e.g. from Mike Cohn
www.enthiosys.com What does a typical 2-week iteration look like? • A living backlog of prioritized work to be done • A brief planning session in which the backlog items for the sprint will be defined: Team commits to work to be completed, identify tasks (and hours associated), collectively commits to getting it done during course of iteration • A brief daily meeting or scrum , at which progress is explained, upcoming work is described and impediments are raised: • 1.What have you done since the last scrum meeting? 2.What has impeded your work? 3.What do you plan on doing between now and the next scrum meeting? Review with Product Owner to review and accept/reject work Insert example of agenda . . . Insert example of retrospectives Iterations should not be longer than 4 weeks . . . .
Often PO is program manager, requirements analyst, user representative, business analysts… recruited into position without training or any PM experience Certainly, there are executives who would agree that they act as big product owners – but when you check their business cards you see titles like “Senior Product Manager” and “VP Product Management” and “COO, Network Security Products.” They don’t self-identify as product owners.
Plus team-related activities that were not part of traditional PM role: Process improvement and retrospectives Pitching in on broad team tasks including estimation, acceptance testing
“ In Scrum, a single person must have final authority representing the customer's interest in backlog prioritization and requirements questions. This person must be available to the team at any time , especially during the sprint planning meeting and the sprint review meeting.”
Responsible for
Defining the features of the product
Deciding release date and content
Profitability of the product (ROI?)
Prioritizing features according to market value
Changing features and priority between iterations
Accepting or rejecting work results
How developers have defined product management
Ideal Product Owner Must Be…
Omniscient, telepathic
Represent true market needs without spending a lot of time “in the field”
Manage complexities of detailed stories as well as marketplace financial tradeoffs
Very difficult to do “solo”
Nearly impossible without some product management experience
Product Owner’s Calendar Borrowed from Catherine Connor, Rally
Two Sizes of Product Owner
“ small p” product owner
Focus on iterations (up through releases)
User story elaboration, backlog management
Available to dev team hour by hour
Customer showcase (rather than primary market research)
Internal recruit, often limited product management experience
“ Big P” Product Owner, aka Chief Product Owner
Strategic view of customers, profitability, markets
Sets broad direction, owns resource allocation
Deep experience with customer segments
In my experience, “Big P” Product Owners call themselves:
VP/GM of Business Unit
VP Product Management
VP Engineering
PO/PM Organizational Map product owners Product Management Organization more technical more market-focused GM - VP PM - VP Eng/CTO
“ small p” product owner Development customer information, priorities, requirements, roadmaps, personas, user stories… software Marketing/Sales Customers Executives product owner
Adapted Pragmatic Marketing ® Framework product owner backlog, accept work stories, NFR burn down/up Process improvement retrospectives Team needs all-team tasks Pricing Buy, Build or Partner Business Plan Product Profitability Win/Loss Analysis Distinctive Competence Market Problems Marketing Plan Customer Acquisition Customer Retention Program Effectiveness Buying Process Buyer Personas User Personas Positioning Product Portfolio Market Definition Distribution Strategy Innovation Competitive Landscape Technology Assessment Lead Generation Thought Leadership Referrals & References Launch Plan Use Scenarios Require ments Status Dashboard Product Roadmap Presentations & Demos Event Support “ Special” Calls Channel Support Channel Training Sales Process Collateral Sales Tools Business Market Programs Planning Strategy Support Readiness Business Market Programs Planning Strategy Support Readiness
Much More to Do
IMO, Product Owner role adds 40-60% more work for a traditional product manager
PM is like to be overcommitted already
Too many constituents, queues, roles
Heavily time-sliced
PM capacity planning is a challenge
Natural for PMs to ignore how stretched they are
Agile highlights/worsens existing problem
Product Manager Failure Modes
Solo Product Manager fails the agile team if…
Part-timer, not fully engaged in team
Lack of detail on stories, acceptance tests
Stale items in backlog
Handwaving and bluster
Best of intentions, but pulled in too many directions
“ Build what I meant”
Product Owner Failure Modes
Solo Product Owner fails the market if…
Weak on actual economic value: pricing, packaging, upgrade barriers, professional services, discounting, competitive dynamics
Disconnected from cross-functional teams that turn software into products (Marketing, Sales, Support…)
Trading off company-wide product strategy in favor of product-level features
Substituting showcases for broad market input
Scalable PM/PO Models
People and organizations matter. Consider:
Small product, co-located team
Agile product manager is the product owner
Complex product
PM covers strategic/outbound, PO (TPM) for inbound
Report up through same PM management chain
Distributed teams
One or more PMs at main Eng location, heavy travel schedule
Every remote team has a PO (or PM)
Frequent, intense collaboration among all PMs/POs
Pool of PM/PO talent with strategic leadership
Larger departments, enough resources to allocate
Pair up, mix and match, share, segment, be creative
Recapping My Biases
Titles don’t matter, but activities and roles do
A seasoned Agile Product Manager can also be a Product Owner
Cover both roles for one moderately complex product
Heroically for two products?
A Seasoned Product Owner can rarely also be a Product Manager
Outbound coordination and Sales/Marketing/Field role don’t fit into schedule or expertise
Product Management and Engineering have a historically complicated relationship
Take-Aways
PM/PO: One of the reasons Agile delivers better software
Activities and roles matter more than titles…
Product Manager POV: Agile makes PM job bigger
Market demands and first-hand interactions don’t go away
Challenging for one PM to cover both roles
Product Owner POV: customers are the market
Need deep and complex market inputs to represent users/customers/markets
1–4 of 4 previous next Post a comment