Agile DevelopmentCollaborationCultureDesignDevelopmentInnovationInteractionLeadershipProcessProduct ManagementProject ManagementSaeedScrum

Agile/Scrum Software Development and Product Management part 2

Agile 2008There have been a number of good comments on my original post on this subject and I thought, given that the Agile 2008 conference is happening here in Toronto this week, some additional focus was appropo.

Bhuwan, Ivan, Consultiq and Stacy all agreed with my position that the Product Manager shouldn’t be the Product Owner (Scrum role) if the meant that the Product Manager had to attend daily stand-up meetings with Development. This would force the Product Manager to be a daily tactical decision maker and would make it even more difficult to get out of the office, meet with customers, partners and prospects and do the fundamental research that is needed to ensure that the future success of the product is addressed.

Stacy wrote:

Many companies have assumed that Product Owner is equal to Product Manager. That’s a recipe for disaster — Product Managers can’t be in the daily stand-up, or the team will reach a point where they don’t know what to do next. … Product Management has to be that bridge between the market and development…and we can’t do that if we’re in the building, involved in the daily workings of Development.

I personally don’t like the name “Product Owner” for the role as it is defined in Scrum. At one company I worked at, we called it “Project Owner”, explicitly to remove the assumption that the Product Owner and Product Manager were one and the same.

In fact, on any sizable product release, there will be multiple scrum teams working on different aspects of the product, and thus in the Scrum terminology, there would be multiple “product owners” which doesn’t make sense. Now, the term “Project Owner” is not perfect either as there can then be confusion between the Project Owner and the Project Manager, but I think there is less potential confusion there than using the term “Product Owner”.

Steve wrote the following:

So, where does it say that if you move to an Agile/Scrum methodology that Development can make decisions on functionality without first consulting with the Product Manager/Product Owner?

Nowhere as far as I know. But this is not a problem with Scrum or Agile, but it exists in companies regardless of which Development methodology they use. Read my response below WRT Walter’s comment on how to address this issue IF the PM is not explicitly the “Product Owner”.

Walter left a thoughtful comment covering a number of topics. He suggested that the PM attend a Scrum of Scrums meeting to get away from the daily standup, but to still be involved. I have not worked in a company where they implemented a formal Scrum of Scrums type meeting so I can’t speak from experience, but I’m somewhat skeptical of the benefit, simply because the focus of Scrum of Scrums will be inter-team issues and not necessarily product/functionality issues that requires a PM’s attention. As stated in the Scrum of Scrums link above:

These meetings allow clusters of teams to discuss their work, focusing especially on areas of overlap and integration.

Walter also suggests using a person with a role something like “Requirements Architect” who can attend the daily scrum instead of the PM. I agree with this. In fact, I wrote in the original post:

Other roles such as Product Designer need to be defined to take that day to day decision making role and act as the Product Owner, or at minimum, be the proxy for the Product Owner (if that is the PM) so that the PM doesn’t get bogged down by daily scrum meetings.

They key here is level of focus and ability to execute. It is very difficult for any one person to work at a very detailed tactical level — which is where the Product Owner needs to be — and still think, act and plan for the future at a strategic level which is where the Product Manager should focus. Having a Product Designer or a Requirements Architecture fulfill that tactical role but also know how and when to escalate decisions up to the Product Manager minimizes the impact on Development, but also allows for a scalable model that works for both PM and Development.

Walter continues:

Probably more important (and more time consuming) than the daily scrum is your participation in iteration planning, demos and retrospectives.

There will be other affects on the product manager when switching from waterfall to agile. You’ll want to approach your requirements differently. Instead of a list of things the software should / shouldn’t do, you should break it down into stories where each can be implemented independently, will add customer value and the team will be able to accomplish within an iteration.

Instead of saying “must”, “should”, or “frill”, you should rank them and update that ranking every iteration based on what was learned. Agile is all about attacking the most important things and changing based on what you’ve learned.

2 person meetingThis is where the Product Designer or Requirements Architect can also play a significant role, by working with the Product Manager to take the requirements that have been collected and defined for the release, and translate them into effective and accurate user stories that can be readily consumed during sprints. Priorities can also be defined for the stories, so that as implementation proceeds, decisions can be made quickly to drop or reprioritize specific stories if lack of time/resources force the case.

By working with the PM in this way, the Product Designer (or equivalent role) gains a clear understanding of the requirements, their context and importance and can then work efficiently with the Development team to see them through implementation.

The Product Manager can (and should) regularly communicate with the Product Designer and Development Management, at minimum, at key milestones such as feature/functionality reviews, retrospectives etc. to ensure the development work continues to stay aligned with the original intent of the requirements. This also frees the PM to work with other teams such as Product Marketing, Marketing, Sales, Finance, as well as customers, partners and prospects and focus on overall product success.

In the end, the key is to ensure there is clear understanding of who has what authority and responsibilities, and people communicate effectively with one another to define, build and release the best product possible. No one role can succeed without the others, and in the end, all teams must either succeed together or fail together.


