Personal tools
Document Actions
Home / Resources / Webinars / Role of Product Management When Development Goes Agile
Document Actions

Role of Product Management When Development Goes Agile

What is the role of product management in an agile environment? Is the role of product owner something different? Developers often see product managers as technical resources. Agile seems to have made this orientation worse, with product managers getting pulled into deeper, tactical activities. But spending so much time with internal teams means less time spent in the market as a resource for strategy and business thinking at the product level.


Watch Role of Product Management When Development Goes Agile






About the Presenters


steveSteve 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. Contact Steve at sjohnson@pragmaticmarketing.com


Rich Mironov 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

Developers Needs

Posted by Peter Dudchenko at 2009-05-08 07:18 PM
Can you address how PM's can deal with the need for Developers to have access to us at all times yet our prime goal is to be out talking to customers and not always accessible to them?

accessible POs/in-the-field PMs

Posted by Rich Mironov at 2009-05-11 01:21 AM
This is IMHO a real dilemma for agile product managers/product owners. Product Owners find that time out of the office is very hard to carve out, esp. with daily standups and story updates and sprint planning/reviews/retrospects/backlog maint. 3 days at the user group is tough; 10 days on the road with sales teams is a huge challenge. Yet you can't represent the market unless you're frequently meeting F2F with prospects and customers and partners.
Where it's possible, I push for duos: a 'strategic PM' who is more outbound and owns pricing; packaging; roadmap; competitive; execs; positioning... and a 'technical PM/PO' who owns the daily details; backlog; stories; acceptance; UI choices... of course, these folks need to be joined at the hip since each must know what the other is doing at the atomic level. Whatever you call these folks, it's a challenging role/pair of roles.

My experience: the daily challenges drive out the strategic ones, and a naked PO without strategic help can easily/quickly lose touch with the broader market.

Question

Posted by Andrew Zosel at 2009-05-08 07:18 PM
Can you speak to how the role and agile development changes in a HW/SW system development environment?

hardware and software

Posted by Rich Mironov at 2009-05-11 11:56 AM
The actual physical creation of hardware takes time -- fabricating devices, sourcing parts, laying down substrates when making chips. Almost all of the design process, though [IMO] is really a software process. Consider chip design and test a la Cadence: massive software systems to layout chips, test circuits, simulate activity.
Hardware designers can apply the same techniques as agile software designers: modularity, completion of fully working functions/subsystems, incremental improvement, etc. I'd guess that your hardware process is really 80% software. There are special constraints on drivers and machine interface code [e.g. optimizing for code size and speed, not functionality], but they are directionally similar.

I might consider splitting out the very (very!) few processes and steps that truly take long lead times - fab, metal bending, fire certification testing and UL approvals - from the bulk of design and engineering work which can be broken into very small steps. Ask hard questions about why each can't be subdivided or sequenced. And apply agile to the rest.

Roles

Posted by Chamindaj Jayasekara at 2009-05-08 07:18 PM
What is the role of the business analyst who is assigned to work with product manager?

Business analysts (and titles)

Posted by Rich Mironov at 2009-05-11 01:21 AM
Titles and roles vary widely... in some agile organizations, business analysts are really doing the work of product owners: speaking for the end customer, prioritizing backlogs, crafting user stories, accepting work. That's often a great fit, especially for INTERNAL IT projects for functional groups within the company (e.g. finance, operations). If the BA is scheduled to return to her/his department at the end of the project, however, the dev team hasn't grown any long-term expertise in the product owner role. We'll have to start again with a new BA on the next project. [Likewise if a BA stays too long on the dev team he/she can lose touch with what's important among the customers.]

Within Pragmatic's framework, a BA may be filling much of the role of a technical product manager. Using our agile terminology, a BA may in fact be a product owner. Either way, it's important to supplement with some solid PM experience (packaging, pricing, sales process, roadmaps, strategic planning ) or mentoring so that you're not setting up a newly recruited BA/PO/PM for failure.

Who uses Agile?

Posted by Eric Sunderhaus at 2009-05-08 07:18 PM
Do company's with longer design cycles (5yrs), such as automotive, use Agile?

Agile and long-lead-time products

Posted by Rich Mironov at 2009-05-11 01:21 AM
They could... and some do. BTW, much of Agile is drawn early lessons of the Toyota Production System. I might draw a distinction between the car companies who've failed to be very agile for decades (and are deep in the red), and those more nimble ones with solid balance sheets and increasing market share.
Agile can be applied to very large projects/products by decomposing the work into very small bits and getting them done more effectively. I wonder if it makes sense to have any commercial product with a 5 year design cycle -- since market forces move faster than that. Advocates of Lean would ask why it takes 5 years, and how to shrink that to 2 or 3, instead of making it a reason not to innovate the engineering process.

