Welcome to episode 197 of the Nerd Journey Podcast [@NerdJourney]! We’re John White (@vJourneyman) and Nick Korte (@NetworkNerd_), two Pre-Sales Technical Engineers who are hoping to bring you the IT career advice that we wish we’d been given earlier in our careers. In today’s episode we share part 3 of a discussion with David Babbitt, discussing agile ceremonies and processes like scrum, how others might get into product management, qualities of a good product manager, and thoughts on the principal title.

Original Recording Date: 10-11-2022

David Babbitt is currently a Principal Technical Product Manager at Amazon in part of the "last mile organization" – the Transporter Experience and Technology Group. If you missed our previous conversations with David, check out Episode 195 and Episode 196.

Topics – Agile Ceremonies, Many Aspects of Getting into Product Management, Thoughts on the Principal Title

4:06 – Agile Ceremonies

• For reading material on what agile is, check out this post.
• David has done agile using scrum (which is a process) and says agile is more of an intent.
• There is usually a daily standup. David doesn’t call this scrum and says it is just a daily standup ceremony (what was done yesterday, what is intended for today, what blockers are to progress, etc.).
• There is also a refinement ceremony where you discuss requirements and ensure everyone is on the same page.
• Typically there is also a sprint loading process where you are taking the user stories, refining them, putting them into the next sprint, and making sure they can be completed within that sprint.
• There is also a retrospective to look back at the last sprint and review things that went well, things needing improvement, and any action items.
• David is not a licensed scrum product owner or scrum po but has learned a great deal from some of his friends who are licensed.
  • Nick wants to know if being licensed gets you accessed to the proper ceremonial attire.
• It was pretty funny to David that some of the concepts were so foreign to Nick and John. But these things have been a part of David’s daily life for 5 or more years now. David mentioned in reference to the above, "this is what we do."
  • John was aware of the terms, especially after seeing so many folks at Google in purple robes.
  • It was important to define some of the terms for listeners. People may need to go and look up / research some of the terms we discussed. John, for example, once heard someone state they were a scrum master. If you’re not in the development process, you don’t know what that looks like and the formalization of the process (i.e. what turning the crank looks like).
• David points out two big fundamental things he has experienced as in his career building software.
  • One is the waterfall process
    • This usually involves a giant requirements document that engineers look at, think about how they will solve the problem, assign sizes to everything in the document, they might say it’s a 6-month project or a 12-month project, and go off to start building things once it gets approved. It maps to waterfall in the sense that it involves giant efforts.
  • There are agile type processes like scrum.
    • The idea of scrum is that you are not committed to a single program but are able to respond as needed to feedback from the market, the users, or early testers.
    • You don’t go research and design something for 12 or 18 months when in 6 months you might choose to do something else.
    • You develop a more iterative process where you are learning along the way and building (out in front of you) the next set of stories that will be invested into the product.
  • John suggests this process solves the problem of answering the question of what is needed 18 months from now or 3 months from now for the next version of a software package.
  • David says as a product manager you are kind of responsible for knowing where a product should be 2 years from now. But, he doesn’t want to write a specification an engineer can build from if they are not going to build it for a year and a half. Within that time much will be learned and allow the team to better write the requirement or realize it isn’t so important.
  • Generally, we (product managers) know where we should be a year from now, 2 years from now, and where the market is going. But we’re not writing down to the user story level or the requirement level on where we should be 2 years from now. If we are, to a degree that may be too rigid.
  • David has seen too many examples of gigantic requirement documents with detailed specifications, and then a year later the projects were never completed to the way they were originally written.
    • This makes for a lot of waste that went into writing the requirements, researching the requirements, and researching the solution to the requirements that never got implemented.
    • This is (to David’s knowledge) where the principles behind agile and scrum as a process likely came from. He’s stumbled into a lot of it over time.

10:07 – Many Aspects of Getting into Product Management

