Past Pairs

Suzanne: So this is a little bit of a unique construct for the 100PM show having two product managers in one episode, but it's also because this construct of pairing is a little bit unique to Pivotal. I want to talk about that, but David, first tell our listeners who is Pivotal?

David: Yeah, Pivotal Labs is a software development consultancy. We work with a number of different companies, enterprises, and startups, to help them build software in an agile way.

Suzanne: So when you talk about being a software development company, my impression from that is you have clients. They want to build product. They turn to Google and they're like somebody who builds product, help. They find Pivotal? That's probably a crude explanation. What catalyzes the need from a client side to say, "We need to build a product?" Then how do they typically find you?

David: A lot of enterprise clients, like CoreLogic, for example, really feel the need to be more agile and more reactive to the market, I think that's why they seek out a company like Pivotal. They see the need to move quickly and not get left behind with changing market needs. That's why they come to us.

Suzanne: Fred, are you a product company yourselves? Help us to understand what is CoreLogic?

Fred: Sure. A bit of background about CoreLogic, we provide property information analytics and data solutions for the real estate, mortgage, and insurance industries, just to name a few. We are, as you mentioned, in collaboration with Pivotal Labs. We want to create a global center of excellence for our next generation technology platforms, applications, analytical models, and solutions. We really recognize, I think, as an enterprise company we needed to move fast. As Dave mentioned, we need to respond to the market quickly. We really wanted to focus on innovation and to take it to the next level. With Pivotal, we are really investing in that so that we can quickly respond to market needs and provide just better solutions for our customers and users.

Suzanne: Thinking back to sort of before, CoreLogic is a product company, right? You already offer products, so I'm curious to know for a company of your scale, what catalyzes the need to go outside? I mean, you talk about working quickly, but it raises the question of why can't we just adopt agile process internally? Why do we need to go to a company to help or do that with us?

Fred: Sure. I think in my opinion, it's one thing just to adopt a process. It's a different thing to adopt an entire new culture and mindset. While we may have already done agile throughout the company in different areas, the differences in not just the process that Pivotal has helped bring to our labs, but really there's a different way of thinking about products, and in particular, delivering value to our users. The focus on user centered design, on delivering value in an incremental way in every step of the process, those types of things, and again, the way you do it using extreme programming practices, being lean, all those things are a change in mindset.

I think being immersed in partnership with Pivotal really helped ingrain that culture into what is otherwise a larger enterprise company with offices throughout the world.

Suzanne: Let's talk about extreme programming for a moment. I have a favorite slide I like to share in my classes about agile. Demystifying agile and if agile is the umbrella, right? It's the set of principles and values that are about a certain way of approaching process, and then underneath that umbrella, we have different software delivery methods and different management practices. We have lean. We have KanBan. We have XP. What is XP for those people listening in who have never heard of it before?

David: Yeah, great question. XP is really the principles of agile taken to their extreme. You have code review done by pair programming, so it's live code review. You're working together as a development pair. You're checking your code constantly as you go. You're releasing software ideally every day as often as possible. We work on weekly iterations, for example. You're constantly seeking to improve. You have retrospectives every week to discuss how things are going and what you can change. A lot of those core principles of agile can be interpreted in different ways. XP really takes those and kind of pushes them to their boundaries so you can truly be building software quickly in a very iterative way and always striving to improve that process too.

Suzanne: Every developer has a developer of equal skill set and capacity beside them, or it’s more of a senior paired with a junior? What is that construct?

David: That's a good question. It could vary. You could have a more senior developer paired with a more junior developer, and the idea is they can get up to parity quicker that way and help each other. It could really fall on either way to be honest. The idea is that it will both have productive input to bring to the table, whereas someone who's more experienced in one language might be able to help up another developer in that area. The other developer is not as experienced may bring their unique knowledge to the table too. It works out nicely in that way.

Suzanne: The impression that you're creating for me is somebody is coding and somebody else is in real time being like, "Woah, you forgot that end bracket." Is that how extreme it can be?

David: That's exactly how it goes. Your pair is, in a way, a check on some of the, let's say, crazy ideas you might want to implement. You're definitely doing that real time.

Suzanne: Wow. So this is kind of the original concept of how Pivotal, as I understand it, of how Pivotal started is XP was relatively young, relatively, not relatively well known, and it was kind of one of the foundational principles of what set you apart as a consultancy. You've evolved that pair concept beyond just the developers.