Question

Posted by Sarela Bliman-Cohen at 2009-05-08 07:18 PM
How do you implement agile when you have developers all over the world and the PM is in another location?

remote dev teams

Posted by Rich Mironov at 2009-05-11 01:21 AM
it's really important (especially under agile) to have as lot of face-to-face time with the team. Consider hiring/designating someone in each location as the product owner, with overall product responsibility rolling up the HQ product manager. And bring those folks together often for real F2F time. Having a dev team without a PM or PO present is generally a poor agile practice.

You should also consider the make-up of each team. Better to have one complete team in Ukraine building UI and web front ends, and one complete team in Bangalore building back-end database, than to have two half teams in each place. A whole-and-complete team -- including a product owner -- that exists in one geography will be much more productive and much happier. Can you segment the work/architecture for this?
And the lead PM will need to spend a lot of time on planes (and WebEx) to keep a unified vision and motivated teams working toward common working solutions.

Question

Posted by Dave Angelow at 2009-05-08 07:18 PM
How do you link Requirements into the Roadmap - which ones go in early releases when in Agile it's not as prescriptive. Generally take the high risk ones first

linking stategy to execution

Posted by Steve Johnson at 2009-05-11 11:53 AM
Individual requirements shouldn't be noted on the roadmap; you should take it up a level. The roadmap should be thematic, showing the phases of development. A typical roadmap shows too much information for most audiences. Of course, sales people and prospects want to know everything but that's just not realistic. Tell them what you know to be true.

We use a technique of grouping requirements into phases of development. Our teams will complete all of group 1 before continuing to group 2. We may communicate all of group 1 externally but only communicate group 4 internally.

All agile teams want to focus on shipping 100% of something rather than 70% of everything.

Barb Nelson & I will discuss roadmaps in the webinar "Agile, Roadmaps, and Requirements: Are They Mutually Exclusive?"

Learn more about roadmapping and agile product management in our in our Living in an Agile World seminar.

Sharing the Roadmap

Posted by Paula Dycaico at 2009-05-08 07:18 PM
How do you share the roadmap in a way that does not allow sales to presell the later part of the plan and compromise your timelines

Selling the dream

Posted by Steve Johnson at 2009-05-11 11:53 AM
Sales people will use any tool that they think will help close a deal. The roadmap is one of their favorite tools. They want it to be a rigid commitment of deliverables that is also flexible so they can make changes to it based on customer contracts.

The trick is to communicate to sales people and customers the phases of development, not the features. The most common technique is to use a grouping method such as release themes or persona goals.

I wrote about Product Roadmaps in http://www.pragmaticmarketing.com/publications/magazine/2/2/0312sj/

Learn more about roadmaps and roadmapping in our Pragmatic Roadmapping seminar.

Offshores

Posted by John Wheeler at 2009-05-08 07:18 PM
I am finding out agile does not work well in an offshore model, where product management is in the US and Dev is offshore (communication issues)...your thoughts...?

Agile and distributed teams

Posted by Rich Mironov at 2009-05-11 01:21 AM
Agile is harder with an offshore or distributed team, but by no means impossible. In fact, most of the (agile and non-agile) teams I know have some folks on another continent.
Knowing this will be harder, you need to plan around it. Get good collaboration software/tools, stagger the time of your standup to share the pain (9AM Pacific one week, 9PM the next), make sure to meet the entire team and do some travel in each direction, do lots and lots of web conferencing and demos.
There are also a range of style/communication issues to address. Having a manager at each end who can encourage/repeat/translate is very important. Agile doesn't work without trust and very frequent/solid communication.

Multiple Roadmaps

Posted by Andrew Karr at 2009-05-08 07:18 PM
I find that I have one roadmap for the executive team (big rocks) and another one for development where we identify individual "issues" to address. Is this a common approach??

roadmaps

Posted by Steve Johnson at 2009-05-10 10:08 AM
Absolutely. Use an internal roadmap with development that shows all the details in support of the overall strategy; use an external roadmap for execs, sales people, and customers to show "big rocks", themes, phases of development. You don't want to make commitments to a single feature two years out! But you should be willing to show the phases of development between here and there. We address roadmapping in our new video seminar, Pragmatic Roadmapping. Look online in the next few days for details.

When engaging in an agile world