• John highlights user stories and acceptance criteria as helpful in the role of a sales engineer. In sales engineering, we’re trying to help solve a problem with our product, and engineering efforts are more around how we put products in the portfolio to solve a customer’s problem.
  • John says he feels we do not have a matching process of customer stories, but we should. He’s not sure how to solve that other than perhaps studying how to write customer stories.
• This is an interesting turn to the conversation on how to get into product management. David was given the opportunity to take the role, but what did he do after that?
  • Getting the role doesn’t mean David knew how to do it. He bought and read lots of books.
  • He also read lots of blogs about how other product managers were solving problems.
  • David also attended conferences. His favorite sessions were hearing about failures – what people tried, what didn’t work, and what people learned from this.
  • David went to meetup groups but didn’t feel like he got as much out of them as from conferences.
  • He also recalls attending some online seminars.
  • In terms of books, David liked
    • The Product Manager’s Handbook
    • User Story Mapping
    • The Lean Startup by Eric Ries
      • David started by reading a lot of blogs written by Eric Ries (see this blog site) before the book came to be.
    • There are a couple of other books David likes on ways to write effective stories
• What about tips for someone to get into product management / progressing toward it?
  • Many people are exposed to a product manager on a regular basis.
  • If you’re going to a meeting (or a ceremony if you will), take note of the types of questions product managers are asking. Think about why they ask those questions and what product managers are trying to get out of it.
  • David has also seen formal mentorship happen. At previous employers like Ping employees from another part of the business would be mentored by product managers and eventually became product managers themselves. These employees would sometimes shadow product managers, asking why questions were asked, what was learned, and what the product manager was looking to gain by asking a specific question.
    • Less formal and more general mentorship is something David would see on a pretty regular basis.
  • David hasn’t been in a situation where he’s seen one of the above be used as relatable experience in an interview, but he knows people have made the transition from formal mentorship into product management. Maybe you can share what you have learned in one of these mentoring programs, for example, in an interview.
  • Interview questions for product managers are really more along the lines of how would you solve this problem or what have you done before.
    • You can be honest and share what you have seen, what you thought of it, and what you learned from it as part of the answer to "what have you done before?" Another idea is to comment on how you might have done something differently than you saw it be done by others.
• There are many other aspects to being a product manager.
  • A product manager must be able to empathize with end users of the product. Is this something that can actually be learned?
  • You have to be able to make decisions with imperfect data. David feels this one can be practiced and learned.
    • In the absence of some of the data, what would you go and research, and what choice would you make? How would you know if you’re right or wrong?
    • You can’t go and research everything, so you have to be better about prioritizing and answering these questions surrounding imperfect data.
    • Another way to say this is dealing with uncertainty.
  • You have to defend priorities quite frequently and reasons for doing things in a specific order. You have to be able to defend things when faced with scrutiny (i.e. why you are "sticking to your guns").
  • At the same time, there is a saying for product managers – strong opinions loosely held. You have to have a position / opinion, but you also need the self-awareness to seek out data and opinions that help you realize you may be on the wrong path. It would be unwise to bury your head in the sand and stand on a decision made a year ago if it was the wrong one (i.e. continue making the wrong decision).
  • David feels there is a certain amount of emotional intelligence required in this role (product management). He remembers at Spiceworks that there were so many features desired by so many users any time he choose to focus on one feature or ten features he was upsetting 99% of the audience that did not want those features.
    • In this way, a product manager is always doing things that are not what the customer you are potentially speaking with next week asked for.
    • You are probably going to deal with customers who are unhappy about what you’re doing and question the direction of the product. You will likely have customers upset with you about why a feature doesn’t work the way they want it to / think it should.
    • The ability to not respond rashly to this type of feedback is important. Separate the personal aspect from it, and do your best to move on. The criticism is more about a decision made than you personally.
    • David has seen many product managers struggle with this kind of criticism and react emotionally. These folks may not react to criticism well in general. David believes this needs to be practiced but doesn’t quite know how to develop it.
    • As passionate about the work as he is, David has become very stoic about work being work and certain things being part of the job.
    • John wonders if there are therapists who as part of their practice work with people in criticism-heavy roles who have helped these people learn to take the criticism to be more about a decision and less about the people.
      • There are sports psychologists who do this kind of work and probably life coaches / career coaches.
    • David says you can ask yourself how you will feel about something in 5 minutes, 5 hours, and 5 days to get a feel for how important something is and how emotionally charged one should be about it.
      • This is a mechanical way we can deal with some of these challenges (i.e. receiving an e-mail from someone who was upset, being told something by an upset customer, etc.). Making the above thought process a habit in these scenarios is a way to train your emotional intelligence (EQ).
      • Nick points out it seems like David read Decisive by Chip and Dan Heath and that this suggestion sounds in line with some of the advice from the book (i.e. setting a tripwire).

