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

Advanced Scrum Product Ownership – Riding Dinosaurs

Facebook
Twitter
LinkedIn
Pinterest
WhatsApp

What does Scrum Product Ownership have to do with Dinosaurs?

We typically say that Scrum Masters get to herd cats. But Scrum Product Owners actually need to learn how to ride a Dinosaur! With the click-bate established, what does that even mean? 

I’ve been using a visualization that people find useful for understanding the relationship between the various Lean/Agile requirement containers. Some people call the full model a dinosaur. Others are reminded of the snake who ate an elephant from “The Little Prince”. (I’m sure there is a good connection to elephant carpaccio somewhere in here …). In this article, I’ll explore this model and connect it to the stances of the Scrum Product Owner

Identifying a Unique Value Proposition

IMG_0449

A lot of teams and organizations expect their Product Owners to be a mix of the Story Writer, a Backlog Manager, a Project Manager, a Subject Matter Expert, or a Gate Keeper. Sometimes they’re even asked to be a requirements Clerk. These stances can be easier and familiar but when these are the expectations and when this is the stance that the Product Owner assumes, It’s hard to deliver value with Scrum. 

In the PSPO-Advanced one of the first preferred stances, we talk about is the Visionary. The Product Owner as an entrepreneur. This vision will be based on customer and market insights. As a Customer Representative, you’ll use techniques such as Design Thinking, Empathy maps, Value Proposition Canvases, and Jobs to be Done to create a vision that’s grounded in understanding the customers. You’ll identify a Unique Value Proposition – the area where your product/service will be unique. 

The Minimum Viable Product (MVP)
IMG_0450

Very quickly even while assuming the stance of the Visionary, you need to also wear the Experimenter hat and that’s because this Unique Value Proposition is just a hypothesis that needs to be validated. So the next step is creating a Minimum Viable Product (MVP) to test your hypothesis. This is focused on your unique value proposition but typically also provides a little bit of “Table stakes” features just to make sure it is “Viable” as a product.

Evaluating your MVP Hypothesis

IMG_0451

Your MVP is also a hypothesis. It might be good enough to find Product-Market Fit or not. The case where each potential customer you engage tells you “This is great but in order for me to use it I need X” and X is different for each customer/user is shown below. This shows you are not in a Product Market Fit yet. 

At this point, you’ll need to be very careful not to fall for the trap of mistaking the Customer Representative for the Customer Order-Taker. The fact that potential customers are asking for something doesn’t NECESSARILY mean your product should include it. It’s ok to evolve your vision for the product based on validation but saying YES to everything even if it’s all over the place is probably not gonna create a great product. These will be tough decisions but an effective Product Owner is also a Decision Maker (also known as the Tough Decisions Maker…)  

Pivot?

IMG_0452

If on the other hand, you are seeing more and more requests for the same capability you didn’t include in your MVP then it makes sense to revise your Customer/Problem/Solution Hypothesis. 

IMG_0453

You essentially are executing a Pivot. You are building MVP2 focused on the new hypothesis based on recent Customer Development learning generated by the previous MVP.

IMG_0454

Growth Stage

Let’s say MVP2 is successful and you are seeing real traction from early adopters. You want to increase growth and are looking for deeper penetration of your early adopters as well as bringing on new clients some of them beyond the early adopter’s crowd. Based on feedback you’ve been collecting and your product management research you have a couple of areas that can potentially bring this growth. Some of them, by the way, extend your unique value proposition and some of them make your current product more robust. As your product grows, your team and ecosystem will grow. You’ll need to assume the Product Owner as Collaborator and Influencer stances as well – working with new stakeholders, partners, a larger team, and maybe multiple teams working with you on the same Product via the same Product Backlog. 

Steady Growth with Minimally Marketable Features

IMG_0455

In the case of areas with a strong indication of value, you might go straight for Minimally Marketable Features (MMF). Finding the minimum piece that can start bringing in growth. The aim of the MMF is to bring value. It assumes high certainty that there is value in this area and that we know what the product needs to be to provide this value. The reason to break a big feature into smaller MMFs is mainly time to market and the ability to bring in value in many areas, always keeping your option to move to another area and provide value in it rather than focusing for too long on a single direction. An indication that you are working on MMFs is that when one is being shipped you feel comfortable working on the next MMF in that area. 

As the Visionary Product Owner, You’ll continue to provide and communicate an updated Value north star for the Product. You’ll be a Customer Representative who is also a Decision Maker for which direction it makes sense to focus and when it makes sense to move on rather than continue to invest in an area where you’re seeing diminishing returns. 

Experiment using MVFs

IMG_0456

Even with an established product sometimes you remember that a Product Owner is an Experimenter. Sometimes it is not clear whether a feature really is marketable and valuable. In these situations, your hypothesis is centered on a feature rather than your product. You have an area with high potential but also high uncertainty. The way to deal with it is to build a “pioneering” feature – the Minimum Viable Feature. The minimum feature that can still be viable for real use and learning from real customers.

IMG_0457

If you learn that the MVF has hit gold you can develop more MMFs in that area to take advantage (if that makes sense). If not, you can pivot to another approach towards that feature area, or at some point look for an alternative growth path. Essentially the MVF is a mini-me version of the MVP.

Voila – The Scrum Product Ownership Dinosaur!

IMG_0458

There you have it. The full model. Essentially my point is that you grow a product in uncertain markets by attempting various MVPs. Then once you achieve Product-Market Fit you mix MMFs and MVFs depending on the level of Business/Requirements uncertainty in the areas you are focusing on.

While MVPs/MMFs/MVPs are atomic from a business perspective (you cannot deploy and learn from something smaller) they might be quite big from an implementation perspective.

If your organization positions you to be a Clerk, Story Writer, Manager, Project Manager, SME, or Gate Keeper you won’t get far trying to ride this dinosaur. 

You’ll have a much better chance if you can switch between being a Visionary, Collaborator, Customer Representative, Decision Maker, Experimenter, and Influencer – the effective stances of the Scrum Product Owner (Which we cover in the PSPO-Advanced workshop) 

Author’s Note: This blog post is an update of an article I wrote ages ago – weaving in the Product Owner stances which are a perfect fit in my opinion. Yuval

Subscribe for Email Updates:

Categories:

Tags:

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