Welcome to episode 196 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 2 of an interview with David Babbitt, discussing David’s time in the player coach seat, his move to executive director and back to an individual contributor role, his experience as a product manager across companies, and important terminology for product management.

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 part 1 of our interview with David, check out Episode 195.

Topics – Player and Coach, What Product Managers Do, Influence without Direct Power, Product Managers and Customers, Reasons for Shifting away from Executive Director, User Stories and Acceptance Criteria

3:48 – Player and Coach

• David’s impact as a player and coach in his role as manager changed over time in terms of team size.
  • Early on it was probably 10 people, and later as they started to separate teams by different products it was a smaller group of 5-8 people.
    • For reference, David took on a product and then developed a new one.
  • John mentions any more than the 5-8 means a player coach would need to become a full time coach.
  • David says this likely goes back to startups and how mature they are in different roles. In this case he was at a startup that had not really made lead engineers managers previously.
  • David doesn’t feel like he put quite as much into the role of being a manager as perhaps he should have (i.e. focusing on 1-1s, giving feedback, and developing engineers). Much of his focus was the product and getting it out on time. There was some level of mentorship as a technical lead which he provided, but David would not say as a manager he was doing the best job.
  • People have told David he was a decent manager, but he feels like he could have done a lot better. We can all look at a situation and feel that if we did it again we would be so much better at it.
• At Spiceworks was a player / coach development manager (as were some of his peers). There were no product managers at this time. The thinking was they wanted everyone to be close to the problem and close to the users of the Spiceworks software.
• As they grew it became clear they needed more people to focus on the execution (getting the product out the door) and others who needed to focus on the actual problem to solve in a situation.
  • David chose to take the product manager path, and near the end of his time at Spiceworks, his title was executive director.
  • He was promoted, was managing product managers, and he was managing development managers, designers, and analysts.
  • It was a bit like a general manager, but he did not really have a budget of his own.
  • In more relatable titles it may have been more like a director of product management. He was not responsible for profit and loss on an entire product, did not have marketing, etc. David could ask for headcount, but things were not as aligned underneath him.
    • He could not go and say to someone "this is the budget that I need."
• Was this part of developing / going after a new product at Spiceworks?
  • It was for multiple products in the end.
  • The Network Monitor product was the second one David managed. It was created from the back of a napkin after realizing there were a number of gaps in existing products. The inventory tool in the main Spiceworks product was sort of passing off as a network monitoring tool but wasn’t quite cutting it.
  • David got to create this product and choose his team to work on it. He was still a manager at that time.
  • After this point David and a colleague (Kevin) were made directors.
  • The team started to create an app store / marketplace concept in Spiceworks to create extensions in the inventory, help desk, and network monitoring products.
  • David was not directly over any one product any longer and its future. He had product managers and engineering managers that would report into him.

8:30 – What Product Managers Do

• There are a couple of ways to think about what a product manager does. David says there is a lot of confusion around product management because he does not believe there are a lot of hard and fast rules.
  • In the industry you typically see a product manager and a technical product manager. David is a product manager technical or what we would call a technical product manager. This also does not mean that any one company has both of these titles.
  • For both of these titles, the responsibility is the future of a specific product in a market and making sure the product is successful (or, the success of a product in the future of a market).
  • Product managers are more focused on the business side of things (partnerships, pricing, packaging, economic concerns in the future of the market, etc.).
  • Think of the technical product manager as being the product manager that is more closely aligned with engineering. They go to ceremonies and are sometimes called product owners depending on the company. They are working on the design, tough technology choices, the future of technology in the market, translating business problems to actionable stories for engineering teams.
  • Another way to look at this is as the product manager being CEO of their product.
    • David doesn’t like this as much because product managers do not manage people. They manage products and have to influence everybody else in what are the right directions for a specific product.
    • A CEO of a product ideally might have engineering or product marketing report into them, but this is not typically how David has seen it done.
  • David has a friend who refers to product managers as the ooze that fills gaps in organizations. In order to ensure the future of a product in a specific market you end up putting on a lot of hats and filling a lot of roles.
    • If your company / startup is not great at sales enablement or product marketing or public relations you will end up wearing these different hats somehow in helping out.
