[2023 kcdc] what your product manager actually does & why it matters

Speaker: Annie Cochran

For more, see the table of contents.


Like the speaker, I”m using PM in this post to mean product manager

Overview

  • Amount of power varies amongst PMs
  • Product Manager vs Product Owner vs Project Manager – these are different roles. Some companies use these terms interchangeably or merge the roles
  • PMs role is to protect developer’s time, unblock things, have conversations/meetings, etc

Day in the life

  • Lots of meetings and prep for a lot of meetings.
  • Common to be double/triple booked
  • 10 meetings/day
  • Juggling between meetings/inbox/to do list
  • Review notes/action items/next day’s schedule

Potential opportunity meeting

  • Frst hear about opportunities to strengthen product.
  • Talk to devs only if agree good opportunity.
  • Say no diplomatically if not.
  • Sometimes not bad but not enough time now.
  • “No and…” – need manager to stand by decisions when need reinforcement
  • Represent team/product at meetings
  • Protect goals of product and team

Brag about the team meeting

  • Celebrate publicly to senior leadership and executives what devs did.

Discovery

  • Series of meetings and activities
  • Trying to discover user needs/goals/pain points
  • Tries to choose best method for the problem at hand
  • Vet work and decide if take back to team
  • Another meeting where protect devs time
  • Use Mural

Other types of meetings

  • One on one – ex: engineering manager
  • Surprise meetings
  • PO meeting
  • Team ceremonies – ex: standup refinement/grooming

Refinement

  • PM fills in where can.
  • Then team fills in. Pre-refinement. Does twice a week for a specific set of stories. A developer must be present because talking about technical details. Investment of time.
  • Actual refinement is after tech lead involved

Shouldn’t do

  • Don’t make technical choices
  • Don’t need to know all tech solutions
  • Not CEO of the product. Don’t want to make decisions in a top down way. Make choices with the team vs hierarchically.
  • Don’t need to control every moment of pre-refinement
  • Tech adjacent, but not technical
  • Not a data analyst. Interpreting data, not collecting it.
  • Not a project manager. Project manager focused on timeline/deadlines (when). Product manager focused on whether should do it at all (why)

How can devs help the PM

  • Participate in meetings.
  • Pay full attention in meetings; don’t do side work
  • Listen so know when can contribute.
  • Give input when asked. Gives confidence for others to share.
  • Prepare in advance when asked
  • Communicate problems as soon as blocked. Give info so can deal fight dragons.
  • Constructive criticism when needed

Product Owner and Product Manager

  • Common for it to be the same person
  • Similar role
  • Internet says PM is more strategic and PO is more tactical
  • Someone in audience said PO supposed to have more authority. Others disagree.
  • Another person said transferred PO to PM
  • Another person said PO helps prioritize backlog as exists, clean it out. BAs groom stories. PMs oversee activities but focus on why.
  • Another person said PMs looking at longer term and POs focus on day to day (ex: standups/impediments)
  • There’s a PO Analyst course role between PO and PM
  • Conclusion – varies a lot by organization and even within an organization

Tech debt

  • Annie is a former dev (for 8 months)
  • Explain why important, robustness, maintainable
  • Make it less abstract
  • Technical education from team so can explain to business. ex: can’t deliver X until fix Y.
  • Don’t ask permission to do job right. Just right tests

My take

This was a fun start to the day. It was nice seeing the POV of a product manager. Annie is a former developer who has been in the role for 13 months. This is a good amount of time for the topic. I like that she crafted a message specifically for developers. I enjoyed both the talk part and question/discussion part. There was a lot of activity.

[2023 kcdc] data science: zero to hero

Speaker: Gary Short

Twitter; @garyshort

Repo for presentation/samples: https://github.com/garyshort/kcdc2023

For more, see the table of contents.


Data science overview/rules

  • Applied data science – solving business problems
  • Curiosity is most important
  • The universe does random stuff so you haven’t discovered anything until you prove you’ve discovered something
  • Only qualitative and quantitative data – people lie, Can’t trust what you ask
  • Can only do math with numbers. Some things will pretend to be numbers when they are not. Also, can’t add different things (dollars vs killograms)
  • If you can’t explain it to a six year old, you don’t really understand it
  • Only have to be more than 51% accurate to do better than guessing
  • True random data has some clusters. The cluster will not last forever. Gambler’s paradox. 27 blacks doesn’t mean due a red.
  • If it’s not in production, it doesn’t exist. Can’t just be on your laptop. Most data scientists need to give to someone else to get it to prod. Cultural difference between data scientist and person who is building/deploying.
  • % chance of hypothesis being right or wrong doesn’t have to sum up to 100%. ex: grass is wet. Could be rain or a dog peeing or something else

Types of data

Structured

  • Relational data
  • Get connection, create cursor, fill cursor, close connection
  • Schema is important on data write.

Semi structured

  • ex: JSON/MongoDB.
  • Get connection, name collection, fill cursor, close connection
  • Schema important when read data

Unstructured

  • Blob (binary large object)
  • Stored in pages/blocks
  • Access via URL

Graph

  • Degrees of separation – can you deliver a message directly
  • People in room now more closely connected because in this session (and would stay so if shared contact info)
  • Wide network effect
  • Nodes tend to be nouns
  • Edges tend to be verbs. Can be unidirectional or bidirectional
  • Get connection, state query, fill cursor, close connection