Agile/Scrum Software Development and Product Management (part 1)

Agile/Scrum and Product Management (part 3)

Agile/Scrum and Product Management (part 3a)

  1. Gopal Shenoy

    Reading this article 4 years after it has been written 🙂 I personally do not agree with this post – just because a product manager attends a daily standups which usually lasts 15 min or less, it does not mean that the product manager does not have time to talk to customers and other cross functional members to get the product out of the door. No one is saying the a PM has to be there – what I would recommend is to attend as many as you can. For some reason, I sense with Product Managers taking a stand that they are strategic, they are building a wall with their development team. If you as a Product Manager knows exactly what the customer’s problems are, you should be defining and helping your development team build the right product. Attending daily standups and keeping track of progress of the sprints is a way to get just in time feedback on whether your product is going to hit its next milestone, understand if requirements have to be adjusted to drop the nice-to-haves etc.

    A consistent complaint I have heard from development team in companies where product management does not work is that they get ambiguous requests – “Build me X” with not enough details on what X should be. Saying product managers must not attend daily standups is creating a wall between you and the development team. I really don’t understand the downside of spending 15 min with your development team to understand where everything stands. If a product manager is not going to out of the building to meet customers because they think they have to attend daily standups, it is stupid and you have bigger problems. But not attending it because you think it is a development methodology that you should not be part of, is equally wrong.

    I attend them almost everyday – and I still talk to customers, I have time to read my analytic reports on how my product is doing, I have a product roadmap for the next 3-4 sprints, I work with my country directors, my marketing team, my customer care team and so on. I have not stopped doing my PM duties because I have decided to attend a 15 min daily standup meeting every morning.

    1. Saeed


      Thanks for the comment, even 4 years later. I had to go back myself and re-read the posts to refresh my memory.

      I think if you read the original post — — it’s much more nuanced than simply — PMs shouldn’t attend daily standups.

      My position on this has evolved (but not fundamentally changed) over the last 4 years.

      First of all, we have to get away from thinking of “THE PM” in the singular and look at roles in Product Management and how best the PM team/org works with the Dev team/org. A Technical PM could work more closely with the “team” and possibly even attend standups. May be a good thing, but in my experience, not absolutely necessary.

      Also, Scrum essentially demands co-location of all team members, including the PO. One reality of our industry is that given distributed and offshore teams, colocation is not possible in many cases. I have worked with offshore teams for years, had weekly (or more frequent) calls,webex, regular emails etc. but NEVER attended a standup. Why? Because it happens at 2am my time. We’ve built great products nonetheless.

      So the point is not standups, specifically. The point is that Product Management is much more than addressing the needs of the development team. It’s about business planning, organizational readiness, go-to-market, and yes, working with the product team.

      While I did make a comment about tactical vs. strategic focus, those words could have been better stated, as I didn’t want to imply strictly a “strategic” focus.

      I’ll finish with the last two paragraphs of the article above which summarize my thoughts well. 🙂

      “The Product Manager can (and should) regularly communicate with the Product Designer and Development Management, at minimum, at key milestones such as feature/functionality reviews, retrospectives etc. to ensure the development work continues to stay aligned with the original intent of the requirements. This also frees the PM to work with other teams such as Product Marketing, Marketing, Sales, Finance, as well as customers, partners and prospects and focus on overall product success.

      In the end, the key is to ensure there is clear understanding of who has what authority and responsibilities, and people communicate effectively with one another to define, build and release the best product possible. No one role can succeed without the others, and in the end, all teams must either succeed together or fail together.”



  2. saeed


    It’s taken me a while to get to your comment above, The development process should be engineering owned. What gets developed should not be.

    Product Management is responsible for defining what is built. This not only includes features, but interfaces (GUI, APIs, command line etc.), performance levels etc.

    Engineering is responsible for how the “what” is implemented. Engineering needs to have a clear understanding of end expectations, but once that is clear, then the responsibility for implementation is clear.

    The issue comes down to how much ongoing information is needed by the development team to do what is needed to sufficiently meet the requirements and expectations set by Product Management.

    In an Agile model, the assumption from development is that the Product Owner essentially provides “just in time” information so they can get the job done. While this is great for the dev team — give me what I need when I say I need it — the reality is that Product Management cannot and should not be put into this position.

    It will end up in failure for all parties, because the PM will be embedded in the development team and not have time to do all the other things that need to be done to keep the development pipeline primed to continue working.

    Don’t let this happen to you. Point your managers to the articles I’ve written and that others have written. Check out part 3 of this series, as I reference others who make the case that the PM and the PO are two different roles.

    Let me know how things work out.


  3. James Peckham

    Furthermore, to Stacy, product managers shouldn’t be gatekeepers between stakeholders, users, and the market to the developers. People developing your software should be given ready access to the users who they’re writing the product for. Product managers should manage the features and know who the right stakeholders or user proxies are to bring to the developers.

    Manage the product! The title is self explanatory.

    Sounds like your product manager is ‘protecting those relationships’.

    Let me guess… your stakeholders are “Too busy” to participate in development.

    Maybe you should reconsider making an application that people are too busy to help spec out!

  4. James Peckham

    why wouldn’t you have your product manager as your product owner? that’s the stupidest thing (sorry, it is) that i’ve ever heard. Your product manager is the perfect person (that is if they have the damn enthusiasm, knowledge, and willingness to get their hands dirty).

  5. Jeff

    So it sounds like you feel Product Management is mostly detached from development (you say Scrum should be “engineering owned”). But my company is just now implementing Scrum and I am the “Product Manager”, and I’m hearing the phrase “One throat to choke” and that I am expected to soon be running the Scrum reviews (every two weeks). If that’s the case, am I really the Product Owner, not the Product Manager? Or can the same person do both in your opinion?

  6. Steve

    My point re: developers deciding on functionality may have been missed. I agree that this could occur regardless of the Development methodology being used. However, as we start to adopt Agile methods, it looks like my Development team is taking some of the Agile tenets too literally – assuming that self directed teams and teams that can make decisions on their own without management approval to mean that they can decide on the functionality.

    In our organization we have Business Analysts who are part of the Development Team. Their role has been to take the PRD level requirements that are created by Product Management to create Functional Requirements. Can this role act as the Product Owner or are they too close to Development? I agree that as the Product Manager I can’t afford the time to be the Product Owner as well, but need to be informed and involved in some of the decisions. Can a Product Owner that is part of the Product Management Team (i.e. “an associate PM”) co-exist with a BA on the Development side? Where does one role start and the other end when it comes time to writing the User Stories?

  7. Walter

    Good discussion. Some additional comments:

    There are a few reasons that it is useful to have the product manager(s) in the SOS. In the SOS, teams bring up blocking issues and give a high level view into how things are going. It is good for the PM to have a feel for the progress so that they can get a feel for what to expect (both this iteration and future ones). They can also influence that progress (perhaps a requirement isn’t worth the effort going into it and can be lowered in priority / dropped). Finally, the blocking issue could be that the team needs guidance from the PM.

    In our environment, it was completely up to the PM on whether to attend. Most attended the SOS at least semi-regularly because they found it valuable. If someone doesn’t in their environment, it might be the way that the SOS is being run.

    On inputs to the development process… So you could continue to create your requirements as you always have. And then convert them (or have someone else convert them) to the format needed for consumption by the team. But the question you have to ask yourself is whether that’s the most efficient way to approach it… There’s a cost to the translation. First, it’s work that wouldn’t have to be done if you approached the initial requirements differently. Secondly, information always gets lost in translation. If you can eliminate the need to translate, you’ll get better communication.

  8. saeed


    I’m not really the best person to answer your question, as I’m not specifically familiar with RAD and JAD. But here are 4 links from Wikipedia, that should help you (and others) understand the differences a bit more. If someone reading this can help answer Mark’s question that would be great.



  9. saeed


    Thanks for the comment and I agree with your two points.

    1. Someone, Associate PM, Technical PM, Product Designer, Requirements Architect, etc. needs to work with the dev teams during the development cycle to keep things on track.

    2. Scrums should be executed as an engineering owned process. This was a key point of my original post. Agile/Scrum is a development methodology and should be viewed as that. It should not spill over and force significant org or process changes to other teams such as Product Managment. Those outside of Development, should only have to be exposed to the interface of that methodology, thus the need for roles as defined in point #1.

    As a PM I really don’t care how Engineering structures the development process. My focus is to know that what I need to get out of the development cycle matches the requirements that formed the key input.

    i.e. I need a factory that creates software of high quality that meets requirements and is delivered on time. I’ll work with the factory managers to help certain problems along the way, but I really can’t become a factory manager.


  10. Kevin Donaldson

    Interesting post. It seems the issue is well know as described above, and depending on the size of your organization you may need more or less roles to make it work. At our shop we run agile development across 3 products. Each product has what we call an ‘associate product manager’ or junior product manager. They are responsible the operational execution of the sprint, acceptance testing, writing and maintaining story details. Product managers (we currently have 2 for the 3 products) are focused on driving future direction of the product, working to help understand client needs, act as an escalation point etc. Being a startup they have to have the ability however to flex up and down very quickly from tactical to strategic, which isn’t always easy.

    We have also undergone some recent adjustments in how scrums are executed moving it more to being a engineering owned process. Associate product managers still attend and listen with the intent to monitor progress, work to remove roadblocks etc, however what we found was no matter how much we tried, the developers always felt like they were reporting to the product representative instead of to each other which is the true intent – hence the subtle shift.

We really want to hear your thoughts...

This site uses Akismet to reduce spam. Learn how your comment data is processed.