• Another way to think about product management is the day-to-day responsibilities.
  • You don’t lead people directly as mentioned previously but rather influence them. David, for example, is paired with an engineering team and has historically been paired up in this way with engineering teams.
    • Engineers may not report to you but know you’re their product manager. They are doing the stuff that enables what you as the product manager or PM want the product to do.
    • The engineers do not report to David, but they are essentially under his influence.
  • This is based at least in part on a strong relationship with the engineering manager and engineering team. David feels he has been lucky in that he has not felt any kind of antagonistic relationship between himself as the PM and his engineering teams (though he has definitely heard about this kind of thing happening).
  • Sometimes when David shares what the product team needs to do and where things are going, it could be met by initial confusion. Ultimately you win them over and they start to believe in you as you show more success.
  • David has heard of dysfunctional organizations in which the PM wants to do one thing and the engineering team wants to do something completely different but has never personally been in that situation.
    • Generally when David has shared what the team will work on over the next 6 months, for example, it has been well received.

13:00 – Influence without Direct Power

• There is an interesting tension when you have only influence over another team as is the case with product managers. It’s not the same as an engineering manager who can put someone who is not performing on a performance improvement plan and set the measurables. But you are still leaning on one or more teams to deliver the success of the product.
  • David’s job has nothing to do with hiring and firing.
• Are the daily operations of the (engineering) team abstracted away from a product manager on purpose to allow more focus on the product itself without the burden of people management?
  • David mentions there is a development manager.
  • He is also not necessarily managing the complexity of how development teams solve a problem. David’s responsibility is more about the next problem to solve.
    • In order for this product to be successful in the market in the next year, what are the challenges we’re going to face (headwinds, tailwinds, economics, user base shifting, adjacent markets, etc.)?
    • Where do we need to be positioned? What important features do we need to have, what problems do we need to solve with it, and in what order do we need to do them? All are important things to consider.
    • How to solve the problem David is giving the team to solve next is really the engineering team’s responsibility.
    • Whether the team is capable and firing on all cylinders (i.e. if they need to hire or fire) is the engineering manager’s responsibility.
  • It starts to get a little confusing when we start to talk about technical product management. Technical product management may be asked to answer questions about / help decide on making technical tradeoffs.
    • Some of those technical tradeoffs may be about undersolving / oversolving a problem based on something coming in the future of the market.
    • It could be about frameworks and whether it is worth a shift from one framework to another.
    • To David this seems a little more engineering than product management, but he could see how it might be different at different companies.
• What about a frequent cadence with engineering management?
  • David thinks this varies more based on the product manager and whether they consider themselves more of a product owner / technical product manager or more of a business product manager.
  • David likes to go to all the ceremonies. If familiar with agile and more specifically Scrum, typically a product owner is a part of the ceremonies representing the set of stories that need to be worked on next and what an acceptable solution might look like for each story.
  • David is involved in all of this, possibly because he was an engineer and likes the level of detail. Even if it takes more time than it should, David enjoys it and considers it part of his happiness with work.
  • If David was too far away from all this he would not enjoy it.
  • This goes back to the director role he had and stepping away from it over time.
  • David found himself too far away from the engineering team and the week-to-week of what they were building. For David it was never about being the one to solve the technical problem. It was about the creativity involved in a solution to a customer problem.
  • "We have a problem to solve. How do we solve it? Let’s be creative. What’s a good solution? I just liked being close to the creativity of it all." – David Babbitt
  • This may be part of the reason David likes to be in lockstep with his engineering team.

17:47 – Product Managers and Customers