David: Yeah, indeed. We pair as product managers and as designers too, which is quite unique. I've never done that before I came to Pivotal. I'm pretty sure most of our clients haven't either. It's a really interesting idea, but I think my experience pairing with the client, the great thing about that is we can show them our process, our methodology. We can work on it together. Then, they can start to take it and run with it and take it back to their company and start to become a champion for the process themselves.

Suzanne: Were you and Fred pairs at one time?

David: Yeah, we were. We were pairs for about eight months almost I think.

Suzanne: You're not pairs anymore. You're past pairs.

David: Yeah, we're past pairing.

Suzanne: You all listening, you can't see it, but they're smiling lovingly at each other, so I think they had a good experience being pairs.

David: It's funny. Yeah, we did. It was really good. Like I said, Fred comes in, we work together, I can help him understand the Pivotal process, both from the very beginning of the project, which was a lot of user research and discovery, to the backlog management, to actually starting to build the product we were working on together. It's super valuable, because we have two heads I think are a lot better than one. In this case we can be a lot more productive. We can actually silently check each other too just as our development pairs would be. We can think about whether ideas make sense. We can flesh out really good user stories. We can help tag team to unblock the development team as well, both internally on the stakeholder side that Fred has to deal with, and I can help him with that too.

It does sound somewhat counterintuitive to have two people being a product manager, but I would argue that it was actually doubly effective. That's typically how I find it.

Suzanne: Part of your process is you require the client to come here and work.

David: Yeah. That's another really important part of it. Again, it's part of the XP principle too is that the team should be co-located, fosters better communication as you saw out on our work floor there. We are working right next to each other in pods. We have a question of the development team or of the designer, it's literally a case of either turning around to talk to them or walking over to talk to them. Ideally, we would like our clients to be co-located. Doesn't always work out that way. We do some remote pairing when we have to. We can use Google Hangouts or Appear.in, something like that, or Screenhero, to make that happen.

We would much rather work in person, so we get that more nuanced face-to-face communication. We find that it makes for a lot more effective product development that way.

Suzanne: What does a typical team construct look like? Let me preface this by saying the challenge for product management as both of you probably know, is it can look very different depending on where you are. Do I have seven other product managers and I'm the lead of that department? Am I the CEO and the product manager and the CTO and trying to be all of those things? When you typically have a client engagement come, is it one PM, one designer, one coder and then teams of six? How does it look?

David: Ideally, it would be a balanced team of, let's say for example, two to three pairs of developers. A client designer, a Pivotal designer, a client product manager, and a Pivotal product manager. That would be a typical and probably the ideal situation for us.

Suzanne: Okay. Fred, CoreLogic is a slightly different complexion, because you actually have an innovation lab yourselves co-located here with Pivotal. Did it always start that way, or was it we're having so much fun, let's not leave?

Fred: I think the goal was always to adopt the culture. I think the best way to do that, as Dave mentioned, is to be co-located. We are, I think from the outset, we knew that in order to really instill that ingrained culture, it wouldn't work trying to just have people go into our existing office and spend a few weeks there and then leave. There's no way to plant the seed. I think we knew from the very beginning we would have to really be set up here with Pivotal, have the stacks. It sounds silly, but the ping pong, the snacks, the breakfast. All of them serve a very specific purpose. We can get into that if you're interested.

Suzanne: I mean, I'm getting interested in eating the snacks and playing ping pong, but I don't know how much it'll benefit our listeners.

Fred: The pairing, the shared workspace, the stand up desks, all those things are actually purposeful in terms of the process. To be co-located to actually be here in the same office with Pivotal was the best way to really ingrain that mindset.

Suzanne: Does CoreLogic then send, or deploy, handfuls of team members to come and 'live' here for a time, do the pilgrimage, and then return back and help to spread the word and manifest that culture more deeply or just rotate and bring other people to be exposed?

Fred: Sure, so in the beginning, I was an external hire to CoreLogic, I was hired to start working in labs. We also had existing CoreLogic employees come here as well that were hired into labs. Then, we also had temporary assignments within the organization for people to come here. The temporary assignments would spend anywhere from three to nine, to 12 months in some cases, and then go back to their home office so to speak. They'd start to instill and plant a seed in the other offices. We're now working on expanding out our innovation labs to other satellite offices within the company.

I think now that we've established and understand the process, the culture, the mindset, we're better able to do that as an organization.

