Employee Number Nine

Jen: Hi, I am Jennifer Busenbark, and I am a product manager.

Suzanne: Now you're not just a product manager. You up until very recently were the director of product management at a company called Braintree here in Chicago, a tiny little company-

Jen: Tiny.

Suzanne: -called Braintree.

Jen: Yes.

Suzanne: Yeah. Tell us a little bit about how you came to be there, sort of going back in time to the beginning of your story.

Jen: Sure. I started my career in technology a little over 17 years ago. I had moved to Chicago to do AmeriCorps, which is a domestic version of the Peace Corps, and I loved the city so much that I just wanted to stay. My criteria was I need a job that will pay me enough money to pay my rent and my bills. My first official job after that was a temp receptionist at the Wrigley Company, so basically I was just buzzing in executives. The most important thing was to make sure they didn't have to wait at the door, and chewing gum the whole day.

After that, I got a job as a recruiting admin at a company called ThoughtWorks, which is a consultancy out of Chicago. That was great. I just scheduled interviews. I was just trying to figure out what do I do next. I was a psychology major. Then the dot.com bubble hit, and they had to start laying folks off, but they were still building product that needed to be tested, so someone had the great idea of why don't we take folks that we've already hired that we know are a good culture fit, they know about our business, and try to train them on doing manual testing? I was chosen to go down that path. It was something that I had an affinity for. I did that, and then that rolled into being a business analyst, which rolled into then being a what we call an iteration manager, which is similar to a Scrum master, and then a project manager at the end of my career at ThoughtWorks.

Two of the developers that I had worked with on my last project there had started at Braintree. They called me and said, "We really need a product manager. Can you please, please join us?" I said, "You're crazy. I've been here for nine years. I'm really happy. I don't think I want to start at this company that's really tiny. I know nothing about payments," but one evening I decided to take a dinner invitation for a free meal and some wine.

Suzanne: Good plan.

Jen: Yeah and after that meeting, I just knew that I was going to join the company as the first product manager. Braintree really was my first job as a product manager. I'd worked in all other capacities, but I never was really a product owner until I came to Braintree, and that was 7-1/2 years ago.

Suzanne: How big was the company when you joined it?

Jen: I was employee number nine, so I was the first PM, and I think at the time our development team was maybe five developers. We were working out of Wicker Park. We had an office that was one room, and we had a couple remote devs. I think there were three devs and myself working out of a really tiny room out of Wicker Park. Our operations team, which was ... I can't do the math, but I'll say about five ... they were located in Bartlett, which is a suburb of Chicago.

Suzanne: The real startup dream, just one step up from a garage basically.

Jen: Basically and it kind of functioned like a garage. Wasn't very nice but it worked. It was really fun and we did a lot of great work out of that office.

Suzanne: Yeah, I would guess it worked. How many employees approximately by the time that you left, which was just quite recently?

Jen: Yeah, I think that it was approaching over 600. I think also when I left, and I may not be getting those numbers right, the product team ... when I say product team, we considered the product team to be PMs, designers, and development ... was approaching around 300.

Suzanne: Wow. Let's go back for a moment to when you pivoted from recruitment administrator to quality assurance person. You had never tested software before?

Jen: No, I didn't even really have any thought ... I didn't know anything about software. I didn't know anything about development until I started recruiting and learning what are we looking for in a resume. I just had no clue. This whole thing happened, like this stuff went behind the scenes and it was things that I was using in real life, so no, I had no idea.

Suzanne: You said you were good at it. Obviously, you were good at it because the company just kept promoting you into more and more roles that required more and more responsibility and involvement. Why do you think you were good at quality assurance?

Jen: I think what made me good was I just was able to think in a different way because your whole thought process when you're testing something is you want to break it, and I was never satisfied. I wouldn't just clip around a few times and be like, "Okay, this seems to be doing really well." I'd always think of different edge cases, and I always wanted to be very thorough. I'm very detail oriented, which is a good quality for a PM, but I always just dug deeper and went further and always wanted to keep going and going and going until I found the smallest thing. I think that's that attention to detail when you're doing ... It was manual at the time ... is really important.

I think that kind of showed through because the stuff I was ultimately testing goes to production, so if there are things that I'm missing, that's showing up to the customers. I was able to do a really good job of making sure that what we were putting out, of course things will always have bugs, but nothing that was major. I was able to catch those types of things in the work that I was doing.

Suzanne: Yeah, I think quality assurance is a very interesting starting point in so many ways because, to the point of your own experience, whether you know software or don't know software, what you quickly have to learn is use cases and what are the different paths that anybody is going to take. The more that you start building up a database of understanding around different use cases, different paths in and out, different ways to move between modules or features or different ways you might like to, the more you're actually really building an architectural mindset. That once you get a pen in hand or now a software tool in hand, it's actually much easier to start to think about workflow diagrams, wireframes, and some of those deliverables that come from user experience design role.

Jen: Yeah, I think that's a really great point. I also think another thing that it helps you with is prioritization and thinking about that, because you know as a PM, you can take a path where you're trying to design and develop for every different use case that a user might take. The probability of that happening is so low, so you don't want to spend your time doing something that isn't ... kind of like the 80 to 90% of how people are going to use your product.

