How has the role and function of product management evolved over the years? In this talk, I have shared my notes from my personal journey over the last 25 years.

1. 25 Years of Evolution of
Software Product Management:
A practitioner’s perspectives
Tathagat Varma
Strategy & Operations,
Walmart Global Tech
Doctoral Scholar (EFPM2019-22),
Indian School of Business
Pic: https://www.bajajelectricals.com/blog/expert-speak/the-evolution-of-light-from-incandescent-bulb-to-iot-based-smart-and-human-centric-lighting-part-1/

2. What is this talk about?
• The story behind the evolution of software product
management through my personal experiences with
various product companies in last ~25 years.
• By no means is this an authoritative or a comprehensive
history – think of it more like a diary of a practitioner!
• Hopefully, it gives you a longitudinal view into some of
the product journeys during this time period.

3. As many
products,
as many
PMs!
https://www.pragmaticinstitute.com/resources/articles/product/where-does-product-management-belong-in-the-organization/

4. http://enlogica.com/uncategorized/what-is-a-product-manager/

5. PMMs & PMs I have worked with:
• Hospital workflow software (B2B): a 30-year experienced
nursing/ healthcare professional (Product Manager), domain
+ project management + tech (Requirements Manager);
engineering management + tech (Requirements Engineer /
me)
• Digital set-top box (B2B2C): a PhD in Computer Science
• Network Management (B2B): Tech + Management
• B2C Consumer Internet (B2C): Management + Tech
• Gigabit core router, Routing platform (B2B): I J
• …

6. The Waterfall / V Model Era
(1990s – 2000s)
• MRDs were the “mother deed”
documents! It established the raison
d'etre, as well as the vision, the
marketing roadmap, etc. Marketing /
Product Marketing folks wrote it.
• PRDs were created by Product
Managers to specify product
requirements.
• FRS / SRS were the lowest level of
specs of what exactly was required
from software team!
• Overarching Philosophy: Safety in
numbers / Measure twice, cut once!
MRD
• Marketing
Requirements
Document
PRD
• Product
Requirements
Document
FRS
• Functional
Requirements
Specs
SRS
• Software
Requirements
Specs

7. Anatomy of an MRD
5-year
• Laundry list for
next 5 years!
This release
• What is required
in this release
• Typically
prioritized as
MASCOW
Next release
• Requirements
for the next
release
• So that
development
team could
keep it in mind
for upcoming
extensibility

8. The Big Fat PRD!
• Literally, the BIG FAT PRD!
• Hardware + Software + Firmware + Product Design + Memory +
Performance + Design …
• I once led a group of ~20 architects and we co-wrote a 200-page
PRD in one month! Led two more similar-sized (code size added
600k-1MM per release)
• Product decisions often led from one of the following
considerations:
• B2B: Technical specs / largest accounts / Contract-driven
specs/date/budget
• B2B2C: Cost!
• B2C: Christmas!

9. Functional / Software
Requirements Specs
• FRS: For non-pure Software systems (e.g. hardware,
systems, etc.)
• SRS: For pure-software systems, or the software
subsystems
• Malcolm Baldrige TQM Criteria + ISO9000 orientation +
+ CMM framework + Six Sigma + …
• Volere Requirements Specifications
• Usage of “shall” / “should”, completeness, correctness,
traceability, feature parity, needs (vs wants), etc…

10. Just-in-case
Product
Management!

11. What about the UI, UX, and
Design?
• Now I know: Software engineers don’t make a good
designer ;)
• Information Architecture + User Interface / Look and
Feel + Interaction Design + Navigation + Graphical +… =
“GUI” and done by your friendly neighborhood dev
team!
• Often captured in UI FRS!

12. Grandfather, Son, Grandson…

13. Product Maturity (illustrative)…
• End of Life (EOL)Version N-2:
• End Of Sales (EOS) / MaintenanceVersion N-1:
• Field / SupportVersion N:
• Under developmentVersion N+1:
• Being spec’dVersion N+2:
• Idea?Version N+3:
Past
Present
Future

14. The Good, The Bad and The Ugly of
CCBs!
• Once the requirements were “baselined”, the CCB would kick in.
• Change Control Board, or the CCB was meant for effectively
managing the changes to specs
• Typical process:
• Perform an impact analysis of a given Change Request (CR)
• Submit the CR to CCB
• CCB might meet weekly and discuss / dispose of CRs
• Smaller ones might be absorbed in existing project plan (schedule, budget)
• Medium ones might need extra schedule to deliver
• Large ones might need rearchitecture / major redesign, additional budget
and / or schedule

15. Feature
Creep
https://headrush.typepad.com/

16. Grandma’s
Remote!

17. Version / Release / SP / Hot Fix /
Patch …
What Frequency Example
Major Version New architecture 1-3 years 1.0, 2.0, 3.0, …
Minor Release New features 6-12 months x.1, x.2, x.3, …
“Major minor
release”
x.5
Service Pack (SP) Mostly CRs and PRs 3 months SP1, SP2, SP3…
Hot Fix Smaller collection of
PRs
As/when
Patch A solitary PR
needing urgent fix at
one customer
ASAP

18. The Agile Era (~2005 onwards)
Waterfall SDLC Agile Development
MRD + PRD + FRS + SRS Product Backlog + Sprint Backlog
Baselined Continuously updated and alive
Detailed requirements Lightweight user stories
Change control through CCB Change anytime! (except in the current
sprint)

20. The Kanban Fix!
• What do you do when you have no backlog?
• The work items are arriving all the time, e.g. field issues?
• We “stumbled” on it in 2004-05

21. https://www.slideshare.net/Managewell/applying-kanban-in-enterpriseclass-products-sustaining-engineering-an-experience-report

22. Product Discovery
• Innovation Games
• Design Thinking, Design Sprints
• Lean Startup, MVP
• Ethnography, Needsfinding
• Data-driven / Data-informed

23. What next?
• Growth in platform-based business models
• Personalized / customizable products
• No-code software
• AI-based solutions
• AIOps, MLOps…