Working for a large waterfall project (+180 members) and although we are about to ship the 1.0. Our client is asking us to work on the next major release (parallel development). Since those new major release includes new features, we need to conduct requirement analysis/impact analysis before getting anything done.

So far, this job has been done by the developers themselves in the early stage of the project before they moved to implementation full-time.

With the quite big workload to analyse the requirement for the new features (as well as preparing the implementation), we are thinking that it could make sense to have dedicated product owner. However, this job would not fit in our organization (those people may still be officially SW Developers) and because of the waterfall approach, they may have to get back to code in few month.

Should we have dedicated Product Owner in waterfall project? Or using developers for the job is ok.

2 Answers 2


There is already a product owner. Since you are in a buy-seller relationship, as evidenced by your use of "our client", then the product owner is on the client side. Someone there is responsible for the product and its use in that organization.

Question becomes, are you looking for someone in the seller organization to work as sort of a counterpart to the buyer's product manager. That role is typically fulfilled by the project manager, who is accountable for the delivery of the product within specs. Is there a piece of responsibility, accountability, or tasks not being fulfilled well that sparked this question? If so, it may not be a missing role but something missing within the PM's role in the seller's organization.

  • On the client side they have what they call "Function Expert" which are indeed similar to what could be called "Product Owner". They write requirements for each function and send it over to us to actually make the product. At the beginning, when we started from scratch, the developer just took the requirements and design the system. However, today those requirement are moving and new features are added to the existing system and we have a gap between our client and the developers that we try to fill. Adding PM could be another solution (but this role involve many other tasks...)
    – valeuf
    Commented Aug 20, 2013 at 22:59


You aren't missing a job title, you're missing a role. You may also be missing the team capacity to fill the necessary roles for what is essentially a second project.

The Business Analyst Role

[W]e need to conduct requirement analysis/impact analysis before getting anything done.

This is typically the role of a business analyst, although it often involves coordinating with the development team and stakeholders. While the Product Owner (PO) in Scrum has a lot of responsibilities similar to those of a business analyst, the PO role is really much bigger than that.

The person (or people) who perform analysis and reporting need a skill set, not a job title. If you have developers who have the skills to perform business analysis, fine. If not, then giving them a temporary title won't make them any more competent in that regard.

In other words, what you really need to do is define what responsibilities this missing role should have, and then find someone within your organization with the skills to manage those responsibilities. It doesn't matter if their job title is Product Owner, Business Analyst, or Senior Bottle-Cap Collector; it's the role that's important.

Team Capacity

[O]ur client is asking [us] to work [on the] next major release (parallel development).

Creating a Product Owner or Business Analyst role will not solve your capacity problems. Your team is already fully-committed to working on the current release. Once you fill the missing analyst role, who is going to do the actual work on this parallel release?

The correct thing to do would be to create a separate team to work on the parallel development. Asking your existing team to work on two separate releases at the same time increases overhead, reduces efficiency, and will probably lead to over-engineering or cross-contamination of requirements.

At this point, some folks may object that they don't have the organizational backing or financial resources to run two teams. That's fine if the business accepts the process or schedule risk; just be cognizant that you are taking a sub-optimal approach, and don't expect one team to do the work of two.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.