I took this workshop, and jotted down some notes from Marty. All in all, I’d definitely recommend this workshop; it was a great overview, and helped me start seeing the difference between product management in Silicon Valley vs. elsewhere.

SAFe is designed for IT. IT projects we give to the Accentures of the world.

Recommended books:

  • The Hard Thing About Hard Things by Ben Horowitz
  • User Story Mapping by Jeff Patton
  • Lean Analytics by Alistair Croll and Benjamin Yoskovitz
  • Lean Customer Development by Cindy Alvarez
  • The Art of Scalability by Martin Lee Abbott and Michael T. Fisher

There’s a difference between “Proctor & Gamble Product Management” and Technology Product Management. PM is the #1 path to startup co-founder role.

*There’s a striking difference between how the best companies do product versus the large majority*

Root Causes of Failure in Product Development:

  1. Source of ideas
    • Shouldn’t be from customers and stakeholders
    • Should be engineers
  2. Business Case Fallacy
    • We don’t know revenue
    • We don’t know cost
  3. Product Roadmaps
    • 50% of features won’t have an impact on customers
    • 50% of features will need lots of iterations to deliver customer value
    • Time to market < < < Time to money
  4. Role of Product Manager
    • Mostly just thought of as a BA
  5. Role of Design
    • Not enough UX design
    • “Lipstick on a Pig”
  6. Role of Engineering
    • If you’re using engineers to code, you’re only getting 50% of the value
  7. Role of Agile
    • You’re hardly doing agile if you’re just doing it in delivery
  8. Focus on Output not Outcome
    • It’s really easy to ship features
    • It’s really hard to deliver outcomes
  9. Customer validation occurs way to late in the process
  10. Opportunity cost of not developing good stuff

3 Themes of Successful Product Companies:

  1. Address risks up front
  2. Define and design collaboratively
  3. Focus on results, not output

Different mentalities between design/discovery:

  • Fake it, then make it –> Google
  • Move fast, don’t break things –> Facebook
  • Learn Fast
    • 30-50 iterations in your prototypes
    • Think Jazz, not Classical Music
    • Prioritize learning
    • Growth/experimenting mindset
    • Let’s talk about Google’s search team
      • 2000 product ideas
      • < 500 delivered
      • 25% success rate is about right
  • Release with confidence
    • Features more often hurt then help
    • Instrument to know this
    • Sprint review should not be first time stakeholders see product
    • PM/UX spend 1 hour in delivery, 7 hours in discovery/day
    • Engineering spends .5 horus in discovery/day

Discovery and delivery aren’t phases.

  • Mostly use prototypes
  • 10-30 iterations/week
  • Apple probably has the most prototypes of the big tech companies

Engineers must want to do discovery.

  • They need to be missionairies, not mercenaries.
  • It’s critical that PMs bring engineering skills along in discovery
  • Typically, 1 PM can work with 10 engineers
  • Invent great thing on your customer’s [and stakeholder’s] behalf – Jeff Bezos
  • Discovery sprints good way to do this
  • Leads/Architects should participate in discovery

Discovery should be 1-2 weeks ahead; no longer than 1 month.

  • If you’re not 1-2 weeks ahead, you’ll end up “starving the machine”
  • If you’re greater than 1 month, you’ll get “backlog rot”

Follow the industry analysts

  • “Consumerization of the enterprise”
  • Good resource is Ben Thompson –> Stratechery

Netflix innovated getting people to watch other movies (non-new releases)

2 user researchers can work with 5 engineering teams 1 designer can support 2 teams Shoot for 3 horus of research/week PMO stinks!

Product managers should handle impediment removal

Don’t share your roadmap externally! Roadmaps should have quarters and themes, not features It’s more important to have a product strategy, not product roadmap

Apply loves personas; prioritize them OKRs:

  • Biggest mistake with OKRs is that team goals don’t align to company goals
  • These are at the team, not individual, level
  • Empowered teams need them
  • What matters is solving problems
  • Results are up to the teams
  • These shouldn’t tie to performance reviews
  • Coordinated objectives are the key to scaling

Myspace measures page views, which led them to inserting pages into flows, making it harder for users to complete tasks

Etsy has a good blog

Modern PMs know what we can’t know Developers don’t build what we tell them. They have to believe Don’t use requirements

Customers don’t do features:

  • Don’t know hwat’s possible
  • Don’t know what they want

Can’t assess value without talking to real users If the first time engineers see the idea is sprint planning, then you messed up

Opportunite assessment is for discovery and has 4 questions

Discovery work should have very light-weight process

Story mapping can be used in ideation

Nothing more powerful for B2B than live, referencible customers

Aim for 6 of these

Should be in parallel

Don’t sell until you have this

Product manager commits to delivering outcome, but might not be able to commit to features

Need site visitts

Should be in target market

Really understand user need

Email Marty about finding customers

In customer interviews, ask what is required to switch

Job is not to match features


Google –> Most ideas come from in-house

Don’t prioritize ideas; focus n objects and try

Engineering prototype- feasibility - can’t control

Live data - control doing

Low-fidelity for early iterations

Real companies do A/B testing


  1. Usability
  2. Value
  3. Feasibility
  4. Stakeholders

Get access to buyers through customer development program A/B testing is not optimizely, because that is server-side, not client B2B does invite-only (opt-in) test

PMs need to know how to show their product:

  1. User test (usability/viability)
  2. Sales demo
  3. Walkthrough

How to transform your organization:

  1. Discovery sprint
    • “learn how this all works”
    • Big product decisions
    • Hard reset
    • Do this only 1 week/quarter
  2. Pilot teams
  3. Outcome-oriented roadmaps. Use “the language of the boardroom”

Everything but prototypes lie “Prototypes as spec” Process serves you, you don’t serve the process

Keys to success:

  1. Tackle risks early
  2. True collaboration
  3. Focus on business results

Need 4 hours/day. Really takes personal time management