Suzanne: I always tell my clients, I think the mark of a great consultancy is we'll teach you to fish. Then, you can fish. It sounds a little bit like that's part of the benefits that CoreLogic is realizing is we took this deliberate approach to we want this learning to be lasting and now you're beginning to be in a place where you can start to stand up these processes yourselves.

Fred: Exactly.

Suzanne: You've learned to fish.

Fred: That's always been the goal from the very beginning. Absolutely.

David: I think to take that concept further, we want to create fishing instructors. We want to create people from CoreLogic who, let's say Fred is a product manager, who can then act as an evangelist within the organization for the type of process and methodology that we follow here.

Suzanne: Right.

David: He then becomes a teacher. That would be our ideal outcome. That's what we're striving for.

Suzanne: Yeah, and it seems to me incredibly important because I think we've all experienced that great ideas can die on the vine if there's not the right level of internal support. It's like, "Oh, here's this great little initiative." You go away, you learn, and then you come back, but if you're the lone voice saying, "No, we have to have a reduced waste approach to doing this. No, we have to have accountability. No, we have to have agile process." Then, somebody just kills it because it's too much work to support it. Then, it's really all for not. I'm curious to go back to the construct of client teams coming here - is it typical that a client would already have a product manager? I imagine at this point most companies employ designers and developers usually at a much smaller scale than is believable from the outside. Do they even have PMs in the first place?

David: Yeah, so it's a real mixture. Some companies have business analysts. They have project managers. Some of them do have product managers. Not many have them in the sense that we would consider a product manager to be, very much kind of full stack, as we were talking about that at breakfast this morning. This concept of a product manager can really own the product end to end from the user research phase all the way to deliver and play a very active role in the day to day management of the backlog.

We see very few companies that have that kind of product to manager in place already, and that's the kind of person that we like to train up. Usually they'll identify someone they think has potential to perform that role, and they will come to us. With that person, we will then pair with them. Typically the set up they've had before is being different to what they would experience here.

Suzanne: Why do you think it is, both of you, from different sides of the fence on this, why do you think it is that so many large scale companies don't have product managers?

David: It's a good question. I think a lot of it probably has to do with the challenges of scale and hierarchy especially. You have stakeholders who they would like to build a certain thing. They're opinionated in that way. So you don't have this kind of bottom up product driven type of approach that you would have with a product manager who's given greater autonomy to actually explore the ideas, make sure this is a good fit for both the business and the user or the consumer. I personally think it comes from a lot of that top down approach.

Suzanne: Right.

David: Yeah.

Fred: Yeah, and I think to build upon that, historically, my understanding is product managers as a role is a relatively new concept in the last 10, 15 years. I think historically senior people were measured against their ability to anticipate or understand the market, the users, their customers. I think it takes a different type of modesty, humility, to be able to take a step back and say, "I might not know what's best for my users. I want to go talk to my users. I want to do user research. Even if I have a hypothesis, I want to validate the hypothesis." I think more recently there's an understanding, and there's a better acceptance of that sort of humility for innovative companies in order to make really next generation products that really address user needs.

The whole shift in, again, senior management supposedly their role is to understand that direction versus a product manager nowadays recognizing that my job is to put this process into place and execute on it so that we can come up with the right problems to solve.

Suzanne: I think it's really beautifully put because just in life, right, there's so much pressure to look like you know what you're doing and to be right and to be the best and different people growing up have different experiences of that pressure, but in a lot of ways, I would agree with you entirely that great product managers are really comfortable being like, "I have no idea," and actually recognizing that's the most honorable position to start from. If you start from, "I have no idea," or you start from, as you say, "Let's go find out," then everything is an open investigation that can lead to real insights for better and for worse.

For better and for worse is removed, because you're not as attached to the outcome versus if you've already decided that you know what's right and then you go out and do some customer research and it doesn't come back favorably, this is where I think you see a lot of people fight to deny that research or ignore it or say forget it, we're doing it my way anyway. Then, the process comes crumbling down.

David: Exactly. It's very hard to let that go, those personal biases. You have to be someone who's comfortable with a lot of change and uncertainty, and like you said, not knowing the answer. You then have to ask a lot of questions. You have to be that inquisitive person I think.

Suzanne: Are we there yet? Are we there yet? Are we there yet? It's funny when you were talking before, David, about the product manager role and maybe it's analysts, maybe it's product managers. One of the things I encounter a lot as an instructor, people come up to me after a workshop or after a course. They'll say, "I think I've been a product manager for the last two years, but I didn't know." They came into the class wanting to learn more about product as though it was this sort of other cool thing, and then discovering exactly that, that what they've been doing under the label of project manager or something else entirely, is owning the responsibility of a workflow, of an actual process, of a product that's been built, sometimes without fully thinking it through.

