Follow
EmailGreg Cohen is the author of the new book “Agile Excellence for Product Managers“. We did a quick interview with Greg to get answers to some important questions we had about product management within Agile teams.
If you’re responsible for product management in an Agile team – check out this interview, then go get Greg’s book. As a former President of SVPMA and a certified Scrum Master – Greg knows as much about this topic as anyone. Here’s the interview – drum roll, please!
Excerpts from Our Interview with Greg Cohen
(We’ve edited the interview for brevity. If you’d like to learn more, you can buy Greg’s book using the link at the end of this interview.)
Accompa: We’ll start with the “Product Manager vs. Product Owner” question. How is the role of a “Product Manager” different from the Agile “Product Owner” role?
Greg: This is an involved question but I will try to keep my answer succinct.
For this discussion, I will define the “Product Manager” as the individual responsible for the success of the product throughout its entire lifecycle. To be effective, the product manager must be an expert in the market, the customer, the product and technology, and the development process.
The “Product Owner“, on the other hand, is a distinct role as part of a Scrum Team. To quote the Scrum Guide “The Product Owner is the one and only person responsible for managing the Product Backlog and ensuring the value of the work the Team performs.” Product Owner’s responsibility as defined by Scrum only extends to maximizing the value of the development effort.
In contrast, the product manager can maximize the success of the product by not just adjusting the feature set, but by changing pricing, the sales channel, splitting the product into basic and premium offerings, etc.
Accompa: What are the top 3-4 challenges Product Managers face in Agile projects (compared to traditional projects)?
Greg:
- If the product manager is playing the product owner role, workload can increase upwards of 40%.
- As the workload increases, it is easy to spend more and more time in the office instead of meeting with customers. This is a short term gain and long term loss.
- With Agile development, you have frequent and regular opportunities to solicit customer feedback during the development cycle. To take advantage of these opportunities, you will need to grow (by 5x or 10x) the number of customers who you can lean on to provide you feedback.
- With Agile, you may have the opportunity to release smaller increments of value to the market sooner. This can require organizational changes in the marketing, launch and sales processes to support this.
Accompa: How can PMs overcome each of these challenges?
Greg: Fundamentally, the biggest challenge listed above is the increased workload. Product managers need to think about how to smooth their workflow by applying Agile principles as well. Three practices Product Managers can apply are:
- Less Documentation/More Conversation – Documents exist to convey information. Conversation is a deeper form of communication than documentation. Documentation is still essential but it should support communication and not be a replacement for the conversation.
- Time box research – Agile development teams use time boxed research projects when further understanding is needed. Time boxing forces focus on the task at hand and contains the inquiry to gathering only enough detail to answer the question. Product managers can apply this technique when evaluating new markets, business opportunities, and product concepts.
- Work in small batches – Limit the number of items being worked on within your product at any one time and move smaller chunks of value through the system faster. For example, instead of passing an entire product requirements document representing months of work to development, pass each feature as it is documented. (See Working in small batches).
I actually just blogged on how to become twice as effective.
Accompa: Are MRDs (Market Requirements Documents) and PRDs (Product Requirements Documents) needed for Agile projects?
Greg: The information captured in MRDs and PRDs is still essential. But the use of these specific documents is contextual.
MRD and PRD templates are still great for collecting one’s thoughts and ensuring you as the product manager understand the true customer problem to be solved and have thought through the issues and interdependencies.
Lastly, all the information generally captured in the MRD and PRD still needs to be conveyed to the development team over the life of the project.
A couple of differences are:
- Development should begin prior to the completion of the PRD. Once the “PRD outline” and first major product requirements are identified, the team should begin development. New requirements will be documented to match the team’s throughput.
- If you write a PRD, it will likely not be maintained under change control or tested against. It will be divided into story-sized increments and the stories will be used to develop and test against.
Regardless of documentation format, the goal is to maximize conversation about each requirement within the team and have a workable method to prioritize, re-prioritize, and separate features into small enough increments to fit into iterations.
——————-
We thank Greg for sharing his valuable insights with us and providing us a free copy of his book! To learn more and get his book, click here.
We hope you enjoyed the interview as much as we did.
Editor’s Note:
Interested in learning how Product Management teams can improve their effectiveness in working with Agile Development teams? Get our FREE eBook A Practical Guide: Product Management & Agile Development.
Like This Post? Get More by Email
3) Do not read this blog one sentence per day during your lunch break, while eating a 