Document Actions
Living in an Agile World: The Role of Product Management When Development Goes Agile
By Steve Johnson
For years, product management seems to be have been defined by what it is not as much as what it is.
Developers and engineers see product managers as technical resources, to be used for project management. Agile development methods seem to have made this orientation even worse, with product managers getting pulled into deeper tactical, technical activities. But spending so much time with internal, tactical teams means less time spent outside the company in the market. Executive management teams rely on product management as a strategic resource, the source for strategy and business thinking at the product level.
This session will explore the strategic role of product management in an agile environment, re-examining the concepts from our popular e- book, The Strategic Role of Product Management, with illustrations from agile methods and teams.
Watch the "Living in an Agile World: The Role of Product Management When Development Goes Agile" Webinar
Download the Webinar Slides and Templates
Download the Webinar (83 MB .mov)
Download the Webinar (34 MB .wmv)
Download the Webinar Slides
Get Notified of All Upcoming Webinars
About the Presenter
Steve Johnson is a recognized thought-leader on the strategic role of product management and marketing. Broadly published and a frequent keynote speaker, Steve has been a Pragmatic Marketing instructor for more than 10 years and has personally trained thousands of product managers and hundreds of company senior executive teams on strategies for creating products that people want to buy. He teaches several top-rated seminars including Practical Product Management, Requirements That Work, and Pragmatic Roadmapping, as well as many on-site workshops.
Prior to joining Pragmatic Marketing, Steve practiced the discipline of product management for over 18 years at a variety of software and hardware firms and served as head of marketing for the leading provider of performance management software.
Steve writes the Product Marketing blog.
Who leads the switch?
Posted by
Luke Hohmann
at
2008-10-12 11:57 AM
Most of the time, we see development teams leading the switch to Agile practices, which we think means that they are very receptive to going Agile. That said, development teams often resist going Agile, and if you're not in development, don't force an Agile process on your development team. Instead, educate and enlist them on the changes you propose. Incremental / Agile development practices tend to put more stress on the source code management / build system(s) because the dev team is branching and merging more frequently. As a result, we recommend that the dev team assess their SCM practices before going Agile and preparing for improvements.
Question
Posted by
Shawna Kelly
at
2008-10-10 08:36 PM
In your experience, how many small tech companies have their CEO and their sales team of 3 drive product strategy?
Sales/CEO driving product strategy
Posted by
Rich Mironov
at
2008-10-13 11:05 AM
This happens a lot, although it's often not good unless the CEO has some product strategy/management experience. One challenge is that early sales teams tend to follow the bouncing Purchase Order and generalize from 2 prospects to an entire market. A seasoned product manager (VP Prod Mgmt) adds discipline and longer-time thinking, so that the Dev team can stick to one solution long enough to finish it. Ditto with pricing/licensing (aka the business model), with sales people focused on simplistic prices low enough to close the first few deals. In my experience, an early product expert provides a rudder to the team.
How does Project Management work in Agile?
Posted by
John Moroney
at
2008-10-10 08:36 PM
How does Project Management work in Agile? How do you develop new product development schedules?
Release Planning is Essential
Posted by
Luke Hohmann
at
2008-10-12 11:57 AM
The heart of a project management is a believable plan created by the team based on the best information available at the time the plan was created. In Agile, this process is called release planning. A release plan is the expected number of iterations that the team is planning to take to complete the backlog items selected and prioritized by product management. The release plan is used to gauge the performance of the team and as a tool to adjust development efforts as new information becomes available. We typically add iterations at the end of the release plan to handle "end game" activities -- everything from localizing your user interface to performing certain forms of testing that may be cost prohibitive to perform in each iteration (such as third-party compliance testing).
Question of the Framework
Posted by
Gerry Callejo
at
2008-10-10 08:36 PM
You mentioned the upper left corner of the framework is relevant to executives, how do you get them to concentrate on these elements without feeling that the product mgr covers a greater area that may threaten their overall product knowledge?
product manager and strategy
Posted by
Steve Johnson
at
2008-10-16 03:56 PM
Executives continue to tell us that they want product managers to focus on strategic product direction. Frankly they don't seem to understand why product managers can't seem to get anything done. They really don't see the daily operational pressure that product managers are under, answering technical product questions for development, marketing, and sales.
Tactical product managers get no respect from the senior executives. It's sad if you're caught in the Catch-22 of it: if you only support sales and development, you get fired for it; yet the demands to support them are incessant.
In the end, whether they (or you) realize it or not, the executive team holds product management responsible for strategy.
If your executives want to dabble in product management--and they all do--just ask them to write it down and keep it current. That'll shut 'em up. :-)
Tactical product managers get no respect from the senior executives. It's sad if you're caught in the Catch-22 of it: if you only support sales and development, you get fired for it; yet the demands to support them are incessant.
In the end, whether they (or you) realize it or not, the executive team holds product management responsible for strategy.
If your executives want to dabble in product management--and they all do--just ask them to write it down and keep it current. That'll shut 'em up. :-)
Who should "own" usability?
Posted by
julie miller
at
2008-10-10 08:36 PM
Who should "own" usability...user interface design...should it be PM or within the R&D team? my usability question relates to the fact that PM and R&D are collaborating regularly in an agile way, but the process slows down when it comes to where to put buttons, which font, etc.
problem and solution
Posted by
Steve Johnson
at
2008-10-11 06:38 PM
We task the product manager to be the expert in problems; the development team should accept responsibility for the solution. The design of the user interaction is part of the solution and therefore part of development. Some product managers like to dabble in design; some developers refuse to. Most teams need a full-time user interaction (UX) designer.
Our annual product management survey reveals that most product teams have 1 product manager, 1 designer, and 1 development lead. I suspect you need to supplement your team with a qualified UX designer.
Our annual product management survey reveals that most product teams have 1 product manager, 1 designer, and 1 development lead. I suspect you need to supplement your team with a qualified UX designer.
Tips on the Grid
Posted by
Tammy Mathews
at
2008-10-10 08:36 PM
Any tips you can share for working the grid when there is only one PM in the company and the company is too small to pull others in to owning portions of the role?
focus focus focus
Posted by
Steve Johnson
at
2008-10-11 06:38 PM
The joy and pain of smaller companies is that there is too much to do and not enough time. Oh wait! the same is true in larger companies.
First, define your personal priorities. Go through the Pragmatic Marketing Framework and identify the top three things that you need to focus on. And look for items where your product team can help.
Can you leverage some of the downtime of your sales engineers? (Most sales engineers think more strategically than sales reps who typically think only about the deals they're working). SEs can feed you market information, interview clients on your behalf, participate in your requirement and design reviews, create some of the sales tools that you're doing now. Likewise, some of your development team might enjoy doing a little sales and marketing work for you too.
Yes, there's a lot to do. Can your team share the load?
First, define your personal priorities. Go through the Pragmatic Marketing Framework and identify the top three things that you need to focus on. And look for items where your product team can help.
Can you leverage some of the downtime of your sales engineers? (Most sales engineers think more strategically than sales reps who typically think only about the deals they're working). SEs can feed you market information, interview clients on your behalf, participate in your requirement and design reviews, create some of the sales tools that you're doing now. Likewise, some of your development team might enjoy doing a little sales and marketing work for you too.
Yes, there's a lot to do. Can your team share the load?
Using Agile
Posted by
Steve Sigal
at
2008-10-10 08:36 PM
Using Agile, how do you provide an estimate for the features in a release to come up with a GA date if Development only wants to estimate one sprint at a time?
Release Planning is Essential
Posted by
Luke Hohmann
at
2008-10-20 07:11 PM
The Agile process for estimating which features will be included in a release is called Release Planning. The result of an effective release planning meeting is the expected number of iterations that the team will require to deliver all of the backlog items accepted for the release, along with the expected deliverables within each iteration. To this plan you will add "end-game" activities (typically 1-3 additional iterations) and then compute your GA date. The GA date should fall within the market window identified in your roadmap, a topic that will is discussed extensively in my book "Beyond Software Architecture" and that will be presented in this webinar: https://www1.gotomeeting.com/register/867252141.
Question
Posted by
Steve Sigal
at
2008-10-10 08:36 PM
Steve, assuming that Development needs to have someone with them 24/7 to answer questions, where in the organization does the Product Owner best fit so that the decisions reached meet what the market wants and not to fit the Development schedule?
Product Owner is a Subset of Product Management
Posted by
Luke Hohmann
at
2008-10-20 07:11 PM
This is a pretty hot topic in the Agile Community. Simply, the Product Owner is a subset of a Product Manager. In Pragmatic terms, it is closest to a Technical Product Manager. We'll be covering this in future webinars (check the schedule -- given the confusion of what a Product Owner really does, we'll likely cover this multiple times). While you're waiting, check out Rich Mironov's posts on this topic:
http://www.enthiosys.com/insights-tools/pm-prod-owner/
http://www.enthiosys.com/insights-tools/po-defined/
http://www.enthiosys.com/insights-tools/pm-prod-owner/
http://www.enthiosys.com/insights-tools/po-defined/
Question
Posted by
Milena Krasteva
at
2008-10-10 08:36 PM
How does a PM satisfy exec's need for predicatbility with Agile. when the end product is a large complex product but you don't know what you'll be up against from a technology/feature/resource perspective it's hard to set realistic expectations with various other groups in the org
Predict Schedules, Estimate Features
Posted by
Luke Hohmann
at
2008-10-20 07:11 PM
Successful Agile teams make rigorous estimates of schedules and adjust features to hit market windows. To handle executives, learn to communicate through roadmaps that emphasize only those high-level features that drive drive revenue. Scott and Jeff will be discussing this during their webinar on roadmaps.
Where does the RFP fit
Posted by
Kevin Courtney
at
2008-10-10 08:36 PM
Where do RFP responses fit in the pragmatic framework, or should they be in the PM responsibility? How do you best create distance from this task?
RFP's are the job of sales, not product management
Posted by
Steve Johnson
at
2008-10-11 06:38 PM
It's fairly typical for companies to rely on product management whenever product expertise is needed. But product managers are not the only one who know the product. Every sales team needs access to a field resource who is expert in the products you offer. I call this role a sales engineer or field consultant.
The easiest way to determine if an activity belongs to product management is to count the number of customers. If the activity relates to a single customer, the job falls to sales engineering or technical support. If the activity affects all customers--a market full of customers--then the job is product management.
For more on the role of sales engineer, go to http://www.pragmaticmarketing.com/publications/magazine/2/5/0410sj/
The easiest way to determine if an activity belongs to product management is to count the number of customers. If the activity relates to a single customer, the job falls to sales engineering or technical support. If the activity affects all customers--a market full of customers--then the job is product management.
For more on the role of sales engineer, go to http://www.pragmaticmarketing.com/publications/magazine/2/5/0410sj/
roadmap commitments
Posted by
Jeff Berg
at
2008-10-10 08:36 PM
Can you comment on meeting roadmap commitments in an agile world (we typically have an 18+ month sales/contract cycle and must be able to deliver product functions committed in contracts 12-24 months earlier)
on roadmapping
Posted by
Steve Johnson
at
2008-10-21 12:38 AM
You'll want to attend Agile Roadmapping with Scott Gilbert on Friday November 14, 2008.
Documenting Agile
Posted by
Gregory Prince
at
2008-10-10 08:36 PM
How would you suggest to overcome the challenges of documentation with Agile. How do you suggest to track the changes that you see throughout the process. For example you decide on one approach or a change, but a month later you are wondering why you went down a specific path. How can you also control scope creep?
flexibility
Posted by
Steve Johnson
at
2008-10-23 09:59 AM
Agile development should deliver 100% of something in each iteration. Like marketing collateral and sales tools, any product documentation can proceed based on results of each iteration. If done correctly, screens and reports will not change after they're complted. That is, your team should not be changing something that is done.
The role of product management is to define the list of problems to be solved and share these with the development team--including documentation. So documentation writers will know the roadmap and the potential release candidates. As soon as development starts working on code, documentation and QA can start working too.
More on this in upcoming webinars. Keep watching...
The role of product management is to define the list of problems to be solved and share these with the development team--including documentation. So documentation writers will know the roadmap and the potential release candidates. As soon as development starts working on code, documentation and QA can start working too.
More on this in upcoming webinars. Keep watching...
Where Should We Start
Posted by
Christopher Briggs
at
2008-10-10 08:36 PM
Managing the process of moving to an agile focus clearly requires significant organizational change.... where should we start?
Bottoms-Up and Top-Down
Posted by
Rich Mironov
at
2008-10-13 11:05 AM
You'll need at least one pilot team that's excited about Agile (make sure it includes dev,prod mgmt, program mgmt, test/QA and UI/UED) and wants to be first. Assume at least 8 iterations before team hits its stride. [That's bottoms-up.]
You'll also need at least one very strong supporter among the Exec team to give you enough time to be successful, since initially things will be messy and team may need air cover.
If you can, borrow some time from product mktg to promote the team's succs internally. If no one knows about it, Agile can't catch on.
You'll also need at least one very strong supporter among the Exec team to give you enough time to be successful, since initially things will be messy and team may need air cover.
If you can, borrow some time from product mktg to promote the team's succs internally. If no one knows about it, Agile can't catch on.
Mixture of Waterfall and Agile
Posted by
Bruce Chapa
at
2008-10-10 08:36 PM
How do you mix the concept of agile with the need for management and sales for a roadmap on what products we will have when, which the waterfall method did very well? At my company, we have a mixture of waterfall and agile where we use the agile methodology, with a committed date for a set a story cards (features). Have you seen other approaches?
on roadmapping
Posted by
Steve Johnson
at
2008-10-23 09:59 AM
That's the rub, isn't it? Agile development offers flexibility and increased confidence, but the rest of the company wants guarantees. Turn it around. Which contracts will sales deliver on what days? How many leads will marcom generate from that upcoming show?
As an industry, we've never been very good at meeting both feature sets and dates. With agile, your teams will deliver 100% of something after every iteration. That said, agile is not the answer for everyone. Some companies feel that agile introduces cowboy coding at a huge loss of predictability.
More on predictability in upcoming roadmapping webinar...
As an industry, we've never been very good at meeting both feature sets and dates. With agile, your teams will deliver 100% of something after every iteration. That said, agile is not the answer for everyone. Some companies feel that agile introduces cowboy coding at a huge loss of predictability.
More on predictability in upcoming roadmapping webinar...
Question
Posted by
Vick Madenian, PMP
at
2008-10-10 08:36 PM
Any insight on the relationship between a PRODUCT manager and a PROJECT manager?? Can both be the SAME person?
Manager = expert
Posted by
Steve Johnson
at
2008-10-11 06:38 PM
My rule for delineating titles is to change the word "manager" to "expert" and see if the title still makes sense. So a "proDUCT manager" should be expert on a product (usually over the life of multiple projects); a proJECT manager should be expert on managing complex projects (not necessarily specific to one product). These are not the same jobs but could be performed by a person with both skills. I caution you to be careful about wearing too many hats, loading one person down with too many expectations: some companies are asking for the impossible! Just try to combine project, market, product, and design expertise in one person. You end up with a person who is not expert in any of them.
Read more on the "managers as expert" concept in my article at http://www.pragmaticmarketing.com/publications/topics/06/0603sj/
Read more on the "managers as expert" concept in my article at http://www.pragmaticmarketing.com/publications/topics/06/0603sj/
Question
Posted by
Mofazzal Bhuiyan
at
2008-10-10 08:36 PM
What is the effective way to motivate developers to accept agile dev from water fall?
Motivating developers toward agile
Posted by
Rich Mironov
at
2008-10-21 12:38 AM
Generally, I'm seeing this in the other direction: development teams want to go agile, and drag everyone else behind them - or fail to recognize that other gropus (PM, product marketing...) need to be involved.
To your question: product management can't push Dev to do this. Instead, this is an influencer role: point out that agile teams are more productive *and* generally happier, since they work more on whole products, have fewer end-of-release burnouts, and sidestep most major architectural failures. And that your competitors are going agile. Peer pressure works with engineers.
To your question: product management can't push Dev to do this. Instead, this is an influencer role: point out that agile teams are more productive *and* generally happier, since they work more on whole products, have fewer end-of-release burnouts, and sidestep most major architectural failures. And that your competitors are going agile. Peer pressure works with engineers.
Effective Roadmapping
Posted by
Don Gray
at
2008-10-10 08:36 PM
How can I get help with putting together an effective roadmapping approach under and Agile mindset
on roadmapping
Posted by
Steve Johnson
at
2008-10-23 09:59 AM
You still need to know where you're taking the product over multiple generations. Agile doesn't hinder that effort. But instead of features, you should be focusing on markets and problems and the architectural underpinnings that support your strategy.
Roadmapping is the subject for an upcoming webinar.
Roadmapping is the subject for an upcoming webinar.
Question
Posted by
Thomas Hughes
at
2008-10-10 08:36 PM
Is it really tough to hit specific dates with specific features vs setting a trend of development?
Estimation Accuracy Varies in Agile
Posted by
Luke Hohmann
at
2008-10-20 07:11 PM
The answer to your question is "It depends". Mature Agile teams are very good at hitting specific dates with specific features. These are called iterations, and the features are the backlog items that the team pulls into the iteration. Agile teams get good at this because they don't accept backlog items that can't fit within an iteration. This means that Product Managers must learn how to take large, complex features, and decompose them into smaller, simpler features, such that each such smaller, simpler feature still provides business value. An example is taking a large use case and decomposing this use case into several discrete user stories that te team can implement. As you ask teams to estimate larger features, the accuracy of their estimates will decrease.
Documenting Features
Posted by
Michael OShea
at
2008-10-10 08:36 PM
I wanted to know what strategy works well for documenting features via agile development
on documentation
Posted by
Steve Johnson
at
2008-10-21 12:38 AM
If done correctly, each iteration delivers complete functionality. So documentation can proceed once the iteration is complete. Knowing the backlog, tech writers can anticipate what new capabilities will be added and plan accordingly. The good news is that agile teams should not be dumping new screens and changed capabilities on documentation without tech writers--and marketing--having a heads-up.
Release planning versus agile sprints
Posted by
Kishore Gagrani
at
2008-10-10 08:36 PM
Release planning versus agile sprints, how to coordinate?
Product Managers guide, Project Managers elaborate
Posted by
Luke Hohmann
at
2008-10-12 11:57 AM
As Steve pointed out in an answer to an earlier question, the Product Manager is an expert in the product while the Project Manager is an expert on managing complex projects. During release planning, the Product Manager answers questions from the dev team and collaborates with the dev team to elaborate and/or decompose backlog items that are larger than a single iteration into backlog items that fit within an iteration. The project manager is there to ensure that the team is following their chosen process and that the results of the release planning process results in a release plan that everyone agrees is valid to for execution. This process happens again during every iteration (sprint).
Sizing the Market
Posted by
Kishore Gagrani
at
2008-10-10 08:36 PM
How do you size the market problem ?
surveys for quantitative
Posted by
Steve Johnson
at
2008-10-11 06:38 PM
There are two categories of research: Qualitative is for discovering problems; quantitative is for validating and sizing. We recommend onsite interviews to learn what you don't know, and web surveys to validate and quantify. See a problem with your eyes and survey to count how many people have it.
The problem is that technical people expect absolute accuracy in every number and they struggle with the ambiguity found in real world estimating.
Once you have a problem, survey your audience to see what percent have the problem and extrapolate that across the population. It sounds easier than it really is.
We discuss both techniques in Practical Product Management. For self-study, let me recommend Innovation Games by Luke Hohmann. The book offers specific techniques for interviewing and observing in an onsite visit. On Amazon: http://www.amazon.com/exec/obidos/ASIN/0321437292
The problem is that technical people expect absolute accuracy in every number and they struggle with the ambiguity found in real world estimating.
Once you have a problem, survey your audience to see what percent have the problem and extrapolate that across the population. It sounds easier than it really is.
We discuss both techniques in Practical Product Management. For self-study, let me recommend Innovation Games by Luke Hohmann. The book offers specific techniques for interviewing and observing in an onsite visit. On Amazon: http://www.amazon.com/exec/obidos/ASIN/0321437292
Agile SDLC
Posted by
Tom Lewis
at
2008-10-13 12:31 PM
Does the Agile SDLC work well with offshore Development and QA and how can Product Management help?
offshoring
Posted by
Steve Johnson
at
2008-10-21 12:38 AM
Offshore makes everything harder: time zones, teacms without a common cultural basis, little or no face-to-face time. Frankly, I've never been a fan of outsourcing or off-shoring; it's hard enough to do development well when you're in the same building! Yet some MATURE companies are doing it. I fear agile and offshore are too difficult for non-mature companies to succeed. What is mature? Teams skilled in development methods, with automated tools, and competence employees dedicated to the team. Whether agile or not, without these items, I think most projects are doomed.
Development and Agile