Do you have those same revelatory experiences from clients that came not as product managers but left as product managers?

David: Yeah, absolutely. They definitely empathize with that. I think most people really want to be approaching their job like That. They want to have that concept of exploring new avenues of really taking a sense of ownership of the product too. Yeah, I definitely experience that. I experienced that myself in my last position at a start up. When I look back on it I started in marketing ,and I thought, "You know what? I really want to change the product, because I can't effectively market something that doesn't really fill a need for the users." Then, I realized after year that that's what I was doing. Then, I made that more formal switch into product. I've had that myself, and I see that from clients too.

Suzanne: I'm curious if it works equally the other way, though, where differently from the CoreLogic experience, Fred, as you described, where there's clearly buy in and desire to have this be a lasting change. If sometimes people come, you know, they came as a project manager, an analyst, they experienced the reality of product management. They, like anything, you go away, and you're rah, rah, rah, and you're excited. Then, they get back to their office, back to the old habits, back to distractions. Then, this product management role sort of collapse. Have you ever seen that happen?

David: I think it can happen. It certainly is more likely to happen if there is not a greater effort within the company to change things fundamentally between the structure of let's say the way the legal department is run, the way projects are funded, the way operationally things are done, all the way through to HR for example. If that support structure isn't in place and the company isn't truly committed to changing the way they build product, then there are people coming back in with this newly acquired knowledge are going to have a much harder time implementing it. It's a lot more likely that, like you say, they will fall back on the old methods. That's what they have to do to operate within the current environment.

It does need to be a big shift. I think going back to your earlier question about why companies come to us, I think they're recognizing, to the point Fred made earlier, that you don't always know the best answer for a product as a senior manager for example. They're recognizing that, and they want to come to Pivotal to become better at understanding truly what makes a successful product.

Suzanne: Right. One of the essential distinctions that I tell clients all the time is products are not projects. We're not building a campaign microsite for a contest we're going to run for six weeks. We're building a platform, whether it's some sort of tool that you're using internally to increase your efficiency, whether it's a tool that you're using to offer a top line revenue opportunity or bolster customer loyalty or engagement. You know, a lot of the times, these ideas from the top. As you described earlier, they get built. Then, there's no consideration for who's going to look after this thing? I say it's like having children. If you commit to putting one into the world, you kind of have to commit to feeding it and clothing it and steering it through the hardships of adolescence, which is-

David: Yeah, when it throws up on you, you have to clean it up. All that stuff. Yeah, I think it's a really good point, because a lot of people ask us, "When's this going to be done? When's this product done?" The answer is it's never done. It's a continually evolving thing, and it's going to have to be to remain competitive, presumably you launched it for a reason. There's a business fit and a user need that you're trying to answer. You have to continuously work on it.

Fred: Yeah, one of the things I'd like to emphasize is a lot of people, especially when you're thinking about product as a project, a lot of people think the end goal is whenever you release that MVP, or whenever you make that first go to market release to your customer base. In fact, and there's a lot of thinking around this and a lot of articles written about it, the first release to your customers is actually the very beginning. That's actually the first step. In a lot of ways, that's job one. There's a lot of emphasis placed on everything that leads up to that point, but the reality is there's so much more needs to happen after that.

Until you actually have the product in customer's hands using it, paying money for it, until you're doing that, you don't really have a product. I think a lot of organizations in some cases overlook that key point.

Suzanne: Yeah, I would agree entirely. I think one of the challenges from a consultancy perspective is number one is you say David, you're always championing the process and the importance of being able to continue to champion the process when we've come and done our help and left. I think the other challenge, especially in startup context, you mentioned startups earlier, is you're building a product for which the actual process isn't known entirely. You know, we always advocate, of course, for less, less, loess, subtract, subtract, subtract, and then of course people always want to put ... Features is a fear defense mechanism I think. It's like if we just keep putting features in front of the release, then we don't ever have to face the really hard stuff like can we actually drive any customers to this thing?

Can we actually convert any customers? Also, we might develop a really elaborate work flow where the user app interfaces with the admin experience, which pings the system and all of these things happen, and architecturally it's sound, and from a UX perspective it's sound, but then we go into the world and we have to manually work alongside that process and realize, "Oh, this isn't the right order of things at all." You know, I've had certainly the experience where clients come back and there's this sense of, "You should have known how this was going to work." Have you ever had that?

