What is the Product Owner's role/responsibility in a proof of concept with an external vendor?

Question

The team is conducting a proof of concept related to checking the capabilities of an external software solution to be added/integrated into our platform. Of course, the PO needs to have all Epics and Stories ready and prioritized for team planning, but are there any other responsibilities that this specific PO should own in this situation? For example, who should communicate/coordinate/liaise with the vendor, set a plan, etc.? Should there be a Project Manager assigned? Or does the Product Manager or Scrum Master own that part?

Answer 1

The Product Owner role as defined by the Scrum Guide says nothing about working with a vendor.

are there any other responsibilities that that PO should own in this situation?

That depends on a number of factors, including:

• The skill set of the Product Owner
• How much time they have available
• Whether they are interested and want to get involved in non-traditional Product Owner activities
• The capabilities of other team members

Or does the product manager or scrum master own that part?

Again, the Scrum Master role as defined in the Scrum Guide says nothing about working with a vendor.

My suggestion would be as follows:

• The Product Owner continues to do their role as defined unless they specifically want to get involved with working with the vendor
• The Scrum Master does their usual role in the team: supporting the Scrum process and helping to facilitate the removal of impediments
• The development team takes responsibility for dealing with the vendor

If the development team does not have the skill set needed to work with the vendor, then it may be worth considering adding a team member with the required capability. I have worked with Scrum Teams that have included somebody with a background in Project Management, and they were often the one that got involved with vendors/clients.

Answer 2

In a POC the Product Owner ought to be the decision maker, the person who will assess the suitability of the product being evaluated and make or recommend the purchase - or someone nominated by the decision maker(s). It's most important that they keep the team's focus on demonstrating the required evidence or learning the lessons that the POC is intended for.

I'd also suggest that Scrum may not be the best choice for a POC unless the expected duration is more than, say, one month. For a shorter piece of work Kanban may be more appropriate. The nature of a POC is that it's about discovery, learning and adapting continuously as you go. Scrum is all about iterative delivery, cadence and works well only if the outcome of each sprint can be defined during sprint planning - difficult to achieve on a short POC I would have thought.

PO seems like the right person to own the relationship with the vendor. Collaboration and adaptability is usually more valuable than planning but that might depend on the nature of the work and the relationship with the vendor. No Project Manager in Scrum because the PO is responsible for setting scope and priorities and the team as a whole is responsible for planning.

Answer 3

A Proof of Concept (POC) cannot be estimated in terms of story points, hours, nor any sizing you use, since it is all about trying to prove if a suggested model works or not. That's why, it cannot be included in a Sprint.

As far as I understand, the need to include it in the Sprints arises due to:

1. some of the Developers in the Scrum Team will be working on that POC
2. the output of the POC will be epics, stories, and/or tasks for the Scrum Team

You should approach this POC just like how you approach a bug from the production environment; have a Kanban board for these kind of activities and add the POC there. In terms of the workload of the Scrum Team members, you can use the same model you use when a member uses paid time off (vacation).

I would recommend the PO do the communication between the external and internal teams because the POC is mainly done for the PO; the outputs of it will define what needs to be done. While the PO does the communication, they can do the planning to act faster.

Answer 4

First, I would argue there is no such thing as a POC in an agile organization. You merely create an iteration of the product with the vendor's solution. Then if you don't like the results, the next iteration pulls that solution out.

Liaising is easy. The PO and team together only create the user stories for their part of the process--creating specs to give the vendor, assessing the results after the solution is in--and put impediments ("blockers") on the ones they can't do until the vendor delivers something. Any team member can take on the role of answering vendor questions; logic suggests it be the person with the most relevant technical knowledge. Then focus on other stuff until the vendor delivers something, clearing the blockers on the post-delivery stories.

The Manifesto provides some answers in the "Individuals and interactions..." and "Customer collaboration..." lines. There is no need for a "plan," and it doesn't matter which job title does what. For your part, you need only break the data mapping process into small enough stories that you can deliver a portion within a sprint, and if forced to do points, only estimate for that one story. (That said, your company is missing the point of points if it includes time required in the consideration. But then, I stopped using points years ago!)

Finally, it is not the PO's job to assess the solution. Teams are self-managing, which means it is the team's call. The PO is just one equal voice in that discussion.

Answer 5

A Proof of Concept (PoC) is a demonstration of an IT-based project's basic feasibility for one or more representative use cases. A well-planned and well-executed PoC ensures that a new IT solution's technical functionality works as expected. A product's bloodline and nucleus of product leadership is the product owner. The PO has power over the kind of features and functionality to construct, as well as the order in which they should be built. The PO also in charge of providing the team with a clear vision.

The PO is solely responsible for the overall success of the solution being produced or maintained as a product owner. Whether it's an external product or an internal application, the focus is the same. The product owner is nonetheless responsible for ensuring that the most possible work, including technically focused work, is always completed. The product owner engages with the scrum master and the development team to ensure that what the team develops meets the requirements.

In scrum framework there's no mention of the product owner liaising with the vendor but that doesn't mean if the product owner has the skills to do so s/he shouldn't do so.

Responsibilities of a product owner include but are not limited to: Participation in planning, Manage economics, Backlog grooming, Collaborate with the development team, Collaborate with the stakeholders, Conveys and the vision to the team and leading the team, Prioritizes work based on business value, Product owner negotiates with the team.etc. (reason for my comment above)

On the otherhand, the software engineer and the project manager complement one other's skills and collaborate on common tasks. Organizational liaison, personnel management, and project monitoring and control are the three key responsibilities of the project manager.

The project manager's role as a go-between for the technical team and non-technical agents is discussed in the "Liaison" portion of project management (such as project sponsors, users, IS management, vendors, and so on).

Some persons may argue that the product owner has no business with the vendor but rather a project manager is the best fit reason is mostly because: The Project Manager (and SE) create a Request for Proposal (RFP) document to obtain bids from possible providers. A contract must be negotiated once a vendor has been chosen. Negotiations may take place with the marketer, but they could also take place with a financial representative or the marketer's manager. Similarly, the project manager may handle all or part of the negotiations with the help of a financial expert or his or her manager.