You see a lot of that when you're doing testing because you go down those rabbit holes and you want to do that as a QA person, but when you then come up with a list of a hundred things that need to be fixed, you very quickly can realize well for me to get to this number 50, I was doing all these crazy clicks and going all around. Maybe that's not as important as this blatant I tried to load the page and it's just not loading. You also get some experience in having to prioritize the types of things you want the developers to work on. That also is helpful when you become an analyst or you become a PM because you already had that thought process as well.

Suzanne: Tell us about the business analyst role as it applied to you. What was the responsibility? What were you really being required to do when you shifted out of QA.

Jen: Yeah, the business analyst role was really working with our customers, which were our clients because it was consultancy, so that could have been somebody who was on the business side of things in the operations teams or it could be the product manager who is working directly with the customers. When you're in a consultancy role, I didn't really have face-to-face interactions with customers directly. I got that through the product manager or product owners that were working with them. Other than that, you're still thinking as you would as a product manager, which is I'm taking all of this information from all of these different sources and I'm trying to synthesize through that and figure out what it is that we need to build.

Because oftentimes, you hear that saying that they may tell you what they want, but you need to figure out what they need, right? Because you want everything. You want all the bells and whistles, of course, but that's not practical. As a business analyst, it was gathering those requirements, thinking through them, figuring out how does this apply to what we're currently building? What is already there? Then working directly with the developers to make sure that they're building what it is that you had in mind. Then just throughout the iterative process, just having conversations with them.

Because a lot of times as well, what you want ... you even want them to build isn't always what comes out in the end because there are things that happened or that are not possible, so playing that role, that was all involved in the BA role that I played at ThoughtWorks, so those are a lot of skills that I gained that applicable to being a PM.

Suzanne: Were you writing user stories back then or was it more like product requirements documents? What was your output to the developers?

Jen: Yeah, it was more user stories. ThoughtWorks was very much early on proponents of the Agile methodologies, and Agile's such a loaded term because it can mean so many different things to so many different companies, but we didn't write really long user stories like document and then hand them over. It was very much cards. Before they developed software called Mingle, which is a card tracker, we would physically have cards on a wall where you would write the high level of what the story was, and then you would just write a doc.

My approach to it was very much giving a summary of what you're trying to accomplish and then I love bullet points, because it's a conversation that you're having with the developer, and you can't capture that all in story cards. Well, you could, but it would become outdated very quickly. It would take you a lot of time, so yeah, I did have that type of output, but it was much more lightweight than maybe the typical kind of waterfall documentation that some companies or BAs produce.

Suzanne: I love that you had the experience of running a manual process for production because I think I see this a lot. People will come to me and say, "What tools should I use for ticket tracking," the real question is: What is the process that you're running with your developers? Tools are great accelerators for a process that's been established and agreed to internally, but they're also a very easy way to get lost in focusing on the wrong things if you don't have the underpinning of what works. You all were just writing on cue cards and then pinning them to the wall and-

Jen: Yeah, yeah. Absolutely. Even at Braintree, we were doing physical card walls until we couldn't anymore. When you start having folks that are remote that are in different locations, it's really hard to have a card wall, but I remember putting up corkboard in one of our offices so that we could do the physical card wall. Yeah, I totally agree with that. The tools ... and you will change over time. We changed over time. It just depends on what your process looks like and what works for you. I'm really a proponent of what is going to be the easiest thing to get to the end state without adding a bunch of process into it because sometimes those tools you have to put in required fields.

It's like do you need those? Are you reporting on those? What's the process? It's like oh, that's just the process. I'm not for that. I'm for what's the minimum amount you need to do in order to make sure you're having those conversations and building the right thing.

Suzanne: That's another really good point is starting to conform your own process around the constraints of the tool is almost never a good idea because that tool was built for a specific type of process that worked for somebody, and if it doesn't work for you, then it does call to the attention do we need this?

Jen: Yeah. It's interesting because we went from when I started at Braintree we were using Mingle. The reason we were using that is a lot of us were from ThoughtWorks. That was the tool we were familiar with, and when you're a consultant, you're also doing a little bit more heavyweight of estimating with the developers because you have to come up with project plans for the company that you're working for and budgets around that. There's a lot more process that goes into that, and that's very fair, but when moving to Braintree, it was way more loose than that. We didn't do estimates.

It was like we know we need to do this, and we all know that estimates aren't always the best thing, but we all know what goal we're trying to get to, so let's not waste time on that. We found that Mingle at the time, it became too cumbersome. It was too hard. I was a little resistant to change because I was just familiar with it, and I think I actually went on vacation and then I come back and the developer was like, "uhh, boozie“ - which is my nickname - "we're using Trello now." I'm like, "What?" They spun up Trello. They found it so much easier to use to put story cards in, and I was like, "Ugh. I'm going to have to move everything over and it doesn't do this, that, and whatever."