I think why I'm bringing it up, Fred, is because it speaks to your point about getting it to market is the beginning not the end. That's when the rubber hits the road, and then all of these realities meet you. You have to say, "Well, we've got to make a change. We've got to adjust the code. If you're thinking about it project-centric, then I already spent $60,000, $600,000. Now you're telling me I have to spend half that again to change these things? Don't you guys know what you're doing?" Don't you know what you're doing, David?

David: That was a great question. You know, I haven't had that specific example. I'm going to have clients talk about that, but I think what's important to remember is that we provide ... The process is important, but it's really a set of bumpers, or framework, for a company to work within. I think the core principles of being flexible and adaptive are what they have to remember there given the situation you're in. Every company has a different situation. The core principles are the same, I think, in terms of building effective product, but we can't anticipate everything that is going to happen.

Suzanne: Right.

David: I've never had that specific question though.

Suzanne: It's real. It's out there. I like to put all the dirty stuff right out on the table and just be like, "Let's name this."

Fred: Yeah, the interesting thing about your example is with any process within any enterprise, or any company, you have to adopt the process to work well within the culture of that organization. Though in the case of the example that you gave, there's a key aspect to product management which I think is often overlooked, which is a skill and the ability to influence. Outside of the process, there's a next level that we need to do that we need to figure out within our organization around how to work with other aspects of the organization, other business units, other leaders, leadership within the organization to influence the right type of decision making.

As a product manager, again this is just my personal opinion, but as a product manager, that's a key skill. You, on a day to day basis, are working with your team of designers, developers to influence them to some degree. You also have stakeholders within the organization to influence the business decisions that are happening. These strategic decisions are happening with the organization, and being on the ground, having to talk to users, having to deliver on the product, you have the ability to have a very good opinion on where things should go, and your ability to influence other decision makers to make those directional changes that align with your opinion. That's a very, very important skill set in my mind.

Suzanne: Yeah, I'm so glad that you brought that up, Fred. Just last night, I was having dinner with a friend. She asked me, "What's the most challenging part about the work that you do with your clients?" I didn't have a long list, because I really love the product work, but one of the things I said is, "It can be frustrating when you're advocating for the decisions that are right." I don't mean right from an ego perspective. I mean right from a lean perspective. Let's walk before we run. You don't need to spend this much money right now. You need to spend one fifth of it and see if you can prove out just this one tiny piece.

I take that very seriously. It's like I want you to succeed in a landscape where it's actually really difficult to succeed, right? The odds of succeeding are one in 10, and I want to give you your best possible chance. I want to do that by infusing the mistakes that I've made from the past, the best practices in the process. I want to save you money. I want to save you aggravation. Then, at the end of the day, they're like, "Thank you, but no. We're going to do this."

You know, I think that's kind of a really challenging piece. Then, I remember that the benefit of being in a consultative capacity is you can say, "Okay, well they're on their path." I'm curious, Fred, in the context of being internal, and as you describe that of sort of having to advocate internally, it's more challenging. It's the same feeling, I would imagine, of really knowing what you think is the right thing to do and being met with extreme resistance or being overruled. Then, you also have to kind of stay there and be in it. Or, as many people have been faced with, then they leave a company because it's too difficult to reconcile the differences. Can you talk about experiences, either your own or folks that you know that have had to be in that difficult moment?

Fred: Sure, without going into specifics, the first thing I'd like to say is having a culture of collaboration is key, right? Being able to have those open discussions and understand the reasons behind them, even if they're opposing view points, and having a culture of being able to have that open discussion is really key. Given that, there's different ... Going back to influencing. There's different ... Again, this is sort of a leadership thing, so this kind of helps with any of your listeners out there who are looking to get into product management. There's different styles or tactics that can be used to influence people. One of them is rationalizing, which is around providing facts.

You can always go back and say, "This is what we found in our user research. This is what users are saying." If there's a different opinion, that's fine, and like I mentioned earlier, being modest and humble, being able to say, "We have this hypothesis. Let's agree to disagree on if we have different opinions about it, but at least let's agree to do some research just to validate the hypothesis." I think that helps address a lot of sort of product decisions. If you can always hide back to what users are really giving feedback on, that helps. Of course, there's other aspects too. There's always you can leverage just person relationships, or just your ability to bridge with people.