Posted by Greg Davidson at 2009-05-08 07:18 PM
I think the important thing when talking about engaging in an agile world is that it comes in many forms... our organization has adopted agile methodologies but still does not produce shippable code... our backlog and product requirements really are more elastic. The benefits still are significant in that we're changing those backlog/requirements as we daily. The other thing that we are doing is taking these product "pieces" to our customers for feedback to feed directly into the backlog... just comments perhaps for you to talk to.

hybrid agile

Posted by Steve Johnson at 2009-05-10 10:08 AM
Our research shows that the most common form of agile is a hybrid. Companies take ideas from Scrum and elsewhere to create a version that works for them. The key of course is small iterations with completed work at the end of each. If you're not getting shippable code, you should consider extending your sprints or reducing the attempted user stories.

As Rich said, some companies are getting 60% more throughput with agile. But getting code done and getting a product in the market are different things. Make sure that this hybrid approach ultimately results in a product that people want to buy.

Planning on going Agile

Posted by Guillermo Tellez at 2009-05-08 07:18 PM
If a big software company is planning to go agile in the next month, what suggestions do you give a PM who has only worked waterfall?

waterfall to agile

Posted by Steve Johnson at 2009-05-10 10:08 AM
Of course, the first step is to attend Living in an Agile World, our new seminar for product managers adopting agile. Meanwhile, get one of the many great books on agile development to understand what development is doing (remembering that product management begins with the market problem). Then you'll want to start thinking of artifacts: in the old days, you wrote a big requirements document in Word with a list of features and descriptions. Instead, now you'll write them on index cards or in a spreadsheet, and again, they need to be problems, not features.

Most of all, have a team meeting to discuss how you can feed the development process without being an onsite encyclopedia. You don't want to be on-hand 24/7 (no matter what the team thinks); you want to give them problems to solve and enough context that they can solve them.

Seriously, this is the reason we created the Living in an Agile World seminar--to show you exactly how to begin in agile.

Thoughts?

Posted by Catherine Schulten at 2009-05-08 07:18 PM
Many large product companies have business analysts that work within the Product Management organization and work in tandem with Product Managers for a given product. The business analysts are the ones working in the bullpen with the product development teams, translating market needs derived from the Product Managers; however the business analyst are knowledgeable in the given product/business domain to drive feature prioritization. What are your thoughts on this model?

titles are a mess

Posted by Steve Johnson at 2009-05-10 10:08 AM
In our annual product management survey, we found over 200 titles doing the activities of product management--including business analyst. I think you'll find that business analyst is doing the technical bits of product management and is probably the same set of activities that agile advocates suggest for product owners. So look at the activities that you want product managers to do and which you want business analysts to do--and let the activities define the job titles.

Question

Posted by Thomas Chmielewski at 2009-05-08 07:18 PM
If the PM is involved daily with the Agile team, and even co-located with them, when does the PM have the oppty to do the strategic work including looking at the market opportunities?

Market expert

Posted by Steve Johnson at 2009-05-10 10:08 AM
That is indeed the challenge of product management in agile. How can you be an expert on the market unless you're _in_ the market? And how can you spend time in the market if you must attend two or three meetings each day. The approach we apply in our Living in an Agile World seminar is to spend time up-front educating the team on the market--the buyer and user personas, and their problems--so that the team is able to answer their own questions supported with domain knowledge.

Create a team that understands the persona and their problems. Then go out and get more problems to solve.

Writing feature requirements

Posted by Joshua Kilpatrick at 2009-05-08 07:18 PM
How do we change the way we write feature requirements to work well with agile? It seems like the requirements need to be small nuggets that can be moved around and reprioritized easily rather than large feature documents. Help us understand what the backlog looks like, how do you express it.

atomic requirements

Posted by Steve Johnson at 2009-05-10 10:08 AM
Yes, requirements should be small so they can be moved from one sprint to another. THat is, each requirement should be atomic (it is complete and stands alone). We teach a method called Requirements That Work that encourages you to start with the problem. Write a requirement in the form of [Persona] has [problem] with [frequency]. Or you may prefer the agile user story approach of "As a [role] I want to [use scenario].

The trick is to think about problems rather than solutions. Requirements are the 'what' but not the 'how'.

Learn more about adapting to an agile approach in our new seminar, Living in an Agile World.

Managing the process

Posted by CORY CAPOCCIA at 2009-05-08 07:18 PM
In our organization, the product department is relatively new and is being defined. As Product becomes more involved in the business of other departments to drive our products and services forward in line with our corporate strategy, what is the best way to manage this process without being received as invasive or a threat to the leaders of the other departments?

introducing product management

