I made this note and presentation for the executives in my company. We discuss how the product organization should be evolving and how we can create a strong innovative company.
Inspired is one of the best books to introduce you to product management. And it's also a strong one that can be easily read and understood by the business and non-product people in the company.
Uneak White's Personal Brand Exploration Presentation
Notes on Inspired: How to Create Products Customers Love by Marty Cagan
1. This is some notes from Cagan’s Inspired book. I presented it for the
executives in my company to help them understand what Product really is and
how to collaborate with us.
It wasn’t designed well, but I added notes to where the discussion supposed
to be deeper. Email me at ivan.nashara@efishery.com for feedbacks.
How to be Inspired
2. First, let’s remember why the modern product
management is needed
It’s the story taken from Scrum: The Art of
Doing Twice the Work in Half the Time
3. The FBI Project Case
Initial Software (VCF):
$600 million -- Scraped
Gen 2 Software (Sentinel):
$405 million -- half the project,
need another $350 million
4. With Scrum:
20% manpower
$20 million
18 months
read here: https://resources.collab.net/blogs/case-study-of-a-difficult-federal-government-scrum-
project-fbi-sentinel
7. Holistic Product
What is product?
Functionality, the features
Also the tech, that enables the functionality
Includes user experience design that presents
the functionality
Includes how to attract and acquire users
Also any offline experience that essential to
deliver product’s value
8. Holistic Product
My personal note:
Every process in the company can be counted
as product process. It’s what differentiate a
product company and a conventional one
The 101 is: when you see a process as part of
the product, you implement the product
mindset on that process, you iterate it, you
continuously improve it
12. Discovery and
Delivery
My personal note:
Inspired strongly suggest to tackle all the risks upfront.
Do extensive research, rigorous prototyping, so you have
the idea of a car just before you decide to build a car. It
what helps the business lean and make the team much
more efficient
13. Discovery - 4 Big
Risks
1. Will the user buy this (or choose to use it)?
VALUE
1. Can the user figure out how to use this?
USABILITY
1. Can our engineers build this? FEASIBILITY
1. Can our stakeholders support this?
VIABILITY
14. The aspect of collaboration between business
and product team is fundamental
Besides day to day communication, they
communicate through Product Vision
It’s how the alignment being implemented
since the beginning
16. Product Vision
COMPANY MISSION/BHAG/WHATEVER
(2-5 years)
e.g. #1 protein provider in the world
PRODUCT VISION
(2-5 years)
e.g highly functioning AI-marketplace to solve
asymmetric information
PRODUCT STRATEGY
(>2 year)
e.g. start with device, then data, then marketplace;
or start with social, then ads, then premium
OUTCOME-BASED ROADMAP
(<1 year)
e.g. build A, increase sales, reduce churn
17. Product Vision
My personal note:
Vision cascading can be different in each case. In my
company we use OKR as our annual business objective
and alignment.
OKR is outcome-based (e.g. drive sales x%, increase
value x%), it’s suitable to what Inspired really suggest
that a target shouldn’t be in a form of an output (e.g.
build A, launch B)
But, syncing the product roadmap (user’s need) and
business objective (OKRs) can be hard. The business
leaders need to sync with the vision before deciding the
OKRs. Hence, product vision isn’t owned by the product
team only, it should owned by the company
18. There’s a lot of technique taught by Inspired.
But I skipped that part and moved to the
Principle, Process and Culture part.
It’s basically what mostly needed to be synced
with the business part of the company to get
them to understand what product mindset is.
21. Principles
My personal note:
I read a book regarding Japanese history and remember
a fact that at least in 15th century, Christianity has
entered Japan. Church missionaries were and has been
the most mission-oriented team in the history. They are
driven by their belief and purpose and they take the
mission seriously
The team of missionaries are inspired. They are
empowered with big mission and delegated to do
anything necessary to deliver that mission.
While mercenaries are only acting based on how much
they get paid. It’s not sustainable and too costly. They’re
budget constrained, rules constrained, and will be
satisfied when certain job done although the bigger
purpose might not be served.
22. Principles
● Empower the team make them
accountable
● PM is not the boss of anyone
● The nature of the team is true
collaboration
● All type of work should exist in the team,
but the team will be limited scope
● Autonomy to solve problem the best way
they see fit
● Minimize dependency
23. Principles
First, collaboration is built on relationship. In a
team, this relationship is nurtured
Second, to innovate you need expertise, durable
nature lets people go deep enough (minimize switching
context)
Third, instead of just building what others determine might
be valuable, in this model the full team understands
the business objective and context hence the
ownership and responsibility for the outcome
The team is not off the hook just because
something launches. They don’t rest until and
unless it’s working for the users and for the
business
25. The Process
My personal note:
It’s the basic product funnel that I implement on the company. I put
the Shaping Cycle to add more feasibility assessment.
For Discovery, it’s mostly the design thinking part. And what I mean by
idea prototype, it’s not even low-fid. We can just really simulate it,
prototyping the experience
27. Good Team/Bad
Team
Have compelling product vision, pursued with
missionary-like passion
Bad teams are mercenaries
Get their inspiration from vision, observing customers,
analyzing data, and new tech.
Bad teams gather requirements from sales and
customers
Understand who the stakeholders along with their pain
and constraint, then commit to invent solution that for
for user, customer, and business
Bad teams gather requirement from stakeholders
Skilled in many techniques to try out product ideas
Bad teams hold meetings to generate prioritized
roadmaps
28. Good Team/Bad
Team
Skilled in many techniques to try out product ideas
Bad teams hold meetings to generate prioritized
roadmaps
Love to brainstorm with thought leaders across the
company
Bad teams get offended when someone outside dares
to suggest anything
Have product, design, and engineer sit side by side
Bad teams sit on their silos and demand documents for
requests
Constantly trying out new ideas to innovate while
protect the revenue and brand
Bad teams waiting for permission to run a test
29. Good Team/Bad
Team
Insist to have complete skill sets on the team
Bad teams don’t even know what product designers are
Ensure engineers have time to prototype in discovery
every day so can contribute their thought on the
product
Bad teams show prototype to engineers during sprint
planning for estimates
Engage directly with users every week and see their
response to new ideas
Bad teams think they are the customer
Know not every ideas will work, even a good one will
need more iterations
Bad teams only build what’s on roadmap and satisfied
only on meeting dates and quality
30. Good Team/Bad
Team
Understand the need for rapid iteration and it comes
from right techniques, not forced labor
Bad teams complain they are slow because their
colleagues are not working hard enough
Make high integrity commitment after evaluating
requests and ensured have a viable solution
Bad teams complain about being a sales-driven
company
Instrument their work so they understand how their
product being used and adjust based on data
Bad teams consider analytic only nice to have
31. Good Team/Bad
Team
Obsess over their reference customers
Bad teams obsess over their competitors
Celebrate when achieve significant impact to the
business results
Bad teams celebrate whey they release something
Integrate and release continuously with stream of
smaller release
Bad teams test manually at the end of painful
integration and release everything at once
32. Reasons for Loss of
Innovation
● Missing customer-centric culture
● No one inherit the product vision
● Lost focus on target market
● Weak product managers
● Everchanging product team members
● Diluting engineers from customer problems
● Extremely risk averse
● Disempowered product team
● IT-mindset
● Lack for room to innovate
33. Reasons for Loss of
Velocity
● Technical Debt, weak architecture
● Lack of strong product managers, not evangelising
● Lack of delivery management
● Infrequent release cycles
● Lack of vision and strategy
● Lack of co-located, durable product team
● Not inspecting rabbit hole, engineers not involved
● Not utilizing designers in discovery
● Changing priorities
● Over-consensus culture
34. Innovation vs
Execution?
● The first dimension is consistently innovate to
come up with viable solution
● The second dimension is execution, shipped the
ideas
Culture of Innovation
● Experimentation
● Open minds
● Empowerment
● Technology
● Business and customer-savvy
team
● Celebrating skill-set diversity
● Discovery technique
Culture of Execution
● Urgency
● High-integrity commitment
● Empowerment
● Accountability
● Collaboration
● Result not output
● Recognition
35. The Summary:
1. Start by empowering the product team. Give them the power to be accountable and mission-
driven
1. Build a healthy product team with core spirit of collaboration that appreciating perspectives
and skill-sets from Engineers, Designers, and stakeholders
1. Product and Business shouldn’t go toe to toe. It should coexist in harmony. Strong product
team helps business thrive while understand what user needs
1. Innovation and Execution. Discovery and Delivery. It’s a two thing that work hand in hand.
Their values might be in odds, but a strong company put focus on the two nonetheless
1. Put tons of effort in Discovery, a lot of people forget this. Do a lot of prototyping, invite
designers and engineers in the prototyping phase too so the solution that the team come up
with will tackle all the 4 big risks
1. The first release may not validate the idea, so go on with more iteration and see if the idea
will really works
1. A strong product team understand business and context and focus on result/outcome. It’s
their main driver. The vision, the mission, the result. Not the output and the release because
it’s just the means to an end
Hinweis der Redaktion
IT: product to serve business ened. Mestinya serve company customers in ways that meet the need of the business
IT: product to serve business ened. Mestinya serve company customers in ways that meet the need of the business
IT: product to serve business ened. Mestinya serve company customers in ways that meet the need of the business