Then I came to the fact it's like no, this is actually a much easier tool to use, and we're not really using all of that stuff that I had used in the past. We went from something a little bit more cumbersome to something really lightweight, and until recently, a lot of the teams were still using Trello, but as you get to be a bigger company, we are part of PayPal, there are things that you need to do. You can capitalize software and there are things like that. You need better tracking in place, so the teams have now moved over to using JIRA, but being able to set it up in a way that works for them.

It's kind of interesting we went from heavyweight to very light for a very long time and then now to something that's a little bit more ... You can do a little bit more tracking in it.

Suzanne: You're at ThoughtWorks, first of all, let's just call out this theme that you have. You're a committed person.

Jen: Yes.

Suzanne: You were at ThoughtWorks for almost a decade.

Jen: Yeah.

Suzanne: When you finally made the decision to jump over to Braintree, and then you were there for almost a decade as well.

Jen: Yeah, 7-1/2 years.

Suzanne: When you join a team, you're like, "I'm in."

Jen: I'm in, yes.

Suzanne: At ThoughtWorks, as you described, from one promotion or side step to the next, to next, to the next, to the next, you essentially accumulated all of the product manager skill sets, but Braintree was the first opportunity that you had to pull it all together as the PM.

Jen: Yes.

Suzanne: Do you remember ... I know we have to go back in time ... but do you remember what your experience was of suddenly being the PM? Was it challenging even though you knew all the things in isolation?

Jen: Yeah, I think so, and I think actually the scariest thing for me though moving over was more the domain. Payments is really difficult and really hard, and in being a consultant, another great thing about that is you're constantly moving domains. Really, the most important thing is get the core skills set that you need to actually do software development is really important then just be open to knowing you're going to have to learn different domains, and if you do that, you're great. But the domain was really challenging, and it's also very developer focused. It was APIs and back-end integrations.

We didn't even have designers at that time, so that to me was a little bit scarier, and so I think for the first couple of years, we were focusing really on those depending our back-end integrations and building out our infrastructure. I still didn't really feel as much of an owner because a lot of this stuff was coming from developers because it was such a developer focus, and I was more I felt at the time had more of a project manager, business [inaudible 00:16:56]. All of the other things and not really owning it, but I think as time went on and you start talking to customers and things like that and then you're like, "Wow, okay, now I'm responsible for figuring out what are we going to do with this where the market's going? What's next?"

Yeah, it was little scary because I don't have anywhere to go. When you're a consultant, you know that you don't actually stay at that company. You can move on to another project, but this was like, no, I'm going to have to do this and I'm going to have to actually see what happens when it goes to market. If it doesn't work out, I'm going to have to, with my team of course, figure out how do we fix this and go back. That is a little challenging because you are seeing it all the way through and you have to deal with the failures as well as the successes.

It's also the most exciting part, right? Because when it's good and you do something good and you're getting great feedback from customers, there's nothing better than reading a really nice Tweet or a nice e-mail about it. When it's bad, it's a bummer and you have to deal with that, but you learn from that. You learn from the mistakes, so it's good.

Suzanne: You're a team of nine. You're obviously very closely connected to the founders of the company. Were they also developers? Was it mostly engineers?

Jen: No, actually, the founder of the company was Bryan Johnson. He started the company because he started selling point of sale systems and he realized how the industry was sketchy because merchants didn't know clearly what fees they were paying, things like that. He's like, "I think I can do this better," so when Braintree originally started, what he was doing was being a reseller of merchant accounts to get merchants up and running and white labeling a back-end system and that he hired developers who were like ... We actually need to build our own thing here, because if we really want to be better than anyone else and make it easier for anyone else, we have to have total control of what our product is.

A lot of the product was actually really being driven by the developers, but the founder was not ... He was a business guy, a serial entrepreneur that was just trying over and over again and then this was the next segment that he went into.

Suzanne: In case we have folks listening in who are aren't hyper-connected to what Braintree does and specifically the problem that they were seeking to solve, can you give us just a very rudimentary explanation of how Braintree became different from what was the status quo at the time?

Jen: Sure, yeah. I think there's a couple key differentiators back when we started. The big one was around just procuring a merchant account. How do I get set up so I can sell things online? I don't know how to do that, and how do I do that? Get a merchant account. What does that mean? What are my rates, etc.? We really focused on simplifying that and having really great customer service where we're walking merchants through it and telling them throughout the whole process what's going on and helping them through that.

Suzanne: Specifically for an e-commerce-type application.

Jen: Exactly.

Suzanne: I'm, again, I think it's relevant where we are in the time line of things. People are coming online.

Jen: Yes.

Suzanne: Traditional businesses that have mostly been brick and mortar are starting to understand they need to have an online presence. This is maybe even before everything went to Amazon.

Jen: Yes.

Suzanne: Everyone is turning on an e-commerce website, and then they're like, "How do I get paid?"

Jen: Right, exactly. You have the business aspect of it and helping them walk through that, and then you have the technical aspect of it, because back then, ironically, one of the big players was PayPal. All we heard was, "It is so hard to integrate to PayPal, to take our site…even developers…it was very hard, so what Braintree did was develop APIs to make it really easy for developers to accept payments. We handled all that stuff in the back end, so really you have one integration and then you're set up to be able to process payments.