Posted by Steve Johnson at 2009-05-10 10:08 AM
Sadly, some teams will see product management as a threat. Product managers bring process and business thinking. They sometimes bring opinions. They should bring market facts. The trick is to say "Sure, you could keep making stuff up but I'm here with facts from the market." With so many ideas and opinions already existing, the effective product manager says "78% of our customers are facing this problem." And "32% of the deals we lost in April were because of this."

What you'll find is that the teams respond to the analytical rather than the emotional. Be the messenger of market facts and you'll find your teams embrace product management.

Integrating Software and Hardware

Posted by Gerry Callejo at 2009-11-06 07:22 PM
We also manufacture hardware. How do you suggest integrating software with hardware and the hw prod mgr?

Agile, HW and SW

Posted by Rich Mironov at 2009-11-08 11:48 PM
Building physical hardware has some limitations different from building software. In particular, the actual making (manufacturing) process can be slow and expensive, which can undercut the agile idea of very rapid testing / cycle-time / delivery.

That said, mostserious hardware design folks (in my experience) have a range of software simulations, test tools, emulators, etc that make this much more "like" a software design process. Cadence-like layout and verification tools for chips, etc, etc. If you can "test" your hardware designs through software, up until the final physical construction, then it's much more suitable to short agile iterations. Good software tooling means that the eventual hardware looks extremely close to its software intermediaries.

That's a long way of saying "I think most hardware design is really more like software than we give credit for." Frequent drops from software teams of drivers, UI, operating code, etc could [should!] be testable by the hardware team along the way. The more often, the better. Agile HW and SW teams can set up frequent integration points, dry runs, etc. You should have HW prototypes, test versions, lab units, that SW teams can kick around.

Of course, there may be issues. Simulations and emulators may not be perfect, device tolerances may matter, heat/cold happen, parts don't fit or wear out, etc. Specs change. That's why I respect HW PMs but am not one myself.

As you gain some experience in this agile HW/SW mix, you may decide that you need extra iterations at the end (or in the middle!!!) for integration, HW/SW verification, whatever. Agile encourages us to *learn* and *adapt* our planning based on direct experience.

Tools

Posted by Shailja Dhruva at 2009-11-06 07:22 PM
Can you comment on the best product management tools to manage the communications and deliverables in agile environment?

Agile PM software tools

Posted by Rich Mironov at 2009-11-08 11:48 PM
I'd carefully differentiate between agile PROJECT management solutions and agile PRODUCT management solutions.

IMO, there's a rich set of products and competitors offering development-focused agile PROJECT management suites. These typically handle creation/tracking of stories, sprint planning, assignments, breakdown of stories into tasks, estimation, burndown charts, status reports, etc. These are essential for geo-distributed teams that can't all stand in front of a status wall to move PostIts, and for larger multi-team organizations working on larger projects/products.

These are certainly good for the whole team, and need product manager/product owner input. I think of them as 'owned' by the ScrumMaster or Project Manager, though, who owns the day-to-day status of the team. I know the Rally, VersionOne and Serena products best, but know that many others (Atlassian, TargetProcess, Danube, Hansoft, Mingle/ThoughtWorks...) play here. Apologies for those I've missed.

[IMHO, having a PM/PO also be the hour-by-hour driver of the team's productivity and status updates and external resource requirements is a mistake -- and a good way to fail. If you don't have a ScrumMaster or Project Manager, then the PM is set up for failure.]

{deep breath}
There's fewer offerings IMO serving the end-to-end needs of the PRODUCT manager that also ties to agile. This would support PM's core needs -- roadmapping, release planning, *benefits* as well as feature tracking, shipment/revenue data tied to products. Rally's APM app ties to customer data/field input. But I think we're still straddling two worlds, where Marketing/Sales needs completely different content/format/structure than we feed to Development.

Engaging Customers

Posted by Adrian Phillips at 2009-11-06 07:22 PM
Should developers engage customers directly for feedback -- that's "agile" but also the pm's job...

customer feedback is critical

Posted by Steve Johnson at 2009-11-08 12:58 PM
Most agile methods, particularly XP and Scrum, want customer representatives for the dev team to interact with. For vendors, this role is commonly served by the product manager or product owner. (In order to do this, both the product manager and product owner need frequent personal customer experiences.)

I'm not opposed to developers interacting directly with clients but they have to understand that ONE client's requirements are not necessarily ALL the clients' requirements. The value of strategic product managers is that they look at the needs of the many, not just the one.

12 hour GAP