• What about time spent with customers for product managers compared to time spent with internal teams?
  • David has seen this vary by company. With David being new to the role at Amazon, he’s unsure of what the right balance is just yet there but will speak to historical experience.
  • At Ping Identity, the customer base was many name brands we might recognize. David did not get to interact with the users of the product that were hands on keyboard very often (only sometimes).
  • He would mostly be speaking to directors of security (since Ping is in the security space), often times for hours out of each week.
  • The time spent with customers was important as the responsibility of a product manager is to bring back the problems we are seeing in the market to the engineering organization (all in the spirit of contributing to the success of a product).
    • For example, David would hear from customers about their security roadmaps over the next year and where they want to be to ensure Ping was well positioned.
    • Customers might share that they were investing in automation technologies and being ready for containerized environments, which meant Ping needed to invest in their software running inside a Docker container.
  • You should dedicate hours per week to speak with customers. It never got to this point on a regular basis for David because other responsibilities crept in (filling those gaps and being the "ooze" discussed earlier). Filling organizational gaps can take away from the right amount of user and product research that David thinks is important.
  • As a PM you always have to empathize with the problem you’re solving for your customers or users. You have to be sensitive to the challenges they face on a daily basis or on a more macro basis.
  • You can’t make everything a research project as a PM. You have to go on the empathy that you’ve built in internalizing the sympathy you’ve developed over time.
• John says questions product managers would ask at executive briefings make a lot more sense now but realizes these cannot be the only opportunities PMs have to ask these sorts of questions of customers.
  • David would recognize in his past roles as PM the company needed him to do briefings (and several other outbound activities which he might not consider his primary responsibility).
  • But if David was going to be presenting or discussing a product roadmap at a briefing, he would stop and ask questions to make it more conversational like…
    • What do you think of this?
    • Of these 3 things which is the most important, and which would you choose to drop?
  • It may have made some people in the room uncomfortable that David would do it this way, but he was there to learn. John says this is typical behavior that he has seen at briefings from product managers.

21:37 – Reasons for Shifting away from Executive Director

• Nick’s observation is the shift from executive director to product manager got him closer to the customer interactions he got from previous visits to Spiceworks user groups (or SpiceCorps as they are called).
  • Nick and David met at SpiceCorps meetings originally. David would come visit and share what he was working on, asking those who attended for feedback on it.
• We know David wanted to make more of a difference and be closer to engineering, but did he also miss customer interactions in his executive director role?
  • The responsibility of a director and influence over a larger organization, it definitely makes an impact on the company.
  • David actually became a director twice (at Spiceworks and Ping).
  • This goes back to David’s willingness to do what a company needs (almost to a fault), and he did so each time he was presented with the opportunity to become a director.
    • The first time he thought "yeah, I’ll try it out." The second time he went into it with eyes wide open. David knew he was probably not going to be doing it for very long.
  • In both cases David feels he got too far removed from the creativity.
    • Much of your job as a director becomes about managing others, reporting on status and managing up, and managing progress / managing against goals.
      • "All these things are super critical….They just weren’t things that super excite me." – David Babbitt
    • As a product manager David can have more balance with the other half of his responsibility being to work with product engineers, designers, and customers to really solve customer problems in a creative way.
      • In the director roles David was too far removed from this process and just didn’t enjoy it.
• We should not be pushed into a role and then stuck there. It’s ok to take a step back down, which David did twice (each time after being a director).
  • John says it’s important to know what takes away energy in your work life and what gives you energy. If the main responsibilities of a role take away your energy and make you unhappy, you should not do it.
  • It’s ok to say you filled in on something for the organization but want to go back to something you were doing or just make a change.
  • David said the executive role taking away energy may be a little strong. To be fair, he wasn’t good at it. He did not want to put in the level of effort necessary to be good at it because it just wasn’t something that excited him.
  • David gets excited by going and interacting with users, understanding the problem, thinking creatively with engineers to solve the problem. As a director he didn’t experience that and just did not put forth the effort into being a good director.
    • David says even his previous bosses when he was a director would agree with his assessment of not putting in the effort to be a good director.
  • John feels that when something gives you energy you will independently raise your level of effort as a result.

25:26 – User Stories and Acceptance Criteria

