1) The document discusses lessons learned from the author's experience working with multiple product management teams over 15 years. 2) Some things that worked well included truly understanding the product, customers, market, prioritizing feedback, and seeing the bigger picture. 3) Some pitfalls to avoid are not understanding the underlying technology, usability, performance issues, and getting swayed by hype without due research. Staying disciplined with agile processes and change management is important.

1. Product Management
Lessons from the other side

2. About Me
 ~15 years | ~12 products | Various roles
Name Gaurav Marwaha
What I do at
Nucleus
I have engineering ownership of product development for loan
origination product. Additionally own technology teams which deliver a
re-usable development framework.
Passionate
about
I am passionate about products, technology and usability. I also enjoy
working with product teams and have helped to groom and mentor
multiple teams.
Technology Java/ big-data/ analytics/ Spring/ ESB (Camel)/ Mobile/ Social
LinkedIn http://in.linkedin.com/in/gauravmarwaha/
2

3. Introduction
Having worked with multiple software products I had the
opportunity to interact with many product managers and
owners. This is an attempt to bring out some of the things
I learnt by observation.
Working on products across business domains and brilliant
people from different geographies gave a unique
opportunity to observe and learn.
This is not an attempt to bring out theoretical concepts of
product management.
3

4. Table of contents
Definition & Key stakeholders
Theoretical definitions and the key stake holders for a product
The product lifecycle
The product development life cycle and its correlation with the stake holders
Some lessons learnt – what worked
Things that worked well for teams in different stages of product development
1
2
3
Myths – what did not work
Things that did not work or had negative impacts on products
4
4

5. Definition & Key stakeholders
Theoretical definitions and the key stake holders for a product
1
5

6. Definition
Product Management
It is much more about the “product” than “management”. Hence managing
a product without knowing what it does is a big NO.
As defined by Wikipedia:
is the process of managing software that is built and implemented as a
product, taking into account life-cycle considerations and generally with
a wide audience. It is the discipline and business process which
governs a product from its inception to the market or customer delivery
and service in order to generate biggest possible value to the business.
6

7. Key Stakeholders
Customers/ Prospects Engineering/ Technology
PRODUCT
&
PRODUCT
MANAGER
Competitors CFO Office
Senior Leadership
Markets & marketing
Product is built for these
stakeholders and they
provide valuable
feedback to the product
teams.
7

8. Stakeholder Feedback
Customers
feedback on
product features
& ideas from
their needs.
Technology/
Engineering
drive & own the
choice of
technology &
platforms.
Competitors
feed in to
product
innovation &
strategy teams.
Marketing
research and
provides input
on markets and
geographies
Senior
leadership
provides vision
and strategic
direction. Brings
in passion.
CFO provides
metrics to
measure
effectiveness
and profitability
of the product.
Conclusions
• Each stake holder brings to the table
their share of feedback and inputs to
the product manager.
• It is important for the product
manager to understand the needs of
each stakeholder then assess these
inputs on case by case basis.
• Product manager has to focus on the
product life cycle stage and
accordingly prioritize things for the
development teams.
• Product managers can easily sway in
one direction giving undue attention
to one stakeholder.
8

9. Gated Process
IDEA/ CONCEPT GATE
Typically the first gate where the concept is
presented and the business/ domain
owners agree to the value proposed.
TECHNOLOGY GATE
Engineering and technology teams work to
check (POC/ otherwise) whether the
presented concept is viable/ can be done.
AVAILABILITY GATE
This is is where the developed feature is
made available to test teams with impact.
LAUNCH GATE
Launch readiness checklist is
executed, communications are
ready or already sent.
GATES
Technology Gates
Go-no go decisions have to involve
technology teams from a long term
maintainability, performance and
compatibility perspectives
Not applicable to
An early stage product company or a
company working on a brand new
product which is in early stages of
development may not have all of these
gates.
Gated Process
Product development is a gated process
with each gate added to ensure that the
right things pass through. These may be
called by different names at different
places.
Deliverables
Each gate should have a well defined
deliverable like the business value
delivered in numbers, perceived gains
may not translate into actual gains.
EOL GATE
End of life gate
9