That was the other thing that separated Braintree at the time. We were going up against the PayPals of the world or like Authorize.net or the banks were the integrations were terrible; there wasn't clarity into the merchant had to pay for their fees, etc. that's what made us really different in the beginning, and that's how ... We actually had a couple of really great tech companies like GitHub and 37Signals that were using us, and then we just grew organically from there. It was word of mouth. We didn't really have outbound sales for quite a while, but the technology was speaking for itself. That's why we got the merchants that we did like the Ubers and the Airbnbs early on.

Suzanne: Yeah, I know. I remember even for us at The Development Factory, we had built a lot of payment gateways for many, many years, and so when Braintree came to market, it was wow, this is really going to change how much time it's going to take to build an e-commerce site for a client, how much we can charge or don't have to charge because we don't have to deal with all of the complexities around. Did you have to market it to developers? Who was the customer in those early days in terms of the value proposition?

Jen: It definitely was developers. It was very developer focused. If you ever went into our control panel, you could totally tell it was built by developers and it was more dev focused because we ... At the time, it was really important to make it as simple as possible to integrate, and we really didn't pay much attention to the control panel, which was the manual ... You could log in online to see your transactions or process a payment if you have that portal rather than having to do direct integration. Yeah, it really was. Even in the beginning, we didn't do a lot of marketing. It really was so organic in how it grew. I remember specifically begging customers to use our gateway when we first came out with it.

Suzanne: Really?

Jen: I was like, "Please, please," and they don't ... You're processing their payments. That's their money. That's their bread and butter, so they're not really keen to wanting to be a beta merchant on a processing platform. I remember writing on our window in Wicker Park with a chalk marker. I bought one when we got our first merchant. Well, actually, I wrote our merchants on cue cards and put them up, and then I started tracking our transactions from one and then 100 and then 500 and then 5,000 and then it's crazy to think about how that growth happened. Lots of stuff happened in between to get us where they are today, but yeah, it was pretty crazy.

Suzanne: Where did the PayPal acquisition happen in terms of timeline? How long were you there before they were acquired?

Jen: I believe it was four and a half or five years.

Suzanne: Did the IPO happen post-acquisition or pre?

Jen: Yes, so what had happened is we got acquired by PayPal. They were part of the eBay family as that time, and I believe a yearish later the split happened, so PayPal then went through an IPO of their own.

Suzanne: What was it like getting acquired? Given that you talk about writing in chalk on the wall, tracking from transaction one to 100 to 1,000. Was it immediately different once you were acquired by a large company?

Jen: No, it actually was not. I have to say when I found out we were being acquired by PayPal, I was like, "You have to be shitting me. This is not happening," because it really happened pretty quickly. You know?

Suzanne: You didn't want that or you were excited?

Jen: Well, that had been the competitor we were fighting against this whole time, right? At the beginning. Of course, Stripe came into play, and they're a fierce competitor as well, but we were just like, "We're going to be better than PayPal. They're terrible. We hear these terrible things about their customer service, etc." When we found out about that, I was like, "Oh, my gosh. No. This can't be true." In the beginning, to be honest, I had a lot of reservations. I was like okay, this is this big company. Their products aren't that great. They're not known for their customer service. How is that going to impact the reputation that we spent all of these years building?

But I think when you do get acquired, one of two things can happen, right? The company that acquires you can swallow you whole. You lose your identity. You lose the ability to control the product that you're building. It just gets wrapped in. Then the second thing that could happen that rarely happens is that you can still control what you build and the culture, and I think that's what happened. In the beginning, there really wasn't a difference. Even still once I left, our product team operates separately from the PayPal team. Of course, there's a lot of cross-collaboration because we're collaborating on a lot of products, but the product team is run separately and we still controlled our roadmaps with input of course.

I think that the company and Bill Ready, who was the CEO at the time we got acquired, who is now running a lot of PayPal's merchant servicing stuff, he did a really good job of helping us protect that culture that we wanted and the way that we worked. I think what happened was that's kind of seeping into PayPal, kind of seeing like oh, okay, I see how they have their team set up. I see how the customer service and how they do things and staffer development, etc. I think some of those things have leaked over into the PayPal world where they're trying to organize their teams in a similar fashion.

Suzanne: How were your teams organized? Tell us a little bit about the construct of the team, how information flowed from either individual to individual or just through the organization.

Jen: It's changed a lot. It changed even every sixish months as we got bigger and problems changed, but by the time I left, how we had organized the development team is into different organizations within the team. Thinking about the product holistically and how to break that up in a way that makes sense. We ended up with an organization that dealt with just payments, where if we want to bring a new payment method to life, if we want to do an additional integration to a banking partner, that organization took care of that.

Then you'd have another organization that would focus on some of our what we call ecosystem stuff, so our marketplace product or our contextual commerce product. Things that are a little bit different than our core processing platform, and there are a few more organizations, but within each organization, you would have leads at the top, and we really bought into this philosophy that the leads ... There's three leads. You have someone who's leading technology. You have someone who's leading the product, and you have an engineering manager who's leading the people aspect of things. We broke it down even further where you would have group level, and then from there you'd have team level.