• What are user stories? We ask David to help operations folks who may not have heard the term understand what they are since he has experienced them from the development side and now from the product management side.

  • There is often a name for this pattern of writing a story, but in David’s experience it usually goes like this:
    • As a so and so (user / persona), I need to or I want to do such and such in order to do such and such.
    • Usually it is I need a feature or I need to solve a problem, and the "in order to" is more like the outcome.
    • If you are familiar with Jira or another project management system, you might say as a product manager you need a way to rank user stories and features inside your product in order to achieve product goals and ensure things are worked on in the proper order.
  • David feels he puts more effort into writing user stories than the average person.
    • One thing David liked from a book he read on story writing was to think of it like a caption from a vacation picture. The caption for the picture doesn’t tell the entire story of what is in the picture, but the idea is to get together with your engineering team and talk through the story you wrote.
      • The engineering team will feel their way around the requirements by considering what if scenarios and how problems could be solved. They are sort of asking you for more detail about your vacation, including what was happening before and after the picture, how someone felt during the picture, etc. But what the engineering team remembers most of all will be the caption you wrote at the bottom of the picture.
    • "Your goal isn’t to write down everything that you experienced that’s in that picture. Your goal is just to sort of write the caption and talk through it." – David Babbitt
    • While David does put a lot of effort into user stories, he is not pedantic about it all the time. He tries to follow the format mentioned above for user stories but keeps in mind it is important to relate to the customer and what they are ultimately trying to accomplish. Too much emphasis on the format can make you lose sight of the bigger picture.
    • To David, it’s about a requirement, and then he wants to have a conversation with the engineering team about what he is asking for to ensure everyone is on the same page.

• The collaborative exercise of making sure everyone is on the same page (product management and engineering) is actually spent writing acceptance criteria together.

  • Acceptance criteria is usually a few bullet points on a story to put in writing what an acceptable solution would be for the problem outlined in the user story.
  • David looks at this in a specific way. Since he was involved in writing the acceptance criteria, he has to accept however the engineering team chooses to solve the problem.
  • If David keeps getting back what he does not like in return for acceptance criteria, he / the greater team needs to get better at writing acceptance criteria.
  • Acceptance criteria are also used as a measure of making sure the team understand what the requirement is. David might create a couple of bulleted items on his own and will then pull in the greater team to make sure everyone understands what he is asking be solved.

• John asks if this is a way to reflect the requirement that the customer base has with acceptance criteria acting as more of a metric on whether this was met?

  • David says another way to look at acceptance criteria is to look at what complete looks like and how far to take the story.
  • Sometimes when developing acceptance criteria David will ask the team to come up with an example of taking it too far.
    • Engineers, if unclear on how far (or to what degree) to solve a problem, can take things way too far (to the nth degree).
    • David says it is good to talk about the boundaries when discussing acceptance criteria.
    • John gives the example of a team spending 400 engineering hours to trim a report run time down from 30 seconds to 13 seconds. It could have been that the product manager didn’t want them to take it quite that far and that the report running in 30 seconds is fine.

• Nick says acceptance criteria seem analagous to job descriptions. You write the job description with someone so you’re in alignment. But then the person you wrote it with (perhaps the hiring manager) is in charge of solving the problem (or in this case doing the hiring).

  • David prefers to do acceptance criteria collaboratively. Sometimes you can write acceptance criteria on your own, having put together a few sentences / paragraphs, and get lots of nods when you present to the team. But the team isn’t really thinking at that point how they might solve the problem or what an acceptable solution might be. If you just move on through the ceremony from there, two weeks later / six months later when the team is implementing this idea, team members might start to ask what was originally meant by certain parts of the acceptance criteria because no one was really in agreement when the criteria were being developed.
  • Refining stories with a group and writing acceptance criteria with a group take time, and it’s an area where David would like to improve (get faster at the process). Doing this collaboratively is a way to quickly get alignment on the problem everyone is trying to solve.

• Mentioned in the outro

  • We’re into breaking stereotypes about having to stay in management if you pursue that path (or any path). Take David’s example to heart of making the move up to manager and eventually executive director but then moving back to an individual contributor role. If something is not the right thing for you, you can take a step in another direction.
  • The move up to management and back to individual contributor is not so different than the generalist who later becomes a specialist. For more on this topic of generalist and specialist, check out Episode 26.
  • Should sales engineers consider using user stories and acceptance criteria in their work?

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