Posted by SaiGiridhar Dasika at 2009-11-06 07:23 PM
Our Product Manager is in the Mid-West close to the clientele. The development team and the Product Owner are in India with 12 hour GAP. They talk to each other almost everyday. In this scenario how does this model work?

non-co-located teams

Posted by Steve Johnson at 2009-11-08 12:58 PM
Since I've never been an advocate of off-shoring, I'll let the agile folks discuss the effectiveness of agile over a 12-hour gap. Regardless, the product manager is in the right place: near the client. The product manager should help the product owner understand the market and its requirements and rely on the product owner to empower the team to build the right solution. As I indicated in the webinar, the product manager doesn't need to attend each daily meeting but should drive the kick-off of each sprint by clarifying the vision and up-skilling the team on the target personas and their problems.

Just a comment

Posted by Johnny Hermann at 2009-11-06 07:23 PM
I suspect Scrum folks intentially minimized the constraints on the definition of Product Owner to that required by Scrum, so that Scrum could interface with as many other processes without artificially limiting applicability.

good point

Posted by Steve Johnson at 2009-11-08 12:58 PM
I believe you're right: the product owner seems designed to deliver what DEVELOPMENT needs from the market--not necessarily what sales, marketing, and executives need. Our message--and I'm sure agilists agree-is that the product owner needs to represent the problems in the market, not just the list of ideas from inside the building.

1-man dev team

Posted by John Davey at 2009-11-06 07:23 PM
Is agile scalable to a 1-man dev "team", do the differences between Agile & Waterfall diminish at this level?

agile for 1

Posted by Steve Johnson at 2009-11-08 12:58 PM
I'm not sure you can be agile with a team of one Daily meetings should be easy enough; one person probably won't argue too much with himself. But you can still leverage some of its benefits: small iterations are still great--work for two weeks and show me where you are; brief artifacts--here are the problems, let's discuss how you're gonna solve 'em; transparency--let's show everybody where you are.

Regardless of the size of your team, product management is about understanding the market, sharing the market perspective with the person or people who build the product, and then delivering a potentially SELLABLE product to the market.

Reqs and Specs

Posted by Phil Green at 2009-11-06 07:23 PM
Related to your article On Reqs and Specs do you still advocate a document centric approach (MRD/specs) to the communication between the Strategic Product Manager and the Technical Product Manager/Product Owner and by extension development team? Could you compare and contrast this with the canonical agile approach of a CCC (card, conversation, confirmation) based product backlog? Thanks for the great presentation.

conversations and documents

Posted by Steve Johnson at 2009-11-08 12:58 PM
I've always been an advocate of conversations over documents, hand-shakes over hand-offs. We teach the "stack of cards" method in Requirements That Work and try to avoid huge MRD/PRD documents. That said, the form of document isn't really the problem. The problem is that those big documents imply that everything is known up-front. And big documents try to anticipate every clarifying question.

We prefer to describe problems to be solved and then discuss the potential solutions. Companies are welcome to put that stack of cards in a word doc or spreadsheet but the artifact doesn't communicate, it logs or documents. People communicate; documents document.

Agile vs Waterfall

Posted by Amruta Joshi at 2009-11-09 10:10 AM
In what environment agile works better than waterfall with respect to Product Management?

agile approaches

Posted by Steve Johnson at 2009-11-09 10:29 AM
There are many agile appraoches: Scrum, XP, TDD, Lean... the list goes on. As for product management, the key as we teach it at Pragmatic Marketing is that product managers need to be the messengers for the market. Every agile method asks for market insights--and product managers are the most likely to provide it.

So I'm not necessarily an advocate for any development method--your dev team should use what works best for their team. I AM advocate for market-driven product management. Learn more in my (free) ebook The Strategic Role of Product Management at www.pragmaticmarketing.com/srpm.

Honestly, I think waterfall methods trick us into thinking that everything can be anticipated. We write huge documents with lots of detail. I prefer a more team-oriented approach focused on personas and their problems, as we teach in Requirements That Work. Agile methods, and particularly Scrum, give us quick feedback on the project so we know that the project is headed in the right direction.

Methods that don't work treat development as a black box: you throw ideas in and hope something recognizable comes out as the product. Methods that do work encourage developers to solve market problems and to keep the stakeholder apprised of the project status.

So use what works for you and your team. If waterfall is generating the right results and giving you visibility into the product status, hallelujah. If not, consider other methods. Regardless of your method, the best product managers focus on the market. For more help in being a great product manager, read my blog at www.productmarketing.com or attend a Pragmatic Marketing seminar. Learn more at www.pragmaticmarketing.com/seminars.