The Pragmatic Marketing framework and the Product Owner position

According to the Pragmatic Marketing framework these are the Skills and Responsibilities attributed to those functions usually associated with the Product Owner position. 


Articulate and prioritize personas and their problems so that the appropriate products can be built.

• Articulate and prioritize problems that solutions should be built for
• Build an effective relationship and team between product and development
• Serve as a checkpoint along the way to provide context and clarification to development
• Technical and product-specific acumen
• Written and verbal communications
• Deep market knowledge and understanding of personas and their problems
• Understanding of design best practices

Use Scenarios

Illustrate market problems in a “story” that puts the problem in context. Use scenarios are one component of requirements.
• Illustrate market problems in a way that puts the problem in context
• Create problem-based requirements
• Document and provide context on how the problem shows up in a day in the life of the user
• Ability to gather market data and then do detailed, independent analysis
• Data synthesis
• Ability to provide context in a way that is easily relatable to various audiences
• Storytelling
• Clear and concise writing

Stakeholder Communications

Manage proactive communications with relevant stakeholders from strategy through execution.

• Manage proactive communications with relevant stakeholders from strategy through execution
• Provide relevant, timely and easily consumable updates to all internal and external audiences
• Define key metrics and goals related to project progress and success
• Measure and report on progress toward metrics and goals
• Understanding of roadmap, release plan and project plan
• Written and verbal communications
• Ability to delegate and work well with project management resources
• Ability to manage resources up, down and sideways

Product Manager vs. Product Owner in the context of mature Product Mngt. organizations

This is the traditional view of Product Management from Pragmatic Marketing

Three domains are highlighted with circles: Strategic Management, Marketing and Technical Management. 

Every function must exist on a Product organization

Each of these functions must have one or more R and a single A in terms of Responsibility assignment matrix

It has been my own view that I fall on the Technical Product Managemnr domain; I usually have A and/or R on these functions.

As PM is a leadership position within the Product organization, I would expect to be as C or I  in all functions of the RACI matrix of the Product organization. In some instances, the definition and analysis of User Personas and Buyer Personas may also fall as R or A, on the shoulder of the PM. 

The PO, which is a SCRUM construct, has a subset of the Tech PM. On many organizations, it is clear that PM should act as PO on the context of the development team practicing SCRUM. This subset of functions may be open for discussion, but I do not want to discuss that here.

However, some organizations, contract directly to the position of PO, which may indicate that the other tech functions are orphaned, or under the Strategic management. This may be the best configuration when you have multiple product layers; for instance: Content product, Front End product and API product (I experienced this many times at Elsevier, and yes I advocate that the API use of a product must have its own product team. I saw, also at Elsevier, a single functionality have its own Product Manager: the export function on Scopus (Yes, a manager for a button). 

At a certain point in the Job Interview you must scope what are going to be the Product Functions “assumed” to fall under Product Owner, where he is to be Accountable and/or sole Responsible, as well as what will be the KPI’s on each one. 

It would also be preferable, once this is cleared that the Informed and Consulted for each other function be discussed… most important of which is the Roadmap function.

It is important to note that these are the responsibilities from the POV of the Product organization. The SCRUM POV also has to be delivered by the PO. The overlap of responsibilities according to both POV’s is not a perfect match. 

Source: and

If we think of Documentation as a SPRINT deliverable, can we indeed have Agile and CSV?

Question on a LinkedIn group:

V model for Agile?

Life Science industry is using traditional V model for CSV. Should this model be changed for Agile based development, testing and validation.
I believe we should be able to use the user stories instead URS as the basis of V model. Please share your thought. Thanks

PJ Singh, PMP
Co-Founder & Director – Quality, Compliance, Validation, and Technology Integration

I’ve found out, during my tenure as Scrum PO for a GxP regulated product, that if you have a documentation resource, usually a Business Analyst, embedded in the SCRUM team, constantly making sure that there is documentation alignment between URS and User Stories, and make the documentation part of the Definition of Done, you can have a very strong alignment between V model and Agile practices.

I’m willing to propose and defend that, for implementing CSV while practicing Agile, one needs to have Documentation as a SPRINT deliverable.

21 CFR 11 Reflections: 10(a,c,d)

When I read regulatory documents I always try to imagine what possible reason can there be for someone to write a regulation and what may have been the real world case(s) that will be prevented by that text.

Sometimes it is clear that a text not only is intended to have specific consequences, but also is based on real historic situations that went bad for the community… because the regulation was not in place. Anybody with more than 5 years in programming and system management can clearly see the root cause for almost each and every item in 21 CFR 11 .

For Example:

21 CFR 11.10(a): Validation of systems to ensure accuracy, reliability, consistent intended performance, and the ability to discern invalid or altered records.

This imposition must derive from situations where the regulated company said that the “software” was bought as it was, in full confidence that the sellers promises of quality and fulfillment of the regulatory requirements, were true.

Many times the promises may even have been made in good faith but if an audit shows that the software product does not fill the requirements, does not impede irregular situations, etc… then the regulated company is at fault of not doing due diligence during the procurement process.

21 CFR 11.10(A) requires that regulated companies perform due diligence when contracting a piece of software for purposes that are regulated. And the due diligence, albeit Validation can mean many different things, simply means that the regulated company should draw a set of requirements and that it should verify and document that the contracted software fulfills the requirements.

Most of the FDA documents regarding Electronic records are just codified common sense, like: “[…] we believe it would not be prudent to store both primary and backup electronic records
on the same computer hard drive because both could be lost if the hard drive fails.” Draft of  “Guidance for Industry 21 CFR Part 11; Electronic Records; Electronic Signatures; Maintenance of Electronic Records”

Does this mean that “Backups must not reside on the same Infrastructure as the original backed up data” should go into the Requirement Specification? Yes. As a requirement of 21 CFR 11?  If that is the way to get the requirement in there. But it should be in the specification because it is common sense.