10. The product lifecycle
The product development life cycle and its correlation with the stake holders
2
10

11. Product Life Cycle
CONCEPT DEVELOPMENT IMPLEMENTATION TERMINATION
LEVEL OF EFFORT
PLANNING STAGE PRODUCTION STAGE
PHASE 1 PHASE 2 PHASE 3 PHASE 4
Standard life cycle
This is the standard textbook
life cycle which most
products follow.
Boundaries
It is important to prioritize
feedback especially at phase
boundaries
Gated process
Normally there are multiple
checkpoints at end of each
phase to ensure team is on
track.
ADOPTION
Feedback
Feedback from stakeholders
can come at any stage;
prospects can give early
feedback.
11

12. Product Life Cycle – Stakeholders
LEVEL OF EFFORT
PHASE 1 PHASE 2 PHASE 3 PHASE 4
CFO Office
Important to make sure there are no
budgetary overruns. Roduct teams get
passionate and forget the resources they
are consuming as delivery of the product
takes center stage.
ADOPTION
Competitors
Competitors can have negative/ positive
impact on roadmaps, getting swayed by
competitors in early stages will only de-stabilize
the roadmap and we will play catch
up.
Senior Leadership
Leadership teams play a role during all
phases. They ensure product roadmaps are
in line with the company vision. They can
also derail the process by throwing weight.
Customers/ Prospects
Customers are always interested in “their”
business. Customers always tend to pull
roadmaps towards themselves. Post release
customers can add a lot of value to
roadmap if involved properly.
Marketing
Marketing teams can help in research of
geographies/ specific customers. They can
setup analyst calls etc. The key is to have
them on board as they act as an interface to
multiple external influencers.
Engineering/ Technology
Is a key contributor across stages. Acts as
the delivery vehicle for all roadmap &
startegy items
12

13. Remember
Enterprise
Enterprise products are not same as
public/ consumer products the nature of
customers and usage patterns are
different. B2C and social user patterns can
find their way into enterprise but not as a
copy.
One of the most critical but subtle factors
which we forget is that enterprise users
are using the product to get their work
done and mostly people do not like to
work . Contrarily shopping on e-commerce
stores or browsing Facebook is
mostly not termed as work!
13

14. Some lessons learnt – what worked
Things that worked well for teams in different stages of product development
3
Myths – what did not work
Things that did not work or had negative impacts on products
4
14

15. Know the product
A new senior member once suggested
that a product built over JNLP used by
doctors to study radiology images should
be rather built as a web/ browser
application.
The person never bothered to see the size
of data being transferred, the kind of
rendering precision and the operations
the doctor performs on the rendered
image.
I understand thee not.
The first and foremost that
each product manager
must ensure is that he/ she
understands what the
product does. Each product
is different and comparison
of features can be done
only after having a good
command over the
features.
15

16. Know the customers
While working on a geo-risk
measurement product it was assumed
that customers from the BFSI industry will
be willing to key in the details of assets
like flats/ houses and see a geo-risk score.
This would become cumbersome and
operational costs will increase as a single
application may have multiple such
assets. Integrating the geo-risk score with
other scores as part of workflow was so
much more easier for the customer.
Customers
Who are the customers, in
enterprise world they are
the ones who pay license,
support and change money.
Product managers should
know them like the back of
their hands.
16

17. Know the market
The USA mandates the preserving of
medical records for number of years
which has allowed many software
companies to provide solutions on
archiving, storage and retrieval of these
records.
In India on the contrary no such law exists
and selling a data archival solution to a
hospital which is trying to break even
after large CAPEX; did not work. As this
cost cannot be transferred to the end
customer by the hospital.
Did you say China?
The market brings laws,
economic environment,
lingo and host of other
challenges for the product
manager. Knowledge of the
trends & business
challenges in the market is
essential.
17

18. Bigger picture
While working to re-vitalize a desktop
based web mapping product we
mistakenly assumed Google maps to be a
competitor, whereas we were not even in
the space of consumer mapping. With
focus on the web needs of the customers
of this product we could launch a web
front in much less time than earlier
planned.
Being able to build the right feature at the
right time and translate that into returns
is a niche skill.
Assemble the jigsaw
Being at the center of all
communications that
happen with key
stakeholders of the product
one of the most important
ability is the ability to piece
things together, prioritize
them so that expectations
are met.
18