Sometimes it's a give and take, right? There's a negotiation going on. Sometimes it is just someone more senior saying, "We're just going to do it this way for these reasons." They might be valid reasons. They might disagree with some of your findings, but it's a discussion. It's a collaboration. It's a team effort. I think at the end of the day, being able to understand the reasoning and at least as a team come to a decision, even if people have different opinions about those things, if it's made in a collaborative way, I don't think it's necessarily ever a bad decision per se. It's just a decision, and then you build from that decision, right?

David: I think what Fred is describing there is a key trait of a good product manager is empathy. It's empathy for your team. It's empathy for the stakeholders, for the user, because you're this person in the middle who has to connect all the dots and has to make this work successfully. Even if you believe your logic and your reasoning is sound and the person on the other end doesn't seem to be listening, you still have to empathize with them. You have to put yourself in their shoes, understand why they might be reacting in that way. It's key for product managers.

Suzanne: We talk a lot about empathy on the show and the importance of the skill but remembering empathy for the team, I think, is an important one. Sometimes we frame it as a product manager you're translator, but I think implied in that skill of being a great translator, of communicating developer concerns and needs and designer concerns and needs is an underlying I understand where they're coming from.

David: Yeah.

Suzanne: I'm curious to know what you think about the role of gut instinct in this day and age. You know, we rely as a discipline so much on the scientific method as you were talking about for very good reason as you described. Yet, there are sometimes cases to be made for we're looking at the data wrong. I know this is right, we just haven't pivoted to the exact place. How much room do you allow for that?

David: I think gut instinct is very useful when you need to make a decision quickly. Making a quick decision can enable you to release your product, get feedback quicker and really understand if you're going down the right path or not. That's when I think it's super useful. I think you can be paralyzed by indecision sometimes when making product decisions that seem really important, they may or may not be, but you have to make that decision. I think that's where gut instinct can actually be quite useful in terms of making a decision, going down a path, and being willing to change that decision and certainly measure the implications of that. That's when I think it's useful.

Fred: Yeah, and your comment made me think of something around the goal, right? If the goal is, in the traditional waterfall, the goal's more to reduce waste, to do something and do it once whereas in agile, there's not necessarily a focus on getting it right the first time. There's a focus on let's deliver value to the user as quickly as possible. We may very well know that the way we're doing it might not be perfect, but at least we can get it out there and get some feedback and then iterate on it.

You might iterate, and you might "have waste" because you are redoing things, but again, the goal's not to limit the amount of reuse. The goal is to deliver value as soon as possible.

Suzanne: Right, and I think that's the sentiment. That is the fail fast, learn fast kind of thing. It's don't be afraid to be wrong, be prepared to quickly learn why it was wrong and then make an adjustment.

Fred: Mm-hmm (affirmative).

David: Yes.

Suzanne: You talked before, David, about you were at a startup before. I'm curious about your experience as a PM inside of a consultancy versus sort of that other application. I know certainly from my own experience one of the awesome things about being a consulting PM is you get to learn a lot of different businesses. You get to touch a lot of different projects, and you get to help steer products through very specific points in their life cycle, whether that's the introduction phase, whether it's through growth phase, whether it's into maturity or expansion, but at some point, you have to say goodbye. You can fall in love with these things a little bit.

Do you miss the role of being able to be kind of married to a single product and potentially be the one or one of the ones to steer it through its entire destiny?

David: I do miss some of that. There's always a twinge of that, that I miss. I think on balance though, I value the breadth of experience I get here in a consulting role more than that sense of ownership, because I think it was a lot of fun launching a product, especially a user facing product where you could see the numbers come in. You could look at google analytics. You could see who's using your product in real time, if it was going well or if it wasn't. That was awesome. It was a great feeling. I don't know how much of that is ego as opposed to just a sense of fulfillment. I get just as much fulfillment from helping companies start to research and launch a product as I did with actually "owning" a product.

When I talk to PMs who, let's say they want to work at Pivotal Labs, one thing I always talk about up front is, "Hey, if you're used to having this sense of ownership over a product, you're going to have to be prepared to let that go here, because we're working with a lot of different products." On the flip side, you will get exposure to tons of interesting products, lots of different people, different industries, and that's massively valuable too.

Suzanne: Fred, how did you get into product management? You said you had been brought on specifically for this partnership. Were you a product manager before that?

Fred: My career kind of started in ... I have a technical background, I have an engineering background. I worked in a lot of different roles throughout my career, which I think none of them were specifically labeled as a product manager. They were different skill sets that I think are required in a product management. For example, I've, in the past, been a data analyst, a business analyst. I trained people in software. I was a strategy consultant. I was a project manager on a SASS eCommerce platform. I was an account manager for a royalty and licensing SASS platform.