You can always roll up, but whatever made sense. Each level would have those three leaders that would work as a team together to make sure things were happening and that the people were taken care of, the product was correct, and that the tech was on the right track.

Suzanne: Yeah because I think one of the things that's interesting when you look at larger organizations, the one that you're describing, is how does it make sense to carve up the ownership? How does it make sense to carve up the product? Right? Because I think that's a tricky ... If you are part of an organization like Apple or Microsoft, I think many people listening can readily understand okay, Microsoft Word is a product. Microsoft Excel is a product. We can see that separation clearly. It starts to feel a little bit stranger I think when you think about no, it's not Microsoft Word.

Yeah, there's somebody who owns that product, but then there's actually somebody who owns print or a series of smaller features that live inside the toolbar, and that whole constellation of micro-features has its own product management approach. I'm curious when you start to divide it that way, doesn't it have the potential to create a Frankenstein product where the folks over here who are steering the vision of processing and the folks over here who are steering the vision of reporting, come back together and it's like, "Oh, that's what you all are doing? Our product looks very different"? How do you unify in that kind of scenario?

Jen: Yeah, so that absolutely can happen, and I think there's probably no way around some of that happening when you start to scale as much as Braintree had scaled. I think the way we try to address that is like I said, kind of a ... I hate using the word hierarchy but having different levels of what your scope of what you're looking at is. As a PM at a team level, you really are focused on that one product that you're building, right? You're not thinking about across the board because your goal is to focus on that team, and you would have another product manager that is then focused on multiple teams in making sure that everything that they're building is pretty cohesive.

Then I mentioned the organizational leader, they're responsible for even more teams. It was at that level in the group level where they're communicating with other organizational leads and making sure that they're talking, they're developing the roadmaps together so that there's some cohesiveness across the board. I think also we ran into the problems that you talked about because naturally you try to break things up as to make as much sense as possible, but there's always going to be an overlap with certain products. It's just trying to make sure we have folks that are thinking more big picture and not have everybody focused really deep into the weeds.

By giving them some of that mind space, they can see what's going on elsewhere and hopefully catch some of those things before they get to the finish line where they're like, "Oh, my gosh. These two things are not going to work together."

Suzanne: Can you tell us a little bit about how road mapping worked in that construct? Who owned what? Was there one director-level person who said, "Here's the roadmap?" Was it informed from each of these product teams? Was it more collaborative?

Jen: Yeah, so also changed the way we road mapped over time.

Suzanne: Lots of change.

Jen: Yes. Road mapping is really hard. It's super difficult. I think when we started out, it really was. When it was early days of Braintree, it was me and developers, and we had to figure out what are we going to do and we would just figure it out and do it. We didn't have even a quarter road map or anything like that.

Suzanne: You just put a card on the corkboard.

Jen: It was very much card level. It was great. It was just like we've just got to do what's next. It was very focused on our goal. Then we got to the point where you start building the team up, you start building more leaders. You have additional stakeholders. We built a whole operations team, and each team has their own stakeholder, so we would get leads in a room and we'd all talk about what is developed now, what do we see as coming up, what are some things we need to do for merchants, etc. We would try as a leadership group to come up with what the road map would be. That was really hard because there never really was agreement because you're always going to have this tension between maybe what sales wants versus what operations needs versus what development needs, etc. It felt like we would come out of there, but there wouldn't be a lot of agreement, and then there was a lot of change throughout the time that we're trying to execute the roadmap.

Towards the end, the approach we took was let's start thinking in terms of what are our business priorities and how do they roll up even into Braintree business priorities to PayPal business priorities?

From those business priorities, what are our product priorities? Then taking those priorities and giving those to our PMs and saying, "Okay, based on these priorities, what you know about what your team is doing now, what you know about what we want to accomplish. Come back to us with a suggestion on what you think your team should be working on in the next quarter, some ideas for the second quarter after that, and then anything after that just a bullet list of contenders."

Suzanne: What would be an example when you say product priorities that are being surfaced? Are these more like broad, ambitious goals like improve usability?

Jen: No, they're a little bit more specific than that. I think a good example would be we always wanted to make sure that we're the integration of choice, that a merchant wouldn't want to go anywhere else because if they came to Braintree, they could do one integration and get every payment method they would ever need. They can get PayPal. They can get Apple Pay. They can get credit cards, any alternative payment method and they didn't have to worry about it. That was our product goal is make sure that whatever is happening out in the market and what's coming that merchants we're the integration of choice and there's no other comparison to us.

It's broad I guess, but it is specific because then you have to think about what's coming up. Oh, is Samsung Pay coming up? Is this coming up? These are things we are hearing about that we need to factor into our roadmap so that we continue to be that integration of choice.

Suzanne: In this model that you're describing where some of the executives or the management leads bring to the respective product teams some broad priorities and then say, "Come back with a list of what you're going to do next quarter and maybe the quarter after that," what's the time line here? Let's say that we're asking for these priorities for Q3. When is that list due by? Q1?