20:04 – Thoughts on the Principal Title

• David couldn’t necessarily say what it took to obtain the principal title. He’s not someone who has been very calculated about his career or ladder climbing.

• David always tried to do things that were in part fun for him and in part something fun and creative and good for customers.

• He’s always been ambitious about recognizing opportunities to solve more problems. As a result David has been rewarded over his career with different opportunities for new titles and growth.

• David was a director twice and each time came back to the individual contributor track. While he did like management of engineering early on, he much more enjoys the creativity of product management and didn’t want to focus his career on the management path.

• David understands the need for an individual contributor path across many disciplines, and from his experience at different companies the principal title is one that is reserved for the highest level individual contributors.

• At David’s previous company the highest level individual contributors across engineers and product managers were principal level. Beyond that most had some sort of manager or director title.

• John points out David was not pursuing a title but increased responsibilities for solving problems. This suggests the principal title is awarded for gaining additional responsibility that may not fall to other individual contributors but without requiring someone become a manager.

  • David says he was not necessarily seeking out additional responsibilities.
  • "I just think about the person using the product and where this product needs to solve more problems over time." – David Babbitt
  • David just recognized there were more opportunities for the products to do better over time for the user base. Pointing out opportunities for a product (i.e. here’s where this product could do more) were not a self-serving opportunity for David. He feels the reward for some of the out of box ambitious thinking were new titles and opportunities to experience the management path.
  • When interviewing for his next role while at Ping, David made it clear he was looking for principal and that his goal was not to become any sort of manager or director.
  • "I’m happy to be a principal. I know who I am. I know what I like. This is what I want to do." – David Babbitt
  • David thinks a couple of companies were concerned that though David had director level roles on his resume, coming in at principal would prompt him to immediately pursue the same director level again internally. He made it very clear that is not what he wanted.
  • Nick cites this as greater impact to the product and greater impact to the customer base. David calls it connected to the customer base.
  • "I think in general product management is about thought leadership." – David Babbitt

• David fully expects us to have more product managers out there as guests and report back to him.

  • If you’re a product manager out there, we want to hear from you!

• Mentioned in the outro

  • Maybe one way to better communicate with product teams and perhaps edge into product management is to write a draft of a user story for a customer and have product management give feedback on how clearly it came across to them. This seems similar to the advice from Brad Pinkston in Episode 84 when determining how to communicate with a new boss (i.e. adapt to their communication style).
    • See also Episode 83 for the first part of that interview with Brad.
  • John mentions Crucial Conversations as a good read for people who might need to de-escalate a situation or de-personalize it.
    • Maybe we can try a de-personalized reflection of what people say to de-escalate conversations.
    • If you or someone you know might have expertise or good tips for these kinds of situations, please let us know!
  • Is David’s mode of progression a bit of an outlier compared to other guests? Perhaps it had to do with varying experience at startups, the opportunities to wear multiple hats, etc.

Contact us if you need help on the journey, and be sure to check out the Nerd Journey Podcast Knowledge Graph.