AI/ML works on data types

  • Categorical – segregate data by category where category is not important (ex: blue eyes)
  • Ordinal – order is important but distance between is not important (ex: position in a race)
  • Numeric – order is important but distance is the same (ex: counting)
  • Ratio – numeric but with positive numbers

Can only do math with ordinal and ratio types. A survey on a scale of 1-5 (likert scale) is ordinal, not numeric/ratio. Can’t do average. This is categorical data (ex: very happy, pissed off). Can do math with counts of categorical data but not single items.

Exploratory Data analysis

  • Need to understand the variables. Ex: is it really a number
  • Handle missing values – depends on scenario. Ex: use mean or median (if not looking for that particular thing), delete row with incomplete data
  • Outlier detection – sometimes genuinely an outlier (ex: someone who is 8 feet tall), sometimes it is the important piece of data (ex: which exits people use in a fire; one person went the other way and want to know why). Need to determine why outlier and if care so don’t delete data need
  • Univariate analysis – ex: histogram for categorical data
  • Bivariate analysis – correlated data; could be hidden variable. Don’t need both of them since one predicts the other. Want minimal variables in model so chose the one that brings in the most info.

Feature Selection

  • Preprocess the data
  • Normalize data – units have to be the same. Using variance doesn’t help because unit is now original unit squared. Can use Z-score so everything on scale 0-1 using mean and divisor
  • Encode the categories – make so can do math
  • Booleans are numbers (0 and 1)
  • Word vector – can use math to represent a word. Complicated. Ok to have to look up every time.
  • Bi/multivariate analysis – high correlation means redundant info
  • Feature importance – check coefficients from regressions and scores from gradient boosting

Model Selection

  • People have a favorite model
  • Use one or more models. See which gives best result before making any changes to the model.
  • Good to use a linear and non linear one. Normal the linear model is enough because normally dealing with people (directly or indirectly). Linear equations work for a normal distrobution.
  • Make sure to find global minimum, not local/current one
  • Compete with yourself. Try to have your second best model beat your current best model. Once something in prod, start again

Train/test split

  • 80/20 split
  • 80% data for training
  • 20% data real
  • Model never sees training data because can’t grade own homework

Model evaluation

  • Outcome – model + error
  • Error is difference between predicted and observed values.
  • Sample of population can be model. Get error because of sampling bias

Hyper Parameter Tuning

  • Every models have parameters to govern how works.
  • Hyper param tuning is fiddling with these
  • Will be an optional value for each of these parameters for your particular use case

Model Validation

  • Need to make sure model doesn’t work by chance
  • K-Fold Cross Validation – after do 80/20 split, can feed data back in and do again
  • Stratified Cross Validation – same as K-Fold but unbalanced classes

Bayesian inference in Real Life

  • P(h|e) = P(e|h) * P(h) / P(e)
  • In English: current belief = new evidence

Estimation

  • Important to be able to estimate values when have no data
  • Dumb questions like “how many piano tuners are there in Chicago” was testing this. So few people could do it that pulled question. [I suspect the ridicule and people memorizing the answer was a factor too]
  • Easier to estimate a range than an actual value
  • Pick a minimum that it couldn’t possibly be below. You’d be surprised and skeptical if less than that.
  • Pick a maximum that it couldn’t possible be above.
  • Pick value spits range in two so that the possibility of being above/below has equal probability. Call this the medium. Resist temptation to pick the mean.
  • Repeat finding the minimum to median. Call this Q1
  • Then repeat finding the median to maximum to get Q3.
  • This gets you a five point description of a distribution
  • Use sampling to get mean of distribution

Lab part

The lab was to predict something you want to predict and make a model and/or predict a probability. Can do individually or in groups. He also gave the option to leave. I chose leave because there was a little over an hour left when he finished explaining the lab. I need to go over the material for my own workshop so doing that instead of the lab.

My take

This was a good intro and Gary is a good, engaging speaker. I learned (and re-learned) a bunch of stuff. Both concepts and terms. Having a bunch of rules and getting into them made it fun. (ex: math needs numbers). I like that the concept part was longer (except for the lack of a break), but it would hav been better if it was advertised that way in the intro.

I disagree with Gary’s philosophy on not having a bathroom break. He started by saying there would be 60-90 minutes of lecture and then a lab. [wound up to being just over 2.5 hours] And that we are all adults and can go to the bathroom whenever. Someone asked at the 90 minute mark if there would be a bathroom break and he repeated the all adults thing expanding that you’ll catch up and the slides will be online later. He also said people feel compelled to hold it until break or go when told it is break. However, the tradeoff is that you don’t want to go to the bathroom lest you miss something that will wind up being important during the session. It’s super frustrating to miss stuff and then struggle to understand later. It may be that this workshop isn’t cumulative but there’s no way to know. Also, by not having a break, you aren’t giving people’s brain a break. It’s not just about the bathroom.

Gary stated he puts the materials online after so people don’t read it during the session. That I agree with!

2023 kcdc table of contents

This week I’m at KCDC. This page will contain links to my live blogs and sessions.

Wednesday

Thursday

Friday