Jen: Yeah.

Suzanne: How much time between the list comes in and when the road map gets "published"?

Jen: It depends. Again, road mapping is so hard. It never sticks.

Suzanne: These are the truths we need for this show. It's so hard.

Jen: It is. It never sticks, so sometimes we would be publishing our road map for the second quarter already into the second quarter because things are moving and stuff. To me I think if you can publish something before the quarter starts, that's good. That's great if you have an idea or just kind of broad things, but then maybe firm them up more of where they're going to be, kind of development is going to start is great. We found ourself publishing the road map in the quarter that we were currently working on because once we did that whole process of come back to us on what the teams think they want to be able to do, then we had to coordinate across all the different organizations and say, "Does this stuff line up and make sense based on what we know about priorities?"

Then leadership had to take a look at it and be like, "Okay, seems good" or "Maybe we need to tweak this or that." That whole process takes a lot of time. I think it was the best process that we had had there. I don't necessarily know if I think it's the best process. It's just the best one we had had at Braintree at the organization at that size.

Suzanne: It sounds like, if I can visually imagine this, Q2 that's published is the most accurate version of what we're going to do for the next three months. Q3, which is also there, is a looser interpretation of what we said we would get to after that. Then Q4 and Q1 and on was just a bunch of the ideas that were in the bulleted list with an unspoken caveat that these are highly subject to change both in terms of timing, so at any given time you might see a road map that looked like one year or two years long, but the understanding was the next six months are the most clear and everything after that is just a suggestion.

Jen: Absolutely. I would go as far to say the next three months are clear just because ... and again, it could change based on the nature of your product and your business, but we got surprised by Apple Pay. There's so many things that are happening in the payment space. It's changing so rapidly that we have to be able to react to that. We can say ... I can't even remember the quarter ... but we can say, "Oh, we have all these grand plans." Then we hear oh, Apple Pay's coming out. We need to have that. Then you have to scramble and rework and things kind of fall apart. To say that you could know six months in advance what you're going to do is to me a crazy thought.

It's even more crazy when you try to get pretty granular with the developers in terms of how long things are going to take because you can't ... You don't want to waste too much time going into details of what it is you're going to build and have your developers estimating. You can think you can come up with a really good sense, but they just can't estimate that far out. You don't even really know at that point, so I think exactly how you framed it, which is like we really have a really good sense for this three months, kind of a better sense for the next three, and then that far out we just have things that we think we want to do, but as we get closer, we can continue to do that process of refining what it is we think we can do.

Suzanne: I like your story earlier about PayPal and the early days of the Braintree mission was just like bite at the ankles of this giant. Then it worked. As an acquisition strategy, it's always a good strategy to put yourself painfully in front of somebody else so much that they're like, "This is annoying. We're just going to have you," which it sounds like is in large part what happened with PayPal. I'm curious if you remember how you felt when Stripe showed up? I think today about Stripe and Braintree as being like which one? Why one over the other? Was there a clear moment of who is this Stripe and what were they trying to do differently do you think than what Braintree had been doing?

Jen: Yeah, so I think they have great technology, right? What one of our advantages was was that we were easy to integrate to. Then here comes Stripe. They're also very easy to integrate to, so when you were to compare our competitors like PayPal to us, it's a no brainer. Clearly, we're the winner. When you start comparing Stripe to Braintree, you're like, "Hmm. Both look great. Who do we go to?" Then you start thinking, "Okay, this is interesting." What Stripe did better than Braintree at that time is they made the onboarding process super simple. We hadn't gotten there yet.

We were still focusing on building out our back ends and our reach globally, and we kind of ignored making the onboarding process super easy.

Suzanne: Sorry to interrupt you, but for developers like the onboarding for somebody who wants to leverage the API?

Jen: Yes, I should be clear with that. The onboarding if you want to get a merchant account, so you're brand new to the game before you even start the back-end integration to actually hook up your website to the APIs you have to be approved. That's a whole process that has to happen. They automated that and made it very easy, and we were collecting online but there was still a lot of manual intervention in order to get merchants improved so we could be like, "Oh, yeah. You're good to go. Hook up and start processing." They did that really, really well, and they simplified a lot of things. We were really behind the eight ball.

That's when we woke up and we're like, "Oh, this is a serious competitor here. We have to be paying attention." That's when we started scrambling and going into overdrive. It's like, "Okay, we really need to focus on this thing." It was a little scary because you're like oh they're coming out of the-

Suzanne: They're biting at your ankles now.

Jen: Yeah, exactly, and they're doing a really great job, but it also was really good for us because I think for a little while, we kind of cornered that space. Having competition is actually really good because then that gets you ... You can't become complacent. You have to always been innovating and thinking. It was good for them to come into play for us is that we started to review and had to keep pushing things forward.

Suzanne: You were there at Braintree for a while. You left recently. Was part of the reason that you left just because it wasn't the same thing that you signed up for? I know seven years is a long time of change, but was there an element of I don't like this size of company; I don't like this scale anymore?