All of those things being client facing, having project management skills, having strategy skills, having data and business analysis skills, and even user facing training skills, all of those things come into play in product management. Up until my more recent job roles, and especially this job role, it sort of laid a path that actually naturally ended up bringing me here today as a product manager.

Suzanne: Right, so did you immediately, when you were kind of appointed to the role, did you immediately have the confidence of, "Oh, this makes sense. I've already done this role in all of these unpacked linear ways?" Were you kind of like the example we talked about earlier where you looked back at your history through a new lens and suddenly went, "I've been a product manager longer than I actually thought?"

Fred: Yeah, it was definitely the latter. Actually, my last role I was a product manager per se, but I was wearing a lot of other hats too as working in a startup often requires. I knew at that point what a product manager was, but like I mentioned earlier, when I started out in my career, product management was not a career path that was clearly defined.

Along the way, I just realized oh all of my interests and all of my skill sets and the tools that I've built along the way actually fit into this newly defined, what was new to me, this newly defined role that's labeled as product management. From that point on, which was I guess like 2012 and onward, then I realized okay, I want to be a "product manager."

Suzanne: Your title is actually senior technical project manager and I have to ask this question because I get asked this question all the time. Just how technical does a technical PM need to be.

Fred: That's a good question. I think it really depends on the organization. I think having a general understanding of tech stacks, you know, database ... not even details but just architectural things. Being of analytical mindset and logical mindset is important. I wouldn't necessarily say anything I do today is super technical. I'm not necessarily reviewing code, for example. Some organizations might require that from a project manager, but I'm not looking at code from that perspective. I might be looking at XML or JSON or interacting with API's to test them to accept stories, but again I'm not reviewing code. So- I don't think ... it really depends on the organization. In my current role, it's not that technical in my opinion.

Suzanne: Right. But they like to keep the technical in there so that if something goes wrong on the coding floor they know they can come and grab you. "Fred, we need you! You're a technical PM, right?"

Okay. Let's do, "get the job, learn the job, love the job." This is a segment we do regularly on our show. Start with you, David. Advice for up and coming PMs or people who are newly in the role, working just outside of the PM role, want to in to it, don't know how to make this step. What would you say.

David: Yeah, so- my first advice would be to find a company that you really believe in. Certainly in terms of culture and ideally product as well. Because you want to be working for a company where you're passionate about the way that they're building product and the products they're building. So- that, I think, is the first thing.

Honestly, if you find such a company that you love, any closely related to role that you can get into to begin with would be fine. Kind of using my own example of really starting in marketing because I had a marketing background and then transitioning in to the product team within that start up because I believe that in order to have more effective marketing initially we needed to improve the product a lot. So- that was my route at least. But I think it all starts with the company and the culture.

For up and coming product managers too, I think the more that you ask questions and the more that you show genuine interest in the product ... if you're at a company where, let's say that you're not on the product team but you want to be, I think the more that you demonstrate an interest in that and start to involve yourself more in those product conversations, the better.

You know, get to know the product team. Come up with ideas yourself. Do some user research if you can. Those things are all great ways of starting to get more exposure to the product. I think that's a naturally way to do it. We have a lot of product managers here and I've worked with a lot of project managers who, let's say, have a computer science degree, or an MBA, or a start up background. There are so many different paths that people take to project management that there's no one defined solution that fits everybody.

So- my advice would be find a company that you believe is building product in a good way and has a good culture and start from there.

Suzanne: I'm glad you bring up the point about taking an associated role and sort of working your way from inside. But I'm curious if you could speak to, in your opinion, what's the time line look like? Say I'm a user experience designer. I really want to move in to product but I know that I probably couldn't get hired for product but I could get hired for UX. But part of me is resisting that path because I really want to be in product. Is it ... take this UX job, spend a year, actively work your way, could I be there in months? I mean I'm sure it depends but what would you think would be a realistic time frame.

David: I think that's a really good way to get in to it actually. Because as a UX designer you're going to start to build that empathy for the user, which is really valuable for a product management position. You're gonna get exposure to the product. You're gonna be involved in building a component part of it, designing it. I think, again it totally depends on the company, but within a year or two you could potentially make that switch. I think getting to know and understand the product very well will definitely help you there. So- I would say it might take a little while. I think it's interesting because product managers who have a lot of experience in different industries, I think come in with a great perspective on things but you just need to get that start. So- if you can do that as a UX designer for a couple years, I think that's a great way to transition.

