Last week, we shared an interview with Tracker’s GM, Dan Podsedly, at the inaugural Product Stack product manager event in Los Angeles. As promised, here is the full panel discussion from that night, hosted by Suzanne Abate of the podcast 100 PMs, and featuring ProductPlan’s Greg Goodman and Laure Parsons of Notion.
The Product Stack - LA Full Panel from Pivotal Tracker on YouTube.
Stay tuned for future Product Stack events in other cities, and in the meantime: join the conversation!
Here’s the transcript of the panel discussion:
Suzanne Abate: I am joined here with Greg Goodman, CEO of ProductPlan, Jim’s better half; Laure Parsons, senior product manager at Notion; and the godfather, Dan Podsedly. The topic of our panel this evening is the future of product management and we chose these three folks here in particular because of their incredible ability to see into the future and know exactly what’s going to happen and therefore be able to warn us all how we can begin to change. No. Nobody knows what’s going to happen in the future, so disclaimer, this is a conceptual discussion about where product management is going and how to be effective and how things are different, and I thought that since we want to talk about the future, it might be useful to talk a little bit about the past. I’ll start here at the end and we can kind of work our way inward, but Dan, you started your career as an engineer, as you mentioned, and it was early days of agile, early days of extreme programming as you describe. How did you sort of experience the emergence of this product manager role or product management discipline around you?
Dan Podsedly: I can best maybe explain it through the lens of our place in that world. So we were a young consultancy. We’re really into small teams and agile XP, test driving, all that stuff. Even how we built Tracker, it was like, “OK. Every team or project needs a customer.” Then developers and whatever. There was always a customer and for a long time, even as we grew Pivotal to maybe even like 100 people or beyond that, we didn’t really clarify what customer meant. We expected the customer role to be played by an actual customer. So they would come in the door like, “Hi. We got some money. We have this idea. We want to build something.” “Cool. Sign this contract. Let’s go. OK, customer. Please add some stories to Pivotal Tracker.” It’s like, “Well, the product should be really good. It should be easy to use.” It’s like, “No. Those are not stories.”
Suzanne Abate: Simple. It should be simple and easy [crosstalk].
Dan Podsedly: Sure, and easy to navigate. Delightful, whatever. Or like these very coarse-grained like—blam—there’s a entire giant feature as a story. So even just that. Like we would help out. There would be an anchor on the project and they would sort of like, “No, no, no. You really should be thinking about it this way.” We would do these inceptions. We’d break things down, but then we really just like left the customer to be on their own devices and be a good customer. It wasn’t for years until we realized, “We better make that more of a formal thing. Oh, we’ll call it a product manager, because that seems to be what people are calling it.” So the product manager is now there to act on behalf of the customer’s interest. The customer is actually the stakeholder. Ta da.
So product manager, understand the stakeholder’s needs, problems, frame it, you know. Work with the engineering team. Break things down into more fine-grained stories. Things that actually make sense to sort of work through incrementally. So our experience was just very sort of like, because it wasn’t working, and so we need this new thing here. This new role. This new kind of person. Then that started to lead to like, “Oh, wow. Our projects are so much more successful now. Our customers are happier now. Our actual customers.” So that’s what a customer role in the sense of that XP team really should be. Then we basically built up a PM practice where every…like, we wouldn’t think of running any project without an actual PM who understood the product management space and being that sort of bridge between the customer and whatever other stakeholders where the engineering team designed everything else.
Suzanne Abate: Greg, you’re nodding. Tell us more. You have a mature beard and many stories to tell, I think.
Greg Goodman: Unfortunately, I do, and I’m going to date myself. I remember when we delivered software on floppy disks and I delivered software on floppy disks as one of my products that I built. So it’s evolved a lot and it was funny. Jim said this acronym that I don’t even know if any of you caught, but I laughed as soon as I heard it. He said, “I built the PRD for GoToMeeting.” If none of you maybe even know what a PRD is, it’s a product requirements document. It’s like this thick. That is what we people call waterfall method today. A lot of it was because you were building software for a floppy disk and you couldn’t update your software every hour or day or week. So some of it was technological that has changed a lot.
We now have SaaSes so you can do immediate deployments and have all of your customers using the same piece of software simultaneously. That’s not how it used to be. So it really, the product management role has changed a lot. I started out…I ended up double-majoring in computer science and business econ. That was rather unique at the time, although now it’s quite common, I think. Most of the large tech firms require a CS degree to be a product manager at a Google or at a Microsoft, and many times they want an MBA on top of it. So that’s becoming a much more formalized kind of approach to product management. I don’t think it, by any means, it needs to be the only way of doing it. Many of the people here do not have those degrees or come into it that way. I think that’s what the beauty of product management is is you’re the person that’s helping drive the vision for the product and that can come from a lot of different directions.
Suzanne Abate: Laure, how did you…what crooked path got you here?
Laure Parsons: I actually started my career producing documentary films. Then I moved into the business side of the independent film industry. I became frustrated over time because although the creative industries are really fun to work in and there’s a lot of parties and stuff, there’s not really a problem that you’re solving for anybody other than like, “I want something to do on the weekend and did you make the best thing for me to sit around in my house and watch?” Maybe, maybe not, because we didn’t ask you beforehand, before making it. So I got into working at a startup and I was employee 11 at this particular startup where you just wore a lot of hats and we didn’t have a product manager. My title was “chief storyteller.” I think Kevin mentioned this. There’s a lot of correlation between being able to drive a product vision and telling a good story and understand what the story of the customer is. So a couple of years into that we started using OKRs at our company.
Suzanne Abate: Acronyms, right?
Laure Parsons: Yeah. Sorry.
Suzanne Abate: What are OKRs?
Laure Parsons: OKRs are objectives and key results, so it’s a way of setting goals for your company and team and individual goals and then actually putting that together with a metric or some way to figure out whether you’re doing a good job in a numerical way. I found that really exciting and inspiring. So I found out about Notion after moving to Portland and moved over working there and yeah, it’s been awesome.
Suzanne Abate: Anybody here in the audience part of a startup organization? Anyone sort of addicted to the… But you all don’t look happy just now when you raised your hand. You’re like, “Yes. We’re with the startup team.” It’s such a thing being…I mean, I know you’ve all been… Dan and Greg, you’ve been part of startups but your experiences are very different now. As Dan described earlier, it’s structured very differently at Pivotal. Maybe you can each talk about how your current companies are set up. You know, starting with Laure. I mean, what does the product team at Notion look like today and if you have a vision for what it’s going to look like or needs to look like, perhaps later.
Laure Parsons: We’re a very small team and there’s just two of us in product. I think the vision for the company is really to organize product around different life stages of the customer, so right now both because of the stage that we’re at and for my background, I focus mostly on acquisition and activation and I also sort of do some experiments and sort of lean practices as well for the general product. Yeah. I think that the goal is to not have it be so much an idea of different products, but be an idea of really understanding the experience of the customer and focusing the work and the teams around that.
Greg Goodman: I think we are still pretty small. I primarily handle most of the product management. Jim and I collaborate on a lot of the prioritization and details around products. So we’ll get together and talk about stories and talk about what we want to do from a priority standpoint. Some of the things that I would probably say that are maybe a little unique in terms of how we manage things is we take advantage of something called a review app where every developer, when they’re doing a pull request, immediately has a server spun up and everyone can take a look at it if they want. So it’s a really wonderful way, as a product manager, to be able to kind of see incremental progress and make sure that what they’re building is what we want. So that’s a really nice amazing thing that the cloud has given us is the ability to kind of have unlimited resources for doing that kind of thing.
I’d say the other really big thing from a product organization standpoint is we are obsessive about talking to customers. If somebody reaches out to us on Intercom, which I know you guys use Intercom as well, I will, many times, will try to interact with them right on the spot or other people on our team. I try to encourage our team to have conversations with our customers about going a little farther when they say, “You want that feature? Why do you want that feature and what do you need about it?” So really just trying to dive deeper into what we need to build and why so that we can drive to a really viable minimum product so that we can deliver a feature as quickly as possible to somebody and get them the most valuable piece of it.
Suzanne Abate: I’m curious, because in the case for you and Jim, you’re so actively involved in the product management role, and this comes up a lot, is at what point do the founders have to say, “Well, now we have to go and shake the hands of the people and write the press releases and…?” Also you guys bootstrapped. You didn’t go out for outside funding so you don’t have to kind of have to kowtow to investor pressure, but is there a sense of, “Will anybody be able to manage the product as well as us?”
Greg Goodman: That might be one of the reasons why we haven’t hired a product manager yet, but that day is coming rather quickly because I know my time is getting rather thin. So yeah. No. We will be bringing more people and I think we’ll probably start more from the UX side. We already have somebody that helps on the UX piece, helps dive into more of the customer interviews, document those, set them up, and really kind of drive that forward. So we’ll probably expand that way initially, on the UX side more, and then we’ll backfill that with a full-time product manager.
Suzanne Abate: Dan, your circumstance is a little different. You’ve got this baby and they won’t let you go. You’re like, “Please. I’ve been here so long. Can’t you just go on without me?”
Dan Podsedly: Yes. It’s my baby and I do have that emotional attachment. When you raise a child, it really…you don’t just walk away, Suzanne. No. For me, it’s…yeah. I’ve been doing this for a while. I mean, it’s been…I don’t even know how many years, but our situation keeps evolving. We’ve managed to take…I mean, 10 years is a pretty long time for product and I think one thing that we’re proud of is we’ve sort of kept it going. We’ve had our ups and downs and little detours, but the product is still there. It’s still growing, kind of gradually. We’ve managed to sort of improve the product in place without resulting to like, “Ah! Let’s just throw it away and write a new one. Forget it. It’s getting to hard to work [crosstalk].”
Suzanne Abate: You never did a rewrite on it?
Dan Podsedly: So, well, you had to ask, didn’t you? We actually did do a couple of rewrites but they were more like sort of in place where Tracker started as our very first Ruby on Rails app and we didn’t know what the hell we were doing. How do you do like sort of real-time updates? Let’s build our own frameworks for consuming and propagating changes in JavaScript land and whatever. So it’s kind of like it was time to rip some of the code out but it wasn’t like we’re going to build a new product. We’re just going to sort of rewrite it in place to modernize the code base so we can keep going.
The emphasis has always been on incremental improvement and sometimes it’s hard, literally, just to like add some weight to whatever. Clone a story. It’s like, “Well, where do you put it?” You have to move some things around and it’s like everything is hard and it feels like you’re just taking these small steps that take a lot of time but I think if you step back, like there is something interesting about being able to keep going on a steady pace. Of course, then you get competition like, “Boom. There’s Trello and it’s beautiful. It’s got stickers and backgrounds and look at all the things you can do to it, because it does nothing. You just drag cards around.” Anyway, it’s been this sort of incremental journey.
Suzanne Abate: So you love Trello.
Dan Podsedly: What’s that? Do I love Trello?
Suzanne Abate: You love Trello, it sounds like that. Yeah.
Dan Podsedly: I love it so much. No. Actually we use it for a lot of things that don’t require the same sort of approach to building software. So yeah. It’s been very incremental and my kind of joy comes from gradually growing a team and learning some things about how to organize. One example is for a long time we were organized in a way that’s fairly typical out there. Like front-end team platform/back end. Then this other end like iOS app or whatever. Everything was like multiple PMs because we had a front-end PM and a platform PM and then everything was like, “Oh, we want to solve this problem for our customers, our users, or go after this opportunity.” Well now we have to like coordinate everything. Well, the platform’s going to need some new endpoints or whatever, or API endpoints to represent this new kind of thing that we’re saying, “Oh, OK. The front end’s going to have to consume it and build this,” and sometimes we start with the back end, the API, and we go to some place and then meanwhile the front end team was distracted doing something else and then by the time they got around to consuming those new endpoints, it didn’t make sense anymore.
We made the wrong assumptions. Crap. We got to change that. Everything was just a fight. Everything was about like, “We want to make our front-end code base as perfect because that is what we are attached to.” That was that team’s baby was the front-end code base so they just wanted to nurture the code base baby. So we changed and we reorganized into what we call vertical pods. I know some of you are doing this. We are one team, first of all. We’re 34, 36 people. So we have about 24 engineers. Sorry. 12 engineer pairs/units. So we have at least four of these pods where each pod is a PM, two to three pairs of engineers, a UX person. We have roving exploratory testers. It’s much better because now we’ve sort of organized it around the product managers. We as a product team, so myself and our PMs, we have a rhythm, like a weekly, almost daily rhythm around the conversation, like, “What is the big picture? What problem should we try and solve?” and framing everything as a problem. Like, “OK. We have some churn and the top reason is people outgrow the Tracker workflow. OK.
So that’s one of the themes now. That becomes owned by the PM with their own pod focusing on that problem and they can go end to end. There’s no more front end, back end. We all get engineers aggressively so that there’s always a mix of people who can do the work on every given pod. It’s working much better. I kind of find this to be much more product-centric, which is the important thing. Like, “What is the customer problem?” Empower the PM to go all the way and not negotiate with other PMs like, “I need this API endpoint. When are you going to give it to me?” That’s just a waste of time.
So for us that was a good learning experience and it’s this kind of thing. We keep evolving based on what’s working, what’s not working. Retrospectives obviously drive this. So for me it’s like, “Can we keep this going? Can we…” For us, speaking about the rewrites, we took a few years for one of those. That’s about when Trello came out, too. We’re like, “We’re going to have a better code base, right? That’s going to make everything awesome.” It’s like, “No, it doesn’t.” You kind of need it but don’t go off on big rewrites because then Trello’s going to come along or something similar and like eat your stuff. Now we’re like, “We’re at a better place. We’ve organized better. We have a bigger team and we can focus on the customer problems and make the product better.”
Suzanne Abate: Well, we use that term from Scrum, product owner, and it sounds like the shift is problem owner. So you’re sort of handing out problems for the product and where it is and, “OK. You’re in change of solving it.”
Dan Podsedly: You’re right. They’re not necessarily in charge of any particular product and in fact we had this debate when we were… It was a shift and there was a lot of pushback to this vertical approach where some of the PMs were, “Well, so if I’m just going to own problems, how am I a product owner or manager?” Because we also go back and forth like is it a product owner in Scrum? It’s product owner but then if you’re not doing Scrum you’re just a PM. People don’t want to put PO on their resume because it’s not as elevated as PM. So yeah. We kind of came to that realization like, “No. There’s just one product,” but we have different areas of problems/opportunity. So actually, I like that idea of just changing the names of those people to be product owners.
Suzanne Abate: You all heard me say it first. Right? If Pivotal Tracker puts out an article next week about problem owners, you heard it here.
Dan Podsedly: So therefore, I won’t own any problems anymore. Here you go. It’s your problem now.
Suzanne Abate: Well since we’re talking about this title thing, and this comes up a lot, the question, “How technical does a PM need to be?” Kevin spoke to this a little bit earlier in sharing kind of his path and you’re hearing this technical product manager, product manager of growth, product marketing manager. There’s all of these sort of iterations on the title. I think in part for me what it speaks to when I see that is, “Oh, this is an organization who needs a strategic person.” Right? Because product management is a strategy role. They need a strategic person and they need them to kind of skew toward a specific domain. I’m curious, panel, what you each kind of consider to be the most valuable skills and qualities that a product manager needs to have.
Laure Parsons: Yeah. So I would like to take this opportunity to plug a fellow Portlander, formerly a San Franciscan, Theresa Torres, who has a blog called Product Talk. I think that she has recently really nailed the future of what the product owner’s responsibilities and the product manager’s responsibilities will look like in the future in that she says that where we’re moving towards is that the product manager is the person who is responsible for deciding what to build. That is a different role than helping the team build that thing. Even though those things right now are very fuzzy and a lot of folks are kind of being tasked with doing both, that as this role gets more developed and people have a greater understanding of the value that a product manager could bring, their responsibility is to understand what problems and opportunities are out there for the customer to understand, from the team, how viable that solution that they may be envisioning is…but it’s really uniting those issues as opposed to just being like an engineer who makes a list of stakeholder demands or something.
Suzanne Abate: Well, I think it’s a little bit the dream for product managers, at least the ones that I speak with and work with, that they see an opportunity to come and create. They maybe not want to kind of do it all on their own, but they want to own kind of part of that creativity. I say this a lot to my students here at General Assembly, to folks that I mentor and advise, get really clear about what you want to touch and experience because some organizations are going to purport to offer you that strategic input and some organizations are going to be like, “You’re here. This is already all figured out and this is your role that you kind of need to fill in.” Theresa Torres, yes. Absolutely. It’s ProductTalk.org, I believe. Right? Dot org. I think that’s the opportunity to bring that creativity back. It sounds a little, Dan, like what you guys are also doing at Pivotal in your own way. Did you want to add something, Greg?
Greg Goodman: Well you’re asking about skill sets?
Suzanne Abate: Yeah. What do you value in product managers?
Greg Goodman: Communication skills, listening skills, I think are the most critical piece. The people that you’re interacting with are either developers, stakeholders in the company, or customers. Customer support, sales within the organization. I mean, you’re pretty much the glue from the rest of the organization through to development and that’s the voice of the customer. That’s the voice of management and executive team and just the vision of the product. In order to do that, you need to be able to listen to what’s going on both from a customer and sales and support standpoint of like what are the key problems that we’re trying to solve, but then also being able to listen really effectively on what your development team is telling you.
I think from an agile perspective, if you’re really trying to be agile, there’s a give and take. It’s not just the product manager dictating. There’s a lot of discussion around, “Well, how big are these things? Is there a way of releasing it in smaller chunks?” Really trying to get out customer value as quickly as possible in as small of pieces as possible. That’s a really difficult problem that you can’t solve by yourself. You really need all of your team to be participating in that. So I think the key elements are really around listening and communicating. Organization’s a really valuable one.
Dan Podsedly: I mean, all of that resonates for me. A word that I always kind of throw into it is empathy. I mean, the product manager is like the chief empathizer in my mind. Also, a skeptic. I think that’s all to do with why we validate assumptions, but like if your first question isn’t, “What problem are we trying to solve and for whom?” and then focusing really hard and understanding that problem and understanding that whom where all this empathy comes from, but also it shows up in having to kind of play that like sort of almost like a referee between, “Yes, I’m trying to get us to solve the customer problem and moving toward that incrementally and keeping my eye on that and understanding and representing the problem well,” but also…yeah. Hearing the engineering team that you’re…you are a team, but the engineers will always say, “Well, that’s really hard,” or, “We need to refactor this and rewrite that.”
Sometimes I don’t know. It’s a tough balancing act because…and then you have to be able to gauge when it’s really important to make that investment and say, “Cool, let’s do it,” or like, “Uh, let’s just do the scrappy thing and let’s try to solve that problem and learn from that.” But get it in front of our customer. So you’re kind of in the middle. Empathy, I feel like, is such a strong skill. How do you learn that? I don’t know. I mean, I think there are ways to become…
Suzanne Abate: I have a class on that, actually.
Dan Podsedly: Cool. That’s a good class to go to. Not having preconceived notions about what you think the solution is because I think we get that a lot, especially with more sort of like people who come from engineering into product management, their first thought is, “I know how to solve that.” You shouldn’t. You shouldn’t be thinking about how to solve it. You should be thinking about how to understand it. How to frame the problem. Then these days UX is such a strong discipline. Product management is. You didn’t used to hear of like, chief product officer as a title. It does sound weird, though, CPO, but still.
Product is elevated but so is design, and design should be the one focusing on how to solve the problem. You are providing the framing. You’re providing the direction. There’s some sort of a gut aspect of it, too. Like that is a good solution, that isn’t a good solution, but your number one job isn’t to think of the solution. Your number one job is to understand and then put the team together and work with design to solution. I get in trouble all the time with my team like, “Dan, you’re solutioneering again.” It’s like, “Yeah. Fine.” I guess I used to be an engineer and I always obsess about how we could potentially solve it, like, “Well, what if we had a Kanban board built into Tracker or something…” Like, “Dan, just tell us what problem we’re trying to solve.”
Suzanne Abate: You say skeptic. I say curious. But OK. Let me hold you all a little bit to task on this one because one of the things we do here at General Assembly, for those of you know, is we offer a lot of curriculum in a lot of these kind of emerging disciplines because traditional educational institutions aren’t able to keep up and so people are coming and saying, “I need to learn what user experience design is,” or, “I just got hired to be a product manager so I’m taking this class because I thought it would be good to know what my job is.” What are the skills though, practically, that you think if someone…you know, Greg, were to walk into your office and apply for that soon-to-be available product manager role, what do they really fundamentally have to know to be good besides the communication piece that you spoke to?
Greg Goodman: Obviously experience has a lot to do with it. I think, what you were saying as the empathy and the skills to be a really good product manager I think really only comes with experience, I hate to say. So I think we’re at a probably…for us it would probably be somebody that would need to at least have a few years’ experience so I’d say that’s a key element for what we’d be looking for, which I know is hard if you’re just trying to get into the industry. I think larger organizations tend to have more junior and entry-level PM positions so I think that’s a great opportunity for people to pick up those skills. I think for our company that would be one of the key things is just coming in with experience because I think it’s really hard to teach all of those pieces without having the experience.
Suzanne Abate: I mean, Laure, you spoke to your role as being kind of top of the funnel. Acquisition and activation, and that’s traditionally marketing. So this is just another layer of complexity that’s like, you have to understand user experience. You have to understand how to work with developers and you have to know the pointy end of the business, like how to go out and get customers, and that’s challenging. Some people don’t want that responsibility. They want like, “Isn’t there a salesperson for that?” Do you think that understanding growth is an essential part of the new PM reality?
Laure Parsons: I think it really depends on the type of organization you’re working in. Certainly for a startup, I think more than anything else you would need to be somebody who’s very willing to learn all the time and as you mentioned, a good listener, and also have the ability to kind of combine a lot of broad ideas. So I think that growth is a buzz word that people are using but fundamentally the question is, “Can you understand what the problem is that you’re trying to solve, validate that in some way, and then be able to work with a team to come up with a good solution?” I think experience is one way to look at how to have that, but I think another way is just to…it’s kind of like almost a personality type to be a product manager versus something that you could, in my opinion, go to school and learn how to do.
Suzanne Abate: Well, it’s conceptual. I think that’s part of the challenge is that you can come in and you can say, “OK. We’re learning front-end web development,” and there are some sort of finite qualities to that. Of course there’s different skill levels. Product management is kind of tantamount to you’re in an open field and then you have to figure out where you should set up some scaffolding and then what you’re going to build over there and how to organize all these people. Jim talked earlier about using matrices and this is an important part. It’s like it’s just nothing but frameworks and templates and ways to think about thinking, which isn’t knowable in the same way that coding can be knowable or, frankly, even design, which is deeply rooted in principles and philosophy. It’s like, “No. There’s a rule for that.” There’s not a lot of rules for product management, just suggestions.
Laure Parsons: If we could teach someone how to be a great product manager with a book or something, then everyone would make a million dollars every time they did a startup. The reality is that there are a lot of combinations of things that go into building a product that, as you’re saying, are not knowable even if you’re a very good product manager. So I think a lot of the skill set has to do with being willing to be wrong and recognize that and then be able to try something else.
Suzanne Abate: What do you do, Dan, to stay on top of the trends that are out there? How do you make sure that you don’t become irrelevant?
Dan Podsedly: Well, I’ve tried really hard to become irrelevant and I seem to still be here. Events like this are a great way. I admit to being maybe less on top of like, “Hey, what’s the latest buzz and what are people doing?” That’s personality. I don’t want to be told what to do just because they’re doing it and they wrote a book about it and I do have this skeptical view of some of the things that come out. Like there are books written about it. It’s a methodology with a capital L or M or whatever. I mean, I know how that happens. You have some experiences. You go write a book about it. You put a capital letter on it, and now it’s like the new buzz. I’m like, “That works for them. Let me discover my own way of solving the problem with a little bit of input from the outside.”
That’s a little too biased on me figuring it out. So for us at Pivotal, actually the way we keep moving forward is literally the retrospective. Every week for every scope of everything there is a retrospective, and you sort of keep identifying what works well, what doesn’t work well. You look for actions items and you keep sort of…it almost points you in the right direction manually or it sort of triangulates a solution for you if you keep doing it. Obviously there’s a lot of help you can get just from staying on top of it but I don’t obsess about it. I sort of just do what makes sense and let the retros sort of point the way sometimes.
I think, lately, we are more in a culture of questioning every assumption, which maybe if we read a book about lean five years ago, they would have said, “Do that. Do that,” but like, no. We have to find our own way to understanding why we need to really question those assumptions and how to really sort of like test them before going too far, but now we really understand it because we really sort of experienced it and did a few things wrong. So I mean that’s…yeah. I’m a little bit of the, “I’ll figure it out. Just give me some time.”
Suzanne Abate: That resonates with me as well. I mean, we talked with Jim and we talked about sort of being blown about by every wind or that the risk of that if you get too caught up in what other people are doing competitively. I build software products. I helped build software products for people all the time. I’m teaching. I sort of feel that I’m at this…the leading edge of a lot of what’s going on and then I read Fast Company and I’m like, “I’m already irrelevant. I better start looking for jobs. I don’t know what I’m going to do.” So that can be a pressure of everybody is already doing the next thing and we haven’t even read that book yet and how are we going to keep up? So part of staying on top if it is just ignoring it. Right?
Dan Podsedly: To a certain extent, I think. I think it’s a balancing act, of course, but yeah. I’m with you there.
Suzanne Abate: Greg, do you have some thoughts on how to stay current?
Greg Goodman: My resource is Jim. He’s a awesome partner who stays current on a lot of stuff and teaches me a lot of things. I guess my comment would be in a slightly different direction. I think there’s always the new shiny object, especially on the development side of the world. So a new framework or a new tool or a new approach and the engineers in the team can really get enamored with using some newfangled thing. That’s a really slippery slope. I was laughing at when you were talking about refactoring and spending a year or two on a refactor. You know, every company has its life cycle.
There’s the phase at the beginning where everything’s just chaotic and you’re just trying to get something out the door. There’s the little you’re getting a little more mature and you start having tech debt and maybe you don’t have enough tests and there’s a lot of things that you have to catch up on because you were in that early phase where you didn’t do things with really great process and you have to get more process. Then, ultimately, there’s these new technologies that start coming out that you really need to maybe start looking at and I think those are really important conversations and really important that how you handle those situations because those can be train wrecks. Many, many developers want to just throw the baby out with the bathwater and start over and say, “We’ll just write the whole thing over again.”
Suzanne Abate: I know a few of those developers.
Greg Goodman: That can cause chaos so it’s really valuable to be able to allow developers to have a little freedom to make their code as wonderful as they want, but also trying to be pragmatic at the same time. It’s a constant push and pull.
Dan Podsedly: I think one thing that maybe just to the previous point around scales, I think to make the right…because they are judgment calls sometimes, like how far do you invest in this? And you know. Do you just get scrappy? I think you have to have a certain level of understanding, like how software works. So people coming to product management from purely a business and marketing background, I think it can work well depending on the situation and what kind of product you’re building, especially if you are empathetic and if you do focus on the problems and breaking problems down into smaller problems, and taking incremental steps. But these days I think you have to have a certain level of understanding of just like how software works. Everything is getting more complex. You’re not just building one app. It’s an app with a back end, with other apps to complement it, and you’re using all kinds of third-party services.
So to have somebody who came out of school like, “I have a business background in marketing. I’m going to be a product manager now,” without knowing what an API is, for example, like it just…I don’t know how well that works. However, and then it kind of goes back to having a certain level of understanding of like where software development projects do get bogged down and what things do have good outcomes and just how everything kind of hangs together. Like these days, there are a lot of resources. Learning how to be a PM, resources for that are still rare and I think GA is like one of the few that actually give people what they really need to succeed. For every one organization that teaches how to be a PM, there are 50 that learn coding skills. It’s pretty easy these days to find a resource, even online. Just build some little thing and go through one of these code academy basic things.
You know, it’s one thing to be part of a real software project and have that experience, but you can get a pretty good slice through it just by working through things on your own. Like signing up and doing one of these online code academy courses or like find something local where you get to join a team and actually build something. I, at least, have this sort of general awareness of how everything’s structured. That’s a skill. I mean, you can develop that skill. I think people will say, “Well I’m not technical.” There’s no reason to say that anymore. It’s not like it used to be like, “Oh, my God. You have to go to some crazy five, four years of college to understand how software works.” Software’s everywhere. You got apps in your phone. It’s just our world, and so, “I don’t do technical or I just don’t understand coding and whatever,” I think that’s changed and I think that’s something that’s a lot easier to consume now as a skill.
Suzanne Abate: You talk about learning empathy. There’s no better way to learn empathy for a developer than to have to write some code yourself and go, “Actually, it’s not that easy.” I don’t know. We all think software is easy because it’s intangible. So like in the old days for print and broadcast and some of these things where you see a film and video crew roll out, you’re like, “Oh, this is a big production. Videographers and editors and this must be really something.” Everyone thinks that a web product just comes together. We’re like, “Yeah. We have one developer. We’re going to get it done in about three weeks.” It’s like, “No. It’s not going to happen.”
I think it’s fundamental to the communication part as well. That piece, I think, Greg, that you’re speaking about. Knowing how to talk to the different team members also means walking a little bit in their path. You brought up tools. So I want to backtrack. This event is called Product Stack and part of what we’re acknowledging is that there’s the tech stack. If you’re not technical or you say you’re not technical, you should learn about that. That’s not what we’re talking about tonight, but that there are essential tools available to product managers that they can kind of cobble together and each of you represent tools that are or can be essential to the product manager journey. I’m curious to hear from each of you what’s in your product stack where you are?
Laure Parsons: So in our product stack we use, both of the tools represented here and we also use tools that help us talk to customers, like Intercom. We use Trello for kind of like understanding the experiments that we’re working on and the UX stuff. I’m going to punt on this slightly because I think that it’s kind of interesting in talking about tools, that it’s like all these tools have come out of a, I think in some way, a desire to communicate. So one of the things that a product manager, I think this was cited earlier, really has to do well is communicate and you need to communicate with your team so you need a way to track what your team is doing and understand what they’re doing and that’s where tools like Pivotal Tracker come in.
You need a way to communicate about your ideas on a grand level and like the road map and what you’re planning, that’s where a tool like ProductPlan comes in. Then Trello and all these tools really help you communicate. Same with Notion. With the way we built Notion was on the idea that we have…all of us are trying to have this data that we’re communicating with with our team and there’s not a really good way to do that. So I think that it’s kind of interesting that basically most tools around product management really speak to that level of communication.
Suzanne Abate: Well, and if I may offer up transparency, too. I mean, certainly for us in our organization, with Pivotal Tracker in particular and even in bringing clients onto it, which has been a surprisingly successful journey, it’s the need to communicate certain things starts to go away if you can disarm people by going, “It’s all right here,” and they’re like, “Oh. I can see it,” and, “Oh. It’s updated in realtime,” and, “Oh. It’s web-based and it’s available on any device,” and then suddenly people spend less time updating and more time just paying attention and then going about doing what they have to do. What about ProductPlan, Greg? What do you all have going on over there?
Greg Goodman: Many of the same. We use Pivotal, obviously ProductPlan. The things that I would add that probably aren’t a little more subtle. We happen to use GoToMeeting but any form of communication that you can have with your customer, I think, is essential, be it go visit them or online or Intercom for doing chat. I think that’s a powerful channel that if you’re not taking advantage of those on a weekly basis or daily basis, you’re missing half of your job. Obviously there’s the whole team side of things. I already mentioned that Heroku, the review app piece. We’re not mentioning GitHub, but I spend quite a bit of time in GitHub looking at stuff, either reviewing or commenting. We kind of bounce back between Pivotal and GitHub for a kind of communication between stories and things, either in terms of bugs or feedback or that sort of thing. So I’d say those are my primary tools.
Dan Podsedly: Yeah. Not really much to add. I mean, obviously we use Tracker. It would be silly if we didn’t. It’s called Tracker, by the way. It’s not Pivotal.
Greg Goodman: Sorry. My bad.
Dan Podsedly: Everybody calls it Pivotal. Just kidding. We use Slack for pretty much all kind of team communication and just visibility of what’s happening. We post a lot of things to Slack. We have bots for like—t’s not quite working for some things yet, but we’re trying to get to a place where any of the product managers can go to Slack and go to one of the channels and kick off a production deploy. Everything’s just automated so we have CI pipelines built out and Pivotal’s own CI tool called Concourse. So we deploy our production app onto Pivotal Cloud Foundry, which is the PaaS I mentioned earlier. There’s a SaaS version of that PaaS called Pivotal Web Services, which is similar to Heroku. Where we’ve sort of hooked up is like every story has a corresponding feature branch, and then when that story’s finished and delivered, it actually spins up the app on a isolated PWS environment. That’s where you go accept the story. There’s a corresponding poll request in GitHub. Merging the poll request is sort of like one of the final things you do as a product owner now, or PM.
So the PM bounces from Tracker to the deployed environment that’s isolated for that particular feature to GitHub, then there’s Slack kind of interaction with the rest of the team. Obviously ProductPlan for the big picture. Here is kind of where we’re going and why. Google like crazy. I mean, I have a billion Google docs for everything. I use Google Sheets pretty aggressively for like a lot of just internal communication. We do our all hands in everything. Like encouraging the product managers to make decks to explain. They say, “Come on. We have to make a deck?” Yeah, because it conveys the problem and it kind of gets people to have confidence that you understand the problem and you can present it. So that’s pretty much it. Oh. We use Zoom. So Zoom has been surprisingly stable. Zoom’s awesome for kind of like video conference. We use that 10 times a day because our team is somewhat distributed. Works well.
Greg Goodman: We try to record all our customer calls. It’s really helpful for the other people to hear the actual customer’s voice versus just me trying to translate it. So it really helps our UX designer if he’s not in the room or anyone else that’s not in the room that wants to hear about it. So whatever tool you use, be sure you record if your customer says it’s OK and preferably as many screenshots you can get from customers as well.
Suzanne Abate: Do you all have any thoughts on what is the appropriate pace at which to adopt and discard new tools? I heard you talk about, oh, and then a new tool comes out and someone’s like, “Well, we’re using this. Now we’re using this. Now we’re using this,” and there is a certain, however, sort of nimble your team. There is an acclimation process. If we’re going to use Tracker, then this is how it works fundamentally and it is a little different than JIRA and a little different than Asana. At what point does it become too disruptive to say, “We can’t just keep cycling through tools. We can’t switch from Intercom to something else. We can’t go to HipChat to Slack”? Do you all have thoughts about that?
Greg Goodman: We haven’t changed that many tools, actually, so I’d say it’s probably an infrequent thing, at least for us. Maybe on the dev side there’s a little more new technology stuff, but I’d say our tools are fairly stable in terms of what we’re using. We actually are talking about switching off of GoToMeeting and looking at alternatives, which I know Jim would probably be a little bummed about.
Dan Podsedly: Yeah. I think it’s a balancing act always. There’s always a better tool around the corner, but then you’re just spending all your time sort of switching from one to the other. Then when you do, inevitably it’s like you like one, but let’s say half the team is happy with a given choice for a given type of tool and then the other half’s like, “Ah. I don’t like this. I don’t like this.” So then you start to hear more and more things coming up in the retros. Like the same stuff starts showing up in the unhappy column because retrospectives always have an unhappy, meh, and a happy column. So you start seeing patterns, like everybody’s complaining about Hangouts as an example. So OK. Let’s find something else. It’s time to find something else. There’s an action item. Like OK. Zoom. Let’s try that. You try it on a few teams, then you say, “OK. Let’s go with this.”
Then you’ll have a third of the team unhappy with that product, and another third who’s just unhappy with the fact that we changed, which actually parallels this other sort of product management challenge. Like every time we change how something works in the product, you get this flurry of like, “I hate it. I don’t like it. Da da da da. I want to switch to another tool.” Then it’s a week later. “That’s fine now. It’s fine. We like it now.” Just like, it was just different. So I think you kind of get the same sort of thing to worry about every time you try and improve something or change a tool. You’re just going to get this like this mixed feedback until things settle down again.
Category: Community