Jen: I think there was an element of that. I think the biggest thing for me is I got too far away from executing and delivery of software. I feel very comfortable in being close to the product and having a say. I had a say, but we had PMs that I worked with that actually were working with the developers day to day and getting in there. I feel like I got really far away from that, and I really wanted to focus more on execution and on delivery. That's probably the main reason. I think also the size. I think I found when I look back at my days at Braintree, I think it's a wonderful company where I was the happiest in what size the company was.

We had our hundred plus or our development team was fairly small, less than 50. It was fun and I felt like I was part of a lot of things and I was part of the execution and delivery. I really liked that, so those are probably the two biggest things, the size definitely and then also just wanting to focus on product more than some of the other stuff that starts to get in the way once you scale.

Suzanne: When we talk about startups, I always think it's interesting when I talk to companies that are a startup of 80 people of a hundred people because there's a certain amount of scale not necessarily from what the business is doing per se but certainly from how it's been operationalized. Given that you've been at a startup of nine and then watched that go from nine to 20 to 50 to a hundred, where in that spectrum do you think that you'll be most happy? Is it at the higher end or would you go back to the grassroots garage-type lifestyle?

Jen: I would go back to the grassroots garage lifestyle with a caveat: with a very good leadership team or very good leader. I don't know if I would be happy with someone who's maybe a little bit more inexperienced who's just starting something up. If there was a good team in place, I definitely think that that would be something I would go back to. I think where I'm finding I do like maybe a little bit more established company where there's need to grow a product team, that the development team isn't that big, so there's some need for organization there. You have that opportunity to still be part of that growth, but there's also some stuff that is already started that you don't have to start from the very beginning.

Suzanne: One of the things I love so much about your story, Jen, is well, first of all, for anybody listening who is thinking about product management but has zero experience, it's such a great example of how you can get to that center, right? By building up these ancillary skill sets as you did by making the leap eventually. Wondering if beyond just your story do you have any advice to our listeners who want to get into product management who might be working in one of these adjacent roles or coming at it from a completely different discipline? How can they begin to affect that change?

Jen: My best advice is I know it's really tough to break into product management now. I think that the discipline has changed so much over the years. Back when I started, even when I started in tech when it came to even project management, there wasn't a degree in ... a study. There wasn't classes, and I think that has developed so much over time. I know it's really hard to bust in without experience, and my best advice and I think some of the best PMs that I've seen have come from those other disciplines where they know the customers, they know the product.

I say if you're in a role right now, try to seek out the PMs in the company. Try to even seek out maybe your manager and say, "Hey, this is something that I'm interested in. Is there some things that I could do in addition to the work I'm doing now to give me a little bit of exposure there?" Hopefully, the company wants to see their employees grow and they have a path for you to do that. I also think even within the role that you have there are skills that you can gain that are really important to product management, right?

You can take on maybe a side project where you're the project manager of it and you're gaining those skills. Or doing a little bit of analysis or something like that. I think finding ways within your current role and then hoping that you can expand and dabble a little bit in the PM role in the company that you're at is a really good approach because it's also a little safer as well, right? That's my best advice for folks that are interested in PM. Then just get out there and talk to folks and go to your meetups and start meeting people and planting seeds in their minds. Maybe if something comes up, a more junior role, they'll think about you for that.

Suzanne: You said earlier in our conversation that you were detailed oriented and that makes for a great quality of a PM. I think to build on what you were just saying in your last answer, there's a lot of skills, hard skills that you can go out and learn, learn how to be an effective project manager, learn how to do quality assurance like you did. Are there some softer qualities like detail oriented that you think are essential to have or get good at in order to succeed or thrive in the role?

Jen: Definitely. I think one of the biggest ones is you need to be able to get buy-in from a lot of different people on the direction you want to take the product. You need to be able to influence them and that approach is going to be different depending on who you're talking to. If you're talking to executives, their interest and where their mindset is is different than if you were talking to somebody who is maybe on customer support. Their perspectives are different, and so being able to really effectively communicate with different groups of people, really understand their position on things and bring them along in the journey, is super important. I think maybe the most important skill that you need to have as a PM.

Because in the end, as a product manager, your job is to ship amazing product, get it out there, and get users using it. No matter how you get there, how you bring people along, that really is your end goal. If you can do that, you can talk to all these different audiences and get buy-in, and some may not like the approach. Some might really like the approach, but it's really telling that story, bringing them along and then getting a great product out where everybody's happy is a really important skill to have. There's some finesse in that too. You learn over time, but that's probably something that I think is the hardest to master and the most important.

Suzanne: What about hard lessons learned on the job? Do you remember any difficult moments in your own career where you thought, "Well, that wasn't great. That didn't work out as I hoped. I don't want to make that mistake again"? Either your own or that you saw in other PMs as they were coming up under your leadership.

Jen: I think there's probably a couple lessons learned that I have. When it comes to products specifically, I am not a fan of MVPs however you define them. I'm just not a fan because in my experience was, especially in a company that's growing super fast, we're always moving to the next thing, so this MVP is not really something that we were going to iterate on. We did that few times where we developed something; we put it out there; and we moved on to the next thing. Also, there was something in that around how we organize our teams that we needed to fix, so oftentimes we'd have this product in, it would be something that it would just get traction. Then it was like but that's not really what we intended that thing to work for.

