3. COO
The chief operating officer (COO) is a
senior executive tasked with overseeing
the day-to-day administrative and
operational functions of a business.
People Process
Technology
Operational
Efficiency
5. INTERNAL PROJECT PORTFOLIOS
● Transformation of culture and processes
● Security
● Digital Transformation
● HR Processes
● Employee Brand
6. CLIENT SERVICE PORTFOLIOS
Product design projects
Product development projects/programs
Digital Transformation project/programs
Support & Re-Engineering
8. PHASE 1 / PLAN-DRIVEN APPROACH
SOW
Formulation
Project
Approval
Project
Initiation
Project
Execution
Project
Closure
Project
Control
Tracking and feedback
SOW formulation Project Approval Project Closure
Project Initiation
Project Execution
Project Control
Requirements from
Customer
Requirements analysis
SOW generation
SOW approved by Customer
Project Manager assigned
Scope with WBS, assumptions,
constraints, and project objectives
Schedule based on WBS resource
requirements from schedule
Budget from schedule and
resource requirements
OC plan
Risk plan
Linear Responsibility
Chart
Team assignment
Team training
Quality Assurance
Project communication
Budget variance control
Schedule variance control
Quality control (QC)
Scope change control
Risk management
Issue tracking and resolution
Formal acceptance of
deliverables by customer
Archiving project files
Document lessons learned
10. PLAN-DRIVEN APPROACH / SUMMARY
● Fixing requirements does not work
● Design upfront never works
● Original plan never works
● Frequent change requests are painful
● Late feedback
● Silos and lack of context
● Project Managers focus on tracking budget and timeline, instead of
solving the real problem
11. PHASE 2 / AGILE APPROACH
Individuals and
interactions
Working product
Customer Collaboration
Responding to change
Processes and Tools
Comprehensive
Documentation
Contract Negotiation
Following a plan
over
over
over
over
That is, while there is value in the items on the right, we value the items on the left more.
12. AGILE APPROACH / SDLC
Requirements Design Development Testing Deployment
Development
Project Timeline
Waterfall Project
Agile Project
Sprint Planning > Review > Retrospection Sprint Planning > Review > Retrospection Sprint Planning > Review > Retrospection
Big
outcome
at end
Cumulative
outcome
Cumulative
outcome
Cumulative
outcome
Value
13. AGILE APPROACH / INITIATIVES
● Projects replaced by long term “Initiatives”
● Initiatives can be implemented by a series of iteration with tactical
goals to achieve the end goals
● Initiatives are ongoing
● The number of iteration is defined by business goals
● Project management moves to iteration management
16. AGILE APPROACH / PLANNING
"Plans are nothing;
planning is everything."
Dwight D. Eisenhower
17. AGILE APPROACH / FEEDBACK LOOP
Code
Release plan
Iteration plan
Acceptance test
Stand-up meeting
Pair negotiation
Unit test
Pair programming
Months
Weeks
Days
One day
Hours
Minutes
Seconds
18. AGILE APPROACH / TEAM
PO Dev
team
Coach /
Manager
Build the
thing right
Build it fast
Build the
right thing
Product Tech
Process
22. AGILE APPROACH / DELIVERY MANAGER
Agile & Lean
practices
Team health
& happiness
Delivery
support
23. AGILE APPROACH / SUMMARY
● Projects replaced by Initiatives
● Plans are nothing, planning is everything
● Continuous Feedback Loop
● No silos, direct communication enable empathy
● Team owns and understand the product
● Team based SOW – no need to revisit budget with every change
● Safe env for mistakes and learning (unable innovation)
● Delivery manager as sport team coach – achieve goal every play, tournament,
season
26. AGILE APPROACH / CLIENTS COMPLAINTS
● Team does not understand me
● Team does not do right things
● They implement useless features
● I want to give feedback more often
● Why scope negotiation take so long?
● I do not attend demo because you have nothing to show (useful)
● Why team is so slow?
● Why solutions are so overcomplicated and expensive?
27. ● Choose the right PO (senior customer)
● Avoid Proxy PO antipattern (BA as PO)
● Silos are evil
● Find other use for BA
● Developers are not idiots
● They should solve customer problems, not only develop features
● They can solve customer problems
● Just create right environment for them
AGILE APPROACH / SUMMARY
28. SCRUM APPROACH / RESULT
PLAN-DRIVEN
SCRUM
FEATURE
DEVELOPMENT
TEAMS
31. AGILE IS A MINDSET
AGILE IS A
MINDSET
DESCRIBED BY
4 VALUES
DEFINED BY
12 PRINCIPLES
MANIFESTED THROUGH
UNLIMITED NUMBER OF PRACTICES
MINDSET VALUES PRINCIPLES PRACTICES
KANBAN SCRUM SAFe®
33. AGILE HAS NO BRAIN
WHICH
features should
we build?
DID we build
the right ones?
DID we design
them well?
DID we optimize
them to achieve
maximum value for
our customers and
our business?
38. MENTAL MODEL OR MINDSET
Tools &
processes
Practices
Principles
Values
Mindset
Intangible, yet very
powerful
Highly visible
but less powerful
Change
less often
Dynamic -
change often
40. A product is anything
that can be offered to a
market to solve a
problem, or to satisfy a
want or need.
WHAT IS PRODUCT?
41. WHAT IS PRODUCT?
USERS
(what they need →
problem space)
BUSINESS
what they can give →
solution space
TECHNOLOGY
Product can be defined as the result of the processes between :
50. RULE #1: LOVE THE PROBLEM, NOT YOUR SOLUTION
Product
Product
Market
Market
Problem Space Solution
Space
We need X Let’s ship Y
Product-market fit
Reduce
gap
51. RULE #2: THINK IN PRODUCTS, NOT IN FEATURES
FEATURES PRODUCT
54. RULE #1 / USE DOUBLE DIAMOND
�� 🚀
��
��
☑
DEFINE
UNDERSTAND IDEATE PROTOTYPE TEST
PROBLEM SPACE SOLUTION SPACE
C
O
N
V
E
R
G
E
C
O
N
V
E
R
G
E
D
I
V
E
R
G
E
D
I
V
E
R
G
E
?
?
CHALLENGE SOLUTION
RE-FRAMED
PROBLEM
?
57. RULE #1 / LEAN STARTUP (MVP)
Not like this
Like this
Original image https://www.rabitse.com/blog/minimum-viable-product-development-guide/
58. RULE #1 / SUMMARY
DISCOVER DESIGN DELIVER
Problem Space Solution Space Execution Space
Real
Problem
Product
Market
Fit
Research Define Ideate Prototype Build Validate
Problem
Defined
Solution
Defined
Agile
Design Thinking
PRODUCT THINKING
Original chart: https://medium.com/@sahu.sudarsan/7cfaa6a569d7
60. RULE #2 / PRODUCT VISION
Vision
What is the reason for creating product
What positive change should it create?
Target Group
Which market or market
segment does the product
address? Who are the target
customers and users?
Needs
What problem does the
product solve, or which
benefit does it offer? If you
identify several needs,
prioritise them and move the
most important one to the
top.
Product
What product is it? What are its
three to five stand-out features
that set it apart from
competing offering? Is it
feasible to develop the
product?
Business Goals
How will the product benefit
the company that develops
and provides it? What are
the desired business
benefits? Prioritise them and
move the most important
one to the top.
Original chart https://www.romanpichler.com/blog/tips-for-writing-compelling-product-vision/
62. 1st quarter 2nd quarter 3rd quarter 4th quarter
MVP Version 2 Version 3 Version 4
- Acquire an initial user
base
- Understand my eating
habits
- Grow the user base
- Improve my eating
habits
- Generate revenue:
in-app purchases
- Get fitter
- Retention
- Keep up the good
work
- Healthy eating
dashboard
- Integration with
smartwatches and fitness
devices
- Recipes and
shopping lists
- Social media
integration
- Personalized advice
(coach)
- Weight loss
- Integration with
scales
- Enhanced eating
tracker
- Integration with
smart food scales
Be in the top 15 diabetes
app six weeks after
launch
Activations,
engagement, NPS
Revenue from in-
app purchases two
weeks after release
Engagement, NPS,
monthly recurring
revenue
RULE #2 / GOAL BASED ROADMAP
69. PRODUCT THINKING / SUMMARY
● Rule #1: Enable business driven problem solving
● Rule #2: Enable alignment
● From now, Agile has brain
● You can stop using our own
● Transition from “feature development” team “product development
team”
74. PM MODEL EVOLUTION
Plan driven development
(no alignment, no autonomy)
Feature development
(no alignment, high autonomy)
Product development
(high alignment, high autonomy)
Product centric organization
1
2
3
4