Document Actions
Product Companies Need Product Managers, Not Product Owners
with Rich Mironov, Chief Marketing Officer at Enthiosys
Product Managers are responsible for the overall market success of their products, not just delivery of software. In the Agile world, a new title is emerging -- the Product Owner -- which covers just a small subset of the Product Management role.
While this makes sense for internal IT groups that have traditionally gone without Product Management, Agile product companies (that need to deliver customer revenue with their offerings) need full-fledged Product Managers to drive strategic activities and manage organizational/external participation.
What kinds of market failures can we expect when there's (only) a Product Owner assigned to revenue-producing projects?
Watch "Product Companies Need Product Managers, Not Product Owners"
|
|
About the Presenter
Rich is a software product strategist and veteran of four high-tech startups. He is considered one of the pre-eminent experts on software product management and marketing. He joined Enthiosys in July 2007 and heads its marketing and business development activities.
Rich started his technology industry career in 1981 as a software engineer at Hewlett-Packard. He managed networking products for six years at Tandem Computers, including launching the firm’s TCP/IP offering. He then joined Sybase to oversee the product team responsible for making the firm’s database software run on more than 40 operating systems. In the mid-1990s, Rich created and managed Sybase’s Internet Products Group, whose web.sql product was the first commercial solution for dynamic linking of Web pages with databases.
After Sybase, he worked at four Silicon Valley companies: Wayfarer Communications (acquired by Vantive in 1998), iPass (where he headed product management and product marketing), Slam Dunk Networks (VP of marketing) and AirMagnet (VP of marketing), the latter of which is the leader in wi-fi security analysis and remote troubleshooting.
Prior to joining Enthiosys, Rich had consulted to more than 20 large and small technology companies on business strategy, product strategy and market analysis. He also has been an interim vice president of marketing and product management at some of these firms.
Author of the popular “Product Bytes” newsletter on technology product strategy and upcoming book “The Art of Product Management,” Rich is a highly sought after speaker and writer on technology and technology product strategy. He is on the faculty of the Executive Development Center at the University of California Berkeley’s Haas School of Business and a peer reviewer for the California Management Review. In addition, he serves as VP Marketing for the Northern California Product Development and Management Association (Norcal PDMA).
Rich has an M.B.A. from Stanford University, where he was named an Arjay Miller Scholar, and a B.S. degree in physics from Yale University (with a thesis on dinosaur extinction theories).
Contact Rich: rmironov@enthiosys.com
coaching Agile
Posted by
Rich Mironov
at
2008-10-26 11:19 AM
The upcoming Pragmatic "Living in the Agile World" course is a great place to start. It's very (very, very!) important, though, that you're clear about your role and who you'd coach.
IMHO, proJECT managers can train up as scrum masters and coach the development side of agile, the "inner loop" I talked about. That's all about helping the team get software built.
As a group, proJECT managers don't have the outward customer/business/marketing/sales expertise to take on proDUCT management without a lot of field experience. Consider becoming a field sales engineer for a while, or joining a product management team where someone can be your mentor for several quarters.
IMHO, proJECT managers can train up as scrum masters and coach the development side of agile, the "inner loop" I talked about. That's all about helping the team get software built.
As a group, proJECT managers don't have the outward customer/business/marketing/sales expertise to take on proDUCT management without a lot of field experience. Consider becoming a field sales engineer for a while, or joining a product management team where someone can be your mentor for several quarters.
incent the masses
Posted by
James McGeady
at
2008-10-24 08:33 PM
How do you incent the masses (customers) to participate in process? The showcase customers have a large investment, not all do though. good customer business people are busy running the business, no?
incenting the masses
Posted by
Rich Mironov
at
2008-10-26 11:19 AM
You can't! Most customers don't have the time/interest/energy to be serious showcase customers. So you'll need to do real market research (ahead of your sprints) to understand what the broad market wants. Showcases are best for making sure you haven't strayed too far during the dev process, NOT for making broad market decisions.
Take a look at http://www.enthiosys.com/insights-tools/beta/ for some related thoughts.
Take a look at http://www.enthiosys.com/insights-tools/beta/ for some related thoughts.
on working with customers
Posted by
Steve Johnson
at
2008-10-26 11:19 AM
I've found customers quite willing to spend an hour or an afternoon with a product manager. They will be reluctant if they think you're trying to sell them but quite delighted when they find that you're seeking their council and advice. It's with product managers that I've found the reluctance. It's easy to stay in the office and let email and meetings make you feel productive. It seems harder to call a customer and request an appointment. Try it. Make ten calls to your customers and see what you learn.
As the proverb says, "a journey of a thousand miles begins with a single step."
As the proverb says, "a journey of a thousand miles begins with a single step."
"small p"
Posted by
Tom Chan
at
2008-10-24 08:33 PM
What do you recommend for small companies trying to execute all the product management boxes but end up spending most their time doing "small p" product owner tasks ... the product marketing and strategy tasks are not getting done ...
strategic work displaced by tactical items
Posted by
Rich Mironov
at
2008-10-26 11:19 AM
I'd rephrase this as "I'm stuck int he hour-to-hour details and am not getting to any of the strategic tasks." The Pragmatic team recommends setting one day each week as "product management day" and making sure to work the most important things then -- customer meetings or phone discussions, market analysis, positioning, setting priorities, building repeatable tools.
You may need to block out a series of 2-hour meetings on your calendar and only invite yourself, so other folks see your time as taken...
You may need to block out a series of 2-hour meetings on your calendar and only invite yourself, so other folks see your time as taken...
Doing it all
Posted by
Tom Chan
at
2008-10-27 04:50 PM
What is the reality that a single person, from a skill set and bandwidth viewpoint, can execute on all the responsibilities of a product owner (for agile development) and a product manager ("boxes" in the Pragramatic Marketing framework)? If you have limited resources what are the most important functions/boxes?
focus focus focus
Posted by
Steve Johnson
at
2008-10-28 04:27 PM
Whether agile or not, product managers need to focus on the important items, not just the urgent ones. Easy to say, tough to do, I agree.
Identify the most important tasks in the Pragmatic Marketing Framework and allocate time to accomplish those tasks. That's why we recommend that product managers allocate one day each week to get their work done.
Developers want a 24/7 market encyclopedia in the product owner. Guess what? sales does too. And so does marketing. And that's why product managers must find a smarter way to support development, marketing, and sales.
See http://www.pragmaticmarketing.com/publications/topics/01/0105sj for more.
Identify the most important tasks in the Pragmatic Marketing Framework and allocate time to accomplish those tasks. That's why we recommend that product managers allocate one day each week to get their work done.
Developers want a 24/7 market encyclopedia in the product owner. Guess what? sales does too. And so does marketing. And that's why product managers must find a smarter way to support development, marketing, and sales.
See http://www.pragmaticmarketing.com/publications/topics/01/0105sj for more.
Product Owner Groups
Posted by
Mark Rolufs
at
2008-10-24 08:33 PM
What are your thoughts on employing Product Owner Groups (a small p and a Big P working together)?
small p, Big P
Posted by
Rich Mironov
at
2008-10-26 11:19 AM
As I mentioned, I don't actually believe that 'Big P' Product Owners exist except with more well-recognized titles -- the most important of which is "product manager."
So a 'small p' product owner is a good addition to a team that already has a Product Manager (Big P, Big M) when the PM needs additional resources or the development team is geographically distributed.
So a 'small p' product owner is a good addition to a team that already has a Product Manager (Big P, Big M) when the PM needs additional resources or the development team is geographically distributed.
Question
Posted by
Kevin Dore
at
2008-10-24 08:33 PM
Rich mentioned using certain words to convey urgency to the developers, how exactly do you do that without sounding whiney.
on urgency
Posted by
Steve Johnson
at
2008-10-26 11:19 AM
Agile should actually fight malaise. I've found developers want to be associated with successful products. Agile methods allow them to deliver more faster--which is why agile is taking root in most companies.
What you may be experiencing is pressure from management to work 100 hours weeks for an arbitrary deadline. Agile teams learn to work reasonable hours to reasonable deadlines and can show progress. The progress can be mapped clearly in status to management.
Represent the needs of the company and the market to the agile team. No need to sound whiny.
What you may be experiencing is pressure from management to work 100 hours weeks for an arbitrary deadline. Agile teams learn to work reasonable hours to reasonable deadlines and can show progress. The progress can be mapped clearly in status to management.
Represent the needs of the company and the market to the agile team. No need to sound whiny.
the small p product owner
Posted by
Sabra Goldick
at
2008-10-24 08:33 PM
Question for speaker: the small p product owner sounds similar to a traditional program manager. Is that who you recommend to fill the role?
defining product owners
Posted by
Rich Mironov
at
2008-10-26 11:19 AM
Program managers typically manage resources (people, budgets) and are responsible for reporting status against schedules. They don't make decisions about priorities or requirements or market segments or personas. They do try to keep projects running smoothly and deliverables flowing. They are not product *managers* and not product *owners*.
My major point is that every revenue product needs a product *manager* but that most do not need product *owners*. Look at the last few slides for situations when I recommend both a PM and a PO.
My major point is that every revenue product needs a product *manager* but that most do not need product *owners*. Look at the last few slides for situations when I recommend both a PM and a PO.
Question
Posted by
Eileen Stuber
at
2008-10-24 08:33 PM
How do you meet face-to-face with customers when they're spread all over the country?
Meeting customers
Posted by
Rich Mironov
at
2008-10-26 11:19 AM
You'll need to map out a series of trips and methods to do this. (One trip won't do it.) Plan to do several of:
-- arranging weekly phone conversations with current customers: 20-30 minutes to hear about their situation/issues/usage/experience
-- plan ahead with one trip/quarter to major cities, and line up meetings months in advance
-- going to user group meetings where you can set up 3-5 back-to-back meetings
-- go on some sales calls (but don't talk unless the rep asks you to)
-- put yourself on the speaker roster for your customer briefing center
-- arranging weekly phone conversations with current customers: 20-30 minutes to hear about their situation/issues/usage/experience
-- plan ahead with one trip/quarter to major cities, and line up meetings months in advance
-- going to user group meetings where you can set up 3-5 back-to-back meetings
-- go on some sales calls (but don't talk unless the rep asks you to)
-- put yourself on the speaker roster for your customer briefing center
face to face means travel
Posted by
Steve Johnson
at
2008-10-26 11:19 AM
The best way to see a customer's problems is to use your eyes instead of your ears. Developers are right: customers don't know what they need. Go onsite and watch a customer and you'll see problems that no one has every articulated.
So look for ways to extend authorized travel to include a few customer visits. Stay over after a sales call; go to a trade show and call on a customer the next day before you fly home.
A phone call is infinitely better than nothing but a face-to-face visit is infinitely better than a phone call.
So look for ways to extend authorized travel to include a few customer visits. Stay over after a sales call; go to a trade show and call on a customer the next day before you fly home.
A phone call is infinitely better than nothing but a face-to-face visit is infinitely better than a phone call.
Agile development team serving multiple PM's?
Posted by
Jeff Wright
at
2008-10-24 08:33 PM
Is it strange to have a single Agile development team serving multiple PM's? How can a remote PM situation work where PM is across the country from the rest of the company (including development, marketing, much of sales, etc)?
one team, one project
Posted by
Steve Johnson
at
2008-10-27 04:50 PM
Agile teams should be dedicated to a single project so that there is a single voice of priority. One team, one project= one product manager and one prioritized list. For more on this, see http://www.pragmaticmarketing.com/publications/topics/07/one-voice-of-priority/ for more on this.
Embracing Agile
Posted by
Greg Davidson
at
2008-10-24 08:33 PM
In embracing Agile, how do you provide the confort to the Executive level without having those typical Release Requirements/Definition etc. - detailed documentation - is it really just an investment on an ongoing interaction perspective, or is there something else that works well?
Executive comfort
Posted by
Rich Mironov
at
2008-10-26 11:19 AM
Your execs don't actually want MRDs. (Have you ever seen an exec read one?) What they really want is some assurance that products will be shipped and functional. You'll need some investment with them, sure, but focus on what's new and positive about agile:
-- sprints result in truly complete features/functions, which are 100% done-done. This marks actual progress. Execs are used to hearing that software is 80% done right up until the moment you slip the project 6 months
-- focus them on high-level user stories. These tell execs what the product will do, and who it will do them for. They don't care about the details.
-- sprints result in truly complete features/functions, which are 100% done-done. This marks actual progress. Execs are used to hearing that software is 80% done right up until the moment you slip the project 6 months
-- focus them on high-level user stories. These tell execs what the product will do, and who it will do them for. They don't care about the details.
Question
Posted by
mofazzal bhuiyan
at
2008-10-24 08:33 PM
How to make sales team 'buy' agile dev of product release?
Getting sales to "buy"?
Posted by
Rich Mironov
at
2008-10-26 11:19 AM
Sales doesn't get any say in how Engineering builds software. They have to sell what the company produces. Once you get Agile working smoothly, Sales *might* be happier -- with faster releases and higher quality and fewer late-stage disasters -- but they don't get a vote. Instead, they get a quota.
Turning this around: should your engineering team spend time pushing Sales to adopt consultative selling (or any other sales methodology)? No. Sales isn't interesting in what Eng'g thinks about sales techniques.
Consider http://www.enthiosys.com/insights-tools/friendy-pricelists/
Turning this around: should your engineering team spend time pushing Sales to adopt consultative selling (or any other sales methodology)? No. Sales isn't interesting in what Eng'g thinks about sales techniques.
Consider http://www.enthiosys.com/insights-tools/friendy-pricelists/
on sales
Posted by
Steve Johnson
at
2008-10-26 11:19 AM
Honestly, you shouldn't have to sell agile to sales. Show them by the results. Deliver more, faster with more confidence.
For most companies, the old techniques meant that sales people made promises to customers and were disappointed when development delivered less. With agile approaches, we can be assured that what we promise will be delivered. That means introducing some discipline in what we tell sales. Tell them what you KNOW, not what you HOPE.
Many sales people want guarantees of what will be in the next release. The real question is "how well have we done this in the past?"
For most companies, the old techniques meant that sales people made promises to customers and were disappointed when development delivered less. With agile approaches, we can be assured that what we promise will be delivered. That means introducing some discipline in what we tell sales. Tell them what you KNOW, not what you HOPE.
Many sales people want guarantees of what will be in the next release. The real question is "how well have we done this in the past?"
Question
Posted by
Jeff Berg
at
2008-10-24 08:33 PM
How do you deal with a dev org that want PMs to stay out of the "how" and just do the "what"?
how vs what
Posted by
Steve Johnson
at
2008-10-27 04:50 PM
Developers and engineers are natural problem solvers so give them problems to solve. The old rule has always been that product management focuses on the 'what' (and the 'who' and 'why') so that development can focus on the 'how'. Product managers should still focus on problems (and the people who have them) and stay out of designing solutions (the how). Rich's point was that agile teams reveal more of the "what" to product management than traditional methods. A "team" should be working closely together and so product managers can see the results more quickly than in other approaches.
A co-located dev team
Posted by
Steve Sigal
at
2008-10-24 08:33 PM
Even if we have a co-located dev team - how do we effectively balance "being there" for the Dev team and being on the road talking to customers and prospects ensuring that we are capturing market problems?
Being there, being on the road
Posted by
Rich Mironov
at
2008-10-26 11:19 AM
You absolutely must get out of the office to be effective, so plan ahead. Make sure you're in the office for sprint planning and retrospective meetings, and schedule some explicit slots with the team to go over backlogs and issues. That way, you can anticipate many of their requests rather than letting them drive your calendar. Also, present your customer findings to the team when you get back -- that helps give them a market sense so they can make some decisions for themselves.
Product Managers
Posted by
Jonathan Skypek
at
2008-10-24 08:33 PM
Does it make sense if you have a Product Owner that filters and represents several product managers from several business lines?
One product owner to many product mgrs?
Posted by
Rich Mironov
at
2008-10-26 11:19 AM
This is a catastrophe waiting to happen.
At best, a product owner works on one release of one product/service under the direction of one product manager.
As this talk's title suggests, every product needs a product manager. This is the ONE PERSON who takes input from the world and determines priorities and product strategy and customer segments and personas, etc. Someone who applies JUDGMENT and EXPERIENCE and TRAINING and LONG-TERM THINKING to a product plan.
Your configuration sounds like asking a random busload of commuters how you should invest your retirement money, and expecting them to give you coherent advice.
At best, a product owner works on one release of one product/service under the direction of one product manager.
As this talk's title suggests, every product needs a product manager. This is the ONE PERSON who takes input from the world and determines priorities and product strategy and customer segments and personas, etc. Someone who applies JUDGMENT and EXPERIENCE and TRAINING and LONG-TERM THINKING to a product plan.
Your configuration sounds like asking a random busload of commuters how you should invest your retirement money, and expecting them to give you coherent advice.
Small p
Posted by
David Proctor
at
2008-10-24 08:33 PM
Does "small p" product owner equate to a business analyst role within the product management framework? what if product managers can be agile quickly but the development organization is not agile. How do you change the development organization?
small p equates to...
Posted by
Rich Mironov
at
2008-10-26 11:19 AM
There's no clear mapping for small-p product owners. Business analysts and requirements analysts are good candidates *if* you need one... if this is an internal IT effort or prod mgmt needs the additional coverage.
Make sure FIRST that you have a product manager assigned [if this is a revenue-generating project or strategic to the organization] and that your product mgmt team believes it actually needs a product owner (or business analyst or requirements analyst).
Make sure FIRST that you have a product manager assigned [if this is a revenue-generating project or strategic to the organization] and that your product mgmt team believes it actually needs a product owner (or business analyst or requirements analyst).
Hardware Environment
Posted by
Lourdes Valdez
at
2008-10-24 08:33 PM
Can agile work in a hardware environment? If so, what are the limitations?
LEAN = agile for hardware
Posted by
Steve Johnson
at
2008-10-27 04:50 PM
LEAN is an agile method that originated in Toyota. We're now seeing adaptations of LEAN for suse in software projects. See http://en.wikipedia.org/wiki/Lean_software_development for more. For LEAN in hardware, see http://en.wikipedia.org/wiki/Lean_manufacturing
MRD
Posted by
Lauren Brimmer
at
2008-10-24 08:33 PM
At the beginning of a 'new' program of fairly large scale, would you still recommend an MRD?
MRD = a prioritized list?
Posted by
Steve Johnson
at
2008-10-27 04:50 PM
The term MRD (market requirements document) seems to cover a wide range of documents, different in each organization. Before a project begins, the team should have a scoping document that includes market segments, personas, major goals or problem areas, and perhaps other business rationale. Is this an MRD?
What it's not is a verbose document that identifies every feature that will be delivered. The team will design features that address the problems found in the MRD.
What it's not is a verbose document that identifies every feature that will be delivered. The team will design features that address the problems found in the MRD.
SW Implementations and Support
Posted by
Kathleen Neben
at
2008-10-24 08:33 PM
any comments you have regarding SW implementations and support - especially for brand new solutions
Question