For me, if you're going to put something out there, you need to make sure you're prepared to spend the time to iterate on it and make it what you really want to make it or kill it. If you don't do one of those things, it just builds up over time and when you get bigger and you're doing more things, it's always going to come back to bite you. That's a big lesson learned for me is be very thoughtful about what you're putting out there, and just be careful because you have to make sure that you spend time on it or you kill the product. I had a lot of those, also a lot of building specifically for merchants, our customers where it was a bigger merchant. They wanted something. We were like, "Okay. They're a big merchant. We have to do this for them."

It would suck up development resources. We would put it out there. They may or may not use it. They use it for a little bit and it goes away, and it's like we should have just said no. Be comfortable saying no. I wish we would have said no more. Then I think the third one is don't forget your teammates. Don't forget your operations teams. You can't focus solely on your customer. You really have to make sure that you're looking at all of the business and making sure you're building products that they can one, support, but the tools for them to be able to support the products that you're building.

Suzanne: What do you love about product management?

Jen: Building. Being collaborative, solving really hard problems, and building something with a group of people and getting it out there and having customers use it and love it. There's nothing more satisfying than that. I think being able to se a team, a really well-oiled ... it's like a well-oiled machine ... a team that you have just the collaboration and seeing them crank stuff out and build great, beautiful things is just so satisfying.

I think product management is the hardest job. I'm biased of course, but I think it's the hardest job on the development team, but it is the most regarded because you did that. You made an impact on people's lives. I think from my Braintree experience, you think about payments, and that's definitely not a sexy industry, right?

Suzanne: Well, maybe some think it's sexy.

Jen: Yeah, maybe some, but what was awesome about it is that we were enabling companies that were changing industries. We enabled Uber. When I started and Uber was processing on Braintree, no one knew about Uber. I was able to get a limo on New Year's Eve for like $13.00 or something. It was ridiculous because no one was using them. It wasn't there. Airbnb when they had first started out, you could just see these companies who are so innovative and you could say, "Wow, we built back-end code and product that enabled their businesses. That's a super powerful thing." Being able to see the impact you have, your products have on people is really satisfying.

Suzanne: That last point I think is not to be overlooked because Braintree is a great example of the kinds of technologies that did and are leveling the playing field in so many ways, right? Many of those organizations that you described wouldn't have been able to get to market as quickly, gain traction as quickly, fund or even bootstrap in cases without tools like that. I'm glad that you bring that up, and the other thing that I reflect on as you describe is yeah, PMs are awesome.

A lot of why we do this show in particular and why we choose to seek out great product people like yourself to talk to is because there's enough shows available where the CEO gets interviewed. Everyone wants to talk about the CEO, and yeah, it's hard to be a CEO and that's a big deal. It can come with a lot of glory as we're seeing, speaking of your friends at Uber. It can also come with a lot of critique. There are tremendous people out there, thousands of tremendous people out there that are fighting this good fight for great products all day long, so...

Jen: Yeah, the PMs bring those ideas to life. I think part of being a PM, there are some PMs that maybe focus a lot on long term like okay, let me think strategically about where this project is going, which is a lot of times in smaller companies what the CEOs and the founders think about too. There are PMs that are really great at that, but there are also PMs that are getting shit done. There's strategy in that, and that's super important. I think oftentimes they get forgotten about because exactly what you said. You talk about the founder of XY&Z Company. Well, how did that idea get built and who is behind the scenes?

It's very much a good parallel to what Braintree was, which was behind the scenes of an enabling companies to focus on their core competencies. That's I think what PMs do is enable companies and dev teams and CEOs and businesses to focus on core things as they get stuff actually done and out to the market.

Suzanne: Cool, are you reading or watching anything interesting that's helping you continue to grow as a person, as a product manager that you want to share with our listeners?

Jen: Not product-focused stuff ... but I listen to a lot of Tim Ferriss podcasts. I even listen to Tony Robbins, which seems a little weird. It seems very self-helpy, but he interviews a lot of really great leaders, for so me, I was more interested in hearing about what is a great leader and trying to pull nuggets from some of those podcasts. That's the stuff that has really interested me lately. There's a lot of really great interviews on there, so that's what I've been focusing on.

Suzanne: Yeah, I think that's great. We have to remember there are so many great product books and product articles as you describe. We have I think a bunch of them at 100ProductManagers.com, and we can't just be only ever learning about product. We have to remember to grow as individuals. We have to remember too sometimes the best insights come from discoveries and topics that are outside of the core of what we're living and breathing every day.

Jen: Yeah, exactly.

Suzanne: All right, last question for you, Jen. Is there a side of the mug quote that defines who you are as a leader, who you are as a person that you want to share with us before we go?

Jen: Sure. It's a simple one. I think it's a twist on the golden rule, but I just say, "Don't be an asshole." If you always abide by that ... I think if more people abided by that, the world would be a better place. That's kind of my motto.

Suzanne: Amen.