19. Priorities
Working on a product team we soon
realized that each new sales demo
brought in some superficial features
which were put in to win deals as part of
an exercise to showcase the product to
prospects. If even 50% of such deals
materialize then imagine the impact on
the roadmap.
Customers at a large bank wanted
everything to be built as part of product
so that their customization costs are low
and they get features directly from
product teams rather than PS.
Me first!
Customers and sales team
are usually the heavy
weights who pull product
roadmaps.
Both have personal goals
one needs to get features
as part of upgrades and the
other needs to sell more
and more.
19

20. Technology
While talking about workflows a senior
product person was perplexed when the
customer’s IT team went into activities,
sub-flows and the new process definition
standards.
In another instance I saw a product
manager commit on ready to use services
without getting to know the security,
audit ability and concurrency aspects of
these services and overall impact on OLTP
transactions over the web.
Drives business?
The separation between
technical and functional
features is getting very thin;
I have seen product
managers averse to
learning technology
whereas it is a handy tool
on their belt.
20

21. Usability
While developing a product for the bank
which went into implementation we
somehow changed the look and feel of
the home page adopting flat design
pattern. This change was resisted by the
bank; they had valid reasons that the
bank cannot re-invest on training.
Also we overlooked the fact that a lot of
times enterprise products are branded
per customer and the new look did not go
well with customized branding.
Not just forms
Like technology usability is
a nice to have tool up the
product manager’s belt. In
my experience product
managers who understood
usage patterns of the
products add more value
when coupled with a
designer.
21

22. Defects
While working on a banking product
which was tested by a sizeable quality
team which included automated and
manual execution of test cases we
realized that the customer found issues
were more than 50 in first round of UAT.
Deeper scrutiny of the issue revealed that
the internal team test cases were
different from what customer was testing.
Hate them?
Defects are perception of a
user on how system should
behave versus how it is
really behaving. A defect
free system has to be
looked at in context of the
customer always.
22

23. Performance
While working on a banking product
senior product managers compared
performance and page load times with
social media applications. This is done
without understanding the infrastructure
which goes behind each data center that
likes of Facebook run.
At a bank when users complained of
slowness we analyzed and asked the bank
to add cores/ CPU; the system slowness
became acceptable. In the enterprise if
there is one thing which people hate is
adding to the cost.
Vroom
Product managers need to
understand performance
involves CAPEX, hence like
defects acceptable
performance may vary from
customer to customer.
Performance is also a
feature and should be
tracked like one.
23

24. Hype versus reality
Analytic, big data and cloud are terms
that probably even your milkman would
have heard.
I have seen very senior product managers
talk about analytic without actually
studying the quality of data. Statistic is as
good as the data if New York is entered as
a city in Abu Dhabi then on a map it will
show there.
Like wise adapting cloud without
addressing data residency & security
concerns is like a cupcake without icing.
Cloudy?
Product managers should
not get swayed by hype
cycles, especially when
managing stable/ built
products. Jumping the gun
without due research can
be expensive for product
teams.
24

25. Agility
A very senior product manager talked of
how being Agile gives us the right to
change release backlog easily. I have seen
changes being pushed to development
teams in the middle of a sprint. Managed
change is good but unmanaged change
can lead to chaos.
Product managers should be able to
define what we need in a release, sprint
and then time-box these so that
engineering can measure and predict
team velocity this is tough and requires
discipline.
Ready for change
Agile & lean are perhaps
the most misunderstood
terms today. Understanding
agile & lean is in true
essence is essential. Sprint
cycles are closed and time-boxed,
velocity is just a
number not knowing this
only creates confusion.
Story
Agile
Develop
Test
Deploy
25

26. Last but not the least
REMEMBER
Products are like babies who need customers to
learn and grow mature and they need
engineering and product management teams to
nurture and guide them. To feed them with new
features; just like babies are fed baby food
initially. Products are fed on core features which
may be simple but are essential the need to
prioritize on features which are added to the
product roadmaps is critical and very important.
26

27. THANK YOU