Suzanne: Fred, what in your experience has been the hardest lesson that you've either had to learn as a PM yourself or that you have seen in peers where…this is not as easy as I thought it was gonna be in concept for the PM role?

Fred: I think the hardest part is personal growth. It's a little cliché, being humble and modest ... I keep coming back to that ... is an important aspect. People always talk about leadership as a general thing, but being able ... and again, I'm talking about similar themes throughout because I think going back to the whole influencing ... the ability to influence. So- knowing that you have a certain skill set and that you're strong ins some areas and weak in some others and having that modesty and being able to know, "I need to focus on getting better at speaking to senior management." Or, "I need to get better at fostering relationships with technical people, DBA's, you know, other people that I might need help from in the future." Things like that. Recognizing that and being able to have a concerted effort to focus on developing those weak points that you might have in your toolbox so to speak.

Suzanne: What about your favorite thing about this job? As you've described earlier, you've done all of the jobs and you seem to have settled in to product management, at least for now. What is it that you love about the PM role?

Fred: I think it is the ability to flex and use a lot of different muscles so to speak. It requires wearing a lot of different hats, again depending on what phase a products in. But having every day almost not necessarily being the same, always being challenged both from my operational perspective but from a personal growth perspective as well is one of the rewarding things. I feel like I'm becoming ... I'm leveling up in my personal skill set, but also in my ability to deliver value to the company and ultimately to users.

David: It's a full body work out.

Suzanne: I was going to say, it's crossfit! I had no idea. David, what about for you. What is it that you love about this role?

David: I love the fact that I get to interact with so many different types of people. From the development team, to designers, to stakeholders to users, I love the variety in the job too. I'm someone who likes to always be learning about new things and so that part of it is very appealing to me. I think that's what I get the most from.

Suzanne: Cool. Any recommended resources that either of you want to contribute to our growing list at 100productmanagers.com ? Could be books, podcasts, blogs, anything that has helped you shift your perspective fundamentally or?

David: Yeah, I suppose I would have to recommend "XP Explained" by Kent Black. So- the XP bylaw I suppose as it were. It's a really great book. It just kind of outlines the concepts of what we're doing and why we're doing. Working collaborative teams, building software quickly, getting fast feedback. It's just a really good book to explain certainly what we do here at Pivotal. If you read that, you'll have a good understanding of what agile means.

Suzanne: Do you make your clients read that book as part of their initiation?

David: Typically we definitely recommend that. Have you read it Fred?

Suzanne: I've read it.

David: Yeah, good, okay, there we go.

Fred: There's a follow up book also, "Planning XP."

David: "Planning XP" is good too. And then there's "Just Enough Research" by Erika Hall as well. A really good book in terms of helping you to understand what constitutes good user research, how are you going to make those informed decisions that shape your product?

Suzanne: Beautiful. Thank you. Fred?

Fred: Anyone that's new to product management or looking to get in to product management should deficiently read the General Assembly book on product management. That's a good intro.

Suzanne: Jock Busuttil.

Fred: Yep. The "Lean Start Up" is also very good reading. And in terms of a blog, you should definitely subscribe to Product Manager HQ. They provide weekly articles. There's a slack channel. It's definitely worth checking out.

Suzanne: Awesome. Great, great resources. A few new ones too to add to our lists so that's awesome. Last question, I'll ask you both. Fred, I'll start with you. Do you have a personal or professional mantra that you kind of use to guide the way that you move through the world.

Fred: I think it would have to be a lot of what I've been saying throughout the interview, which is being humble, having humility, knowing that you don't have all the right answers but having confidence in your ability to figure out what the right answers are.

Suzanne: David?

David: Yeah, so- professionally I would say do what works, do what's right, and be kind. Those are the values that we have at Pivotal and I think the last one especially is super important. So- never assume bad intentions of someone. Always assume good intentions. Be kind. I think that's something that will help you and it will go a long way in the work place and also in your personal life too. I really like that set of values that we have because it's pragmatic and it's also ... like Fred says, it reflects an element of humility and the ability to empathize with other people too. So I really like those three core values we have.

Suzanne: Beautiful. Thank you both so much, should we go and take some of that bulk candy in the kitchen and really play some ping pong and really enjoy the rest of our day here?

David: I think we should do it. Yeah.

Suzanne: Cool, thank you both.