Search
Close this search box.
Search
Close this search box.
Search
Close this search box.

The Product Manager / Product Owner AS A Scientist

Facebook
Twitter
LinkedIn
Pinterest
WhatsApp

We’ve all heard it before – “Talented technology team builds amazing products!” That… doesn’t create the impact that they wanted, not enough customers end up buying or the users aren’t happy with it, or <some other disappointment>…

This is an especially common problem with companies that have a “brilliant” idea or technology that someone goes developing in their garage (if startup) / innovation product development group (if enterprise). This could be a new product or just a new feature of an existing product. Typically, the Product Owner or Product Manager in the organization specifies what to build. If they’re somewhat Agile, they even work closely with the organization to build it incrementally and hopefully deliver it continuously. But still, even then, too often the product or features don’t provide the expected impact/benefits. Overcoming this challenge is a common theme that is discussed by attendees at our SAFe POPM Course.

The POPM is often SURE they know what’s the right thing to build (aka the “God complex”) – usually this is based on market research, customer interviews, etc.

But too often, the POPM doesn’t know that they don’t really know. Other times, the POPM knows that they don’t know, but aren’t sure how to drive the learning so that more is known.  The Agile approach is to build a working product and engage on an on-going basis with the customer, getting early feedback so that as a result of the customer’s interaction with your product – you will gain knowledge.

Does this sound familiar from another domain/world? Where else do people make concerted learning a matter of principle?

As can be guessed from the title of this article – the answer is in science – a close cousin of engineering. One of the basic pillars of modern science is using the scientific method and specifically its well-known-but-hard-to-pronounce hypothesis.

For those who are a bit fuzzy or unconvinced about how closely the hypothesis fits in here – the meaning of hypothesis as per the dictionary:

  • A supposition or proposed explanation made on the basis of limited evidence is a starting point for further investigation.
  • A proposition made as a basis for reasoning, without any assumption of its truth.  
    [emphasis added]


The famous British Biologist Thomas Huxley (a friend of Charles Darwin) once said:

“The great tragedy of science – the slaying of a beautiful hypothesis by an ugly fact.”

Archangel Michael slays the Devil. Painting by Guido Reni.

Who would have thought there could be such drama in science and the hypothesis 🙂

With this in mind, let’s see how “without any assumption of its truth” and “starting point for further investigation” applies to the POPM roles.

To approach things as a scientist, a POPM should first modestly understand that they have some underlying assumptions, honestly identify them, curiously phrase the hypothesis and openly and bravely seek the truth by evaluating the outcomes and then flexibly adjust based on the learnings.

For example, phrasing the expected business outcome as a hypothesis could be as follows:

We hypothesize that Feature A will generate 30% more transactions (or will cause users to do things 20% faster or to make 15% fewer mistakes, whatever the expected outcome).

It can be much simpler to have this approach as a startup, after all, you typically have to prove yourself quite quickly or the money will run out. In a larger more traditional enterprise, it’s often more difficult to adopt this mindset for various reasons such as the long lead time until reaching the customer to test the hypothesis, on-premise B2B environments, high customization as in professional services, etc. Nevertheless, as a POPM, one must always strive to make the desired impact, regardless of the organization’s size. In fact, the importance of having the right mindset in an enterprise is incredibly important to minimize the waste of developing too many (wrong) features. In large organizations, this is true for both Product Owners and Product Managers.

Once the hypothesis has earned its place of respect, as Konrad Lorenz once said:
“It is a good morning exercise for a research scientist to discard a pet hypothesis every day before breakfast. It keeps them young.

So, to openly and bravely receive the truth, the POPM must evaluate the measured outcomes and decide whether they must show flexibility and discard their hypothesis or keep it. The Lean Startup movement introduced the terms for this as to pivot (change direction) or to persevere (keep on with the direction).

Applying pivot might feel difficult to the POPM, as it means that we have disproved our hypothesis. On the other hand, we will have learned something and hopefully avoid an “OMG” headline, and as Lorenz said, pivots keep us “young” 😉

Subscribe for Email Updates:

Categories:

Tags:

Lean Agile Organization
AgileSparks
predictability
Professional Scrum with Kanban
Continuous Improvement
Product Management
Jira admin
Artificial Intelligence
User stories
Lean Risk Management
Elastic Leadership
Program Increment
Sprint Retrospectives
Software Development Estimation
PI Planning
Agile Games and Exercises
Games and Exercises
ATDD
An Appreciative Retrospective
Hybrid Work
Reading List
Atlaassian
System Team
Jira
Self-organization
Continuous Deployment
The Kanban Method
Scrum Master
Agile Games
Change Management
speed at scale
Nexus and Kanban
Jira Plans
DevOps
RSA
Entrepreneurial Operating System®
Managing Risk on Agile Projects
Continuous Planning
Agile in the Enterprise
Scrum.org
Video
ART Success
Agile Outsourcing
GanttBan
Agile Contracts Best Practices
Implementing SAFe
Amdocs
System Archetypes
Business Agility
Nexus Integration Team
Advanced Roadmaps
Engineering Practices
Implementation of Lean and Agile
SA
Nexus vs SAFe
Atlassian
Scrum Values
Daily Scrum
Limiting Work in Progress
QA
The Agile Coach
Webinar
Scrum Master Role
LeSS
Rapid RTC
Quality Assurance
Spotify
Scrum Guide
Tips
A Kanban System for Software Engineering
Applying Agile Methodology
Agile
Agile India
Lean Agile
Agile Product Development
Lean Agile Management
Lean-Agile Software Development
Covid19
Built-In Quality
Slides
Introduction to Test Driven Development
AI Artificial Intelligence
What Is Kanban
Kanban Basics
Agile Mindset
Kanban 101
Sprint Iteration
Scrum and XP
Agility
Acceptance Test-Driven Development
Kaizen Workshop
Principles of Lean-Agile Leadership
Process Improvement
SAFe DevOps
Agile Assembly Architecture
Lean Startup
Introduction to ATDD
Accelerate Value Delivery At Scale
Professional Scrum Master
Planning
Software Development
Agile Risk Management
Risk Management on Agile Projects
BDD
Continuous Integration
Coaching Agile Teams
System Integration Environments
speed @ scale
Lean and Agile Techniques
TDD
Perfection Game
Large Scale Scrum
Kaizen
Agile Release Planning
Nexus and SAFe
chatgpt
Scrum
Presentation
Legacy Code
IT Operations
Code
Team Flow
Managing Projects
Legacy Enterprise
Agile Development
Product Ownership
Agile Testing Practices
ROI
SPC
Sprint Planning
WIP
NIT
agileisrael
Certified SAFe
Agile Israel
LAB
PI Objectives
Story Slicing
Value Streams
Lean-Agile Budgeting
Scrum Primer
Effective Agile Retrospectives
Continuous Delivery
Agile Israel Events
Frameworks
Keith Sawyer
POPM
Risk Management in Kanban
Iterative Incremental Development
Agile Marketing
SAFe Release Planning
EOS®
Kanban Kickstart Example
SAFe
Agile Project Management
Lean Software Development
ARTs
AI
Lean Agile Basics
Lean Budgeting
ScrumMaster Tales
Nexus
Agile Project
Agile Techniques
RTE Role
Agile Release Management
Kanban Game
Achieve Business Agility
ATDD vs. BDD
ALM Tools
Certification
Risk-aware Product Development
Agile Delivery
Manage Budget Creation
Release Train Engineer
Agile Community
Agile Program
Portfolio for Jira
Lean Agile Leadership
Professional Scrum Product Owner
Agile Product Ownership
lean agile change management
Agile and DevOps Journey
Agile Exercises
Tools
Jira Cloud
LPM
Agile Basics
RTE
Lean and Agile Principles and Practices
Scaled Agile Framework
Releases Using Lean
Development Value Streams
Systems Thinking
Test Driven Development
Agile for Embedded Systems
Scrum With Kanban
Kanban
Operational Value Stream
Enterprise DevOps
AgileSparks
Logo
Enable registration in settings - general

Contact Us

Request for additional information and prices

AgileSparks Newsletter

Subscribe to our newsletter, and stay updated on the latest Agile news and events

This website uses Cookies to provide a better experience
Shopping cart