Product Talks with Justin Bauer - ProductFTW #38

For our fifth post in the Product Talks series, we’re talking to Justin Bauer. I met when Justin founded a startup backed by Mucker Capital, which has backed two of my companies. I think his journey from CEO to product leader is an interesting one. If you want to get advice from Justin, he encourages you to reach out!

Matthew: Hey Justin, I appreciate you taking the time to do this. Let’s jump in with the classic: who are you, and what are you currently up to?

Justin: My name is Justin Bauer. I’m the former Chief Product Officer at Amplitude. I left at the end of last year after spending eight and a half years there. We scaled from a handful of engineers, Series A, and $1 million in revenue to $300 million and went through an IPO.

Right now, I’m prioritizing things you don’t prioritize when you’re at a fast-scaling startup—time with family and friends, getting back into shape, and traveling. I convinced my wife to take the summer off as well, and we traveled to Europe with our four-and-a-half-year-old.

Now, I’ve started to focus on advising companies. I work with early-to-mid-stage SaaS companies and help them think through how to scale their business, scale their product, and scale their team. It’s been really fun; I’ve been really enjoying it. 

Matthew: That’s awesome. Let’s go back to the beginning. How did you get into product in the first place? What did you study at university, and what was your first product job? What’s the story?

Justin: For my undergrad,  I went to Carleton College, which is a liberal arts school, and I did not think I’d go into product. While I was there, the computer science program was nearly shut down because they said it was "too vocational." Thank goodness they didn’t because it’s now the number one major at the school. Back then, though, the number one major was economics. I took a bunch of courses in economics and mathematics, and I kind of thought I was going to be a professor. I thought I should get my Ph.D., but before I did that, I decided I should work with other people who have their Ph.D. first. So that’s actually what got me to move out to California; I got an opportunity to work with Daniel McFadden, who won the Nobel Prize in economics in 2000. He had just started with this firm out in San Francisco. So, that was the first step in the direction of product, just being in the Bay Area. Unsurprisingly, when you’re in the Bay, you get surrounded by a bunch of people working in tech, and so that’s kind of what piqued my interest. But I didn’t really have the skill set to work in tech. Like I said, I was mostly an econometrician. So, I decided to go to business school.

In business school, I learned about the Product Management role and thought I might be good at it, so I applied to eight different internships that summer. And I didn’t get any of them. Every single one of them said, “You don’t have any Product Management experience.” And I was like, “Well, yeah, that’s the point.” I  did, however, manage to get an internship at Yahoo on their Data Science team. This was back when Yahoo was actually a thing. But that experience just confirmed I didn’t want to just be a Data Scientist. So I did what a lot of people do when they don’t know what they want to do after grad school—I went and worked at a management consulting firm. And, funny enough, McKinsey is actually where I got my first PM job. 

Matthew: What is product management at McKinsey, though?

Justin: So, I think I was the first-ever product manager at McKinsey. I haven't met anyone else who had built product beforehand. I did the typical consulting stuff while there, and we had this one client that we had built this pricing algorithm for. Six months later, we checked in on them, and they told us that things were going great, but the pricing algorithm that we had built them wasn’t working anymore. We were like, “What do you mean it doesn’t work? It wasn’t supposed to be working after this long, it was supposed to just be a proof of concept.” I built it in Microsoft Access. They told us that they were using it to run their whole business. And the partner was like, “Hmm. That’s interesting. I wonder if we could actually build software to help companies think through how they manage pricing.” And so he raised a couple million dollars from the heads of McKinsey, and we used that to basically pay for me to be a “project manager” and work with a small software agency to actually build pricing software. That became Periscope Pricing, which is still a standalone business unit. That partner eventually became the CEO of that, but I think he’s now gone back to being a full-time partner at McKinsey. 

But yeah, that was my first experience really building software, and it completely changed my view on how to create impact. Instead of creating PowerPoint slides to try and convince people to try and change how they work, I could . build software that could actually change how they operate and how they work within their business. It’s so much more scalable. 

Because of that experience at McKinsey, I got placed on a bunch of digital projects. Not surprisingly, all of the partners still wanted to do PowerPoint presentations and whiteboarding, and I was like, “This is not how we should design software. Let’s actually work with customers, build some things, and see if it works.” It was too early for McKinsey to figure that out, but one of the partners of McKinsey who had left to go be the CMO of Sports Authority was like, “I want to start a digital consulting company that does that.” I thought that sounded awesome, so I actually joined him. It was called Axon, and we ended up selling it to Booz. It became Booz Digital, and then they went and started BCG Digital. After that, every other consulting company had to create their own digital arm. 

So that got me into building software, and around then, I met Will Hsu from Mucker and I told him that I wanted to work at a startup. But he told me that no startup would want to hire me because I would be too expensive and I had no experience. He told me that if I wanted to work for a startup, I should go and start my own company. So, fast forward four years, and I ended up building this app for fun. It was a game, and we figured out that we could potentially monetize it. I ended up joining forces with some friends, and we ended up joining Mucker, which is when we met. 

Matthew: Yeah. I remember talking to you about it. I remember it had to do with sports betting or something. I was so confused. But, it was obviously at the start of a huge trend.

Justin: Yeah, we got that timing right. The big learning there, which may not be as relevant for the product audience, is that when you’re in a sin industry like that, you can’t build it in the traditional lean startup way. FanDuel started by raising a couple of million dollars and then went all the way up to 60 million. You could do that because, in those industries, people will throw a lot of money at it, and then all the economics of our business flips on its head. We went from being able to acquire users at $2 and then went to $10 overnight. If you’re in the sin industry, you have to capitalize a lot and change your approach to how you build. 

Matthew: I think also—there’s always timing, right? Like, that was in 2013. I had started Wallaby in 2012, coming straight out of the financial crisis, and you know, Facebook was figuring things out; that stuff was cheap. Everyone’s acquisition costs were cheap for a while. There was this era of, it’s cheap to do a startup, and now you’ve got AWS coming on the scene doing interesting stuff. Although, Wallaby, for security reasons we couldn’t do AWS because you couldn’t get a PCI cert. And Facebook was cheap, and that was all great. And then all of a sudden, everyone’s piled in, and now everything, including people, is crazy expensive again. I mean, one of the things I used to say to people who think startups are so much cheaper because of Amazon is, “Have you tried to hire a software engineer lately?” There is still a limited supply of some things, and I think you’re right; we talk about this a lot in fintech stuff, that you can’t apply lean to everything. There are certain industries where it doesn’t work. Like, you have higher compliance costs in something like gaming. You can easily burn hundreds of thousands of dollars on lawyers doing certain things. 

Justin: Exactly. That was definitely a big learning for me that you can’t apply lean to everything. But that experience was great for me because that ended up teaching me a lot about what it takes to build and grow a mobile app. So, after we sold Rivalry, I was having conversations with some analytics companies, including Amplitude, and that was a market that I deeply understood and I hit it off with the CEO. So, as much as it looked like it was a risky bet, I had a lot of confidence in the market and knew what we needed to do to win. I also felt like they had really built the right initial team to win and to build for scale. 

Matthew: That’s such a great story and a really interesting arc. It’s very different from some of the other folks we’ve been talking to, which is what makes this series so fun. Like you said at the beginning you were trying to get a product management internship. How did you know, or what made you want to be a product manager? And what did you think it meant, if you can think back to that early stage of your career? 

Justin: So, I think I’ve always been a builder. I’ve always loved building things, whether it was building model cars when I was a young child or trying to build businesses when I was eleven or twelve of, you know, stuff like lawn mowing, baseball card business, stuff like that. I even tried to buy some real estate in the middle of rural Iowa. Whatever it is, I’ve always been wired in that way. I didn’t know what I would build, but whatever it was, I always enjoyed that. Even when I joined McKinsey, I actually joined to help build the analytics practice. 

It’s always been important to me. So, I didn’t know what product management was when I was an undergrad. Like I said, Carleton was so academically oriented. But once I came out to San Francisco and was part of the tech scene, I think that was when I discovered it. I saw it as a part of the triad of builders and certainly was the one that my skillset most lined up with. I had taken a handful of computer science courses, and I know very basic levels of coding because of my statistics background. We had to do some stuff in python, but I’m certainly not a software engineer and actually didn’t know much about the world of design back then. 

Matthew: Nobody knew much about design back then.

Justin: Yeah, so it’s kind of interesting because I look back, and I see that I love the research part of product management. It’s probably one of my favorite parts, just talking to customers, talking to users, and for someone in design, that’s a real super skill for them. So, all of those things kind of led me to realize that if software was the thing that I wanted to build, then product management seemed like the right role to at least explore. 

Matthew: So now that you’ve gone from that to both having been a founder and this scaling Chief Product Officer role, if someone comes to you and is 22 and wants to know what product management is and what it actually means, how do you describe it? What does it mean to you?

Justin: To me, it’s really the intersection of using technology to deeply solve customers' problems in a way that is financially viable. You’re the intersection of all those points. I think most people, when they think of product management, they just think about the technology piece. They think it’s about getting to come up with cool features. And the reality is, honestly, you shouldn’t be the one coming up with the features. For me, I felt like I have been great at being very clear in stating what the problem is that we’re solving and prioritizing the right problems that, if we solve them, would really drive the business forward, and then setting up environments where we can then collectively figure out the right solutions to actually accomplish that, without dictating those solutions. I think the industry has evolved now; that is how people talk about it. That would be the first thing for me. Therefore, I’d be like, go spend your time figuring out how to get good at doing that, which is a little different than even five years ago, when people would tell aspiring product managers to go take a coding boot camp or go learn how to code. You don’t need to know how to do that. You need to know how to speak to engineers and empathize with them, but honestly, if you are good at understanding customer problems and prioritizing the ones that will drive the business forward, engineers will love working with you. They hate building things that no one uses and don’t make money. So you need to get good at that. 

Matthew: I think that’s right on. I spent a lot of time talking about problem identification as well. You sort of answered one of my next questions which is what advice you would give to new product managers, but maybe I will pick up on your thread about coding bootcamps. There’s often this discussion of how technical you need to be to be a great product manager or what kind of background you need; where do you come down? You said you have a kind of semi-technical background, certainly math oriented. So, how do you think about some of your favorite PMs who’ve worked for you? Or, again, the advice: what would you tell people about needing a technical background or needing a math degree? How do you think about that? 

Justin: I think it depends on the customer you’re building for. This might be a little bit more B2B oriented. But in my opinion, in B2B, since your job is actually going to be interfacing with those customers, it’s more about how technical they are and not about your ability, like how technical you’d need to be to work with engineering. For example, if you’re building a DevOps product, then you need to understand the DevOps industry. If you’re building an analytics product, you need to understand the analytics industry. And so the fact that I have an analytics background certainly helped me understand the analytics industry, but I had plenty of PMs who came from lots of different backgrounds. I actually found, honestly, that I ended up having to spend more time training people on how to become a PM if they came from an engineering background because they were so solution-oriented. They would allow themselves to get into the weeds in debates that they really shouldn’t versus some of my best PMs, who had a humanities or psychology background. Which, if you think about it, a psychology background is honestly perfect for being a great PM because you understand the user and the customer. That’s your primary job. I can teach you the business fundamentals, but if you’re ingrained in the user, that’s a really great foundation. But, if you are building deep infra for generative AI, you’re probably going to need to understand how the space is evolving, so it requires a little bit more of a technical background. But like I said, it really has to do more with your customers than the product itself, in my opinion. 

Matthew: I agree. And I have similar experiences. So, maybe with this is the next set of questions, we’ll lean on your recent experiences at Amplitude, but you can drive from anywhere. What was one of your biggest challenges as a product leader? This is the interview question. What’s something that sticks out? Like, this was super hard, but we found a solution. It could be prioritization, it could be team dynamics, whatever. Anything is fair game. 

Justin: I think the hardest thing for me was probably when we went multi-product. I think of a couple of key pivot points in Amplitude’s history. The first one is when we joined, and we figured out the ICP, to focus on product management. The second was how we figured out how to go after enterprise, and then the third was when we went multi-product. The multi-product one was very hard. All of them had their difficulties, but I think I underestimated how difficult multi-product was going to be because of how much it changed everything. It’s not just figuring out a second or a third product to build, which is hard enough. It completely shifts the go-to-market team and how they think about the world. So, a lot of the learnings I had there were around me not spending enough time understanding our go-to-market, and how it worked at that stage, to then think about how we were going to sell through these products when their incentive structure was not aligned at all, because they’re just trying to hit a revenue target. 

I can give you a specific example. We built this experimentation product, which has done incredibly well. Initially, when we were building it, we thought we were going to target large enterprises. Then I thought we needed to pivot because they weren’t moving fast enough, so we went after mid-market. That pivot was right, and we ended up seeing a lot of traction – something like 10 or 15 companies that were signing LOIs for us. We thought, “Great, this is awesome!” and even moved up the launch date because there was so much interest. So I handed it over to the team that does all of the sales training, and we helped them out and I just assumed that sales training would go great. We had the launch, and then a bunch of customers started asking about us, and we realized that we didn’t train the right people. We trained the salespeople, but salespeople at that time didn’t handle expansion on mid-market; it was actually customer success that did that. But we only trained the sales team. So, the CS team was not ready, and it was a disaster. Had we not had so much proof that this was going to be a successful product, there’s a chance that if you just looked at how it did in its first quarter, and that was the only thing you saw, you probably would have thought we should kill the product. But the reality was we ended up figuring it out. So that was a big learning point for me.

Matthew: That’s an interesting point at the end, knowing when to pull the plug and when not to. How do you balance this lean startup, rapid change, and pivoting while growing with the conviction that there may just be issues with the execution, messaging, or go-to-market strategy? I think that’s such an amazing question.

Justin: So, one of the things that I do for that, is I try to minimize the number of handoffs that could risk the execution. So, for example, I learned that I’m going to have the Head of Product for any of these new products that we build sell the first 10 or 15 deals themselves. I actually learned this through the experiment example because I was able to do it. The Head of Revenue told me that our product wasn’t selling that well, and I didn’t understand why because we had so many LOIs. So when we launched our next product (CDP), I did the same thing; I had the Head of Product go out and do all of the initial deals. And that’s what gave me confidence that there was demand for this. Obviously, that wasn’t scalable, and it was a very hard quarter for him because he had to do both product and sales. But then in the next quarter, when we did do the handoff, we went from signing 15 customers to signing 3 customers. It just speaks to how hard a sales job is, Amplitude had an amazing sales team. Since we had signed so many deals ourselves, I knew we had fit, and I knew we had the right solution and that it was an execution thing. So then, that gave us the time to figure out the execution side versus if I had just built something with a couple of design partners and handed it over the fence, and then we only sold three in the first 6 months. Then, it becomes a fight between me and the Head of Revenue. I never want to be in a position where I feel like I’m advocating for what my hat naturally advocates for because then everyone would just assume that I’m advocating for it because I’m the Head of Product and I’ve spent so much time on it. I actually want to have an unbiased view. So, that’s one of the ways that I think about how I can have that. 

That actually helped us shut down another product, where the Head of Product only got us three customers, and we couldn’t get any more after that. If you can’t sell it, as the founder of this product, I guarantee you that an AE will not be able to do it. 

Matthew: I think that’s a really good lesson. We talk to zero-to-one startups about founder-led sales, and also how to scale that same methodology further along. It adds to the ability of the product leader to get rapid feedback on the nuances or tweaks that have to happen to get to a real fit. I think there’s a tendency for product managers to think that they’re just building software, but Product is a much more expansive job. To me, a true product manager understands the go-to-market and channel education, customer success, and operations and owns the whole thing. You need to know how all of the things come together because you can build cool software, but if you can’t support it, then it doesn’t exist. 

Justin: Exactly. We really encouraged PM as GM mentality, I think PMs need to adopt it. You always hear, “The PM is the CEO,” and the reality is, it’s not; you’re not everyone’s boss. But the mentality of being a GM, I think, is the right mentality. I think we will see that a lot of great GMs are going to come from PM backgrounds. Traditionally, GMs have come from sales backgrounds. I think in B2B, you’ll see a lot more coming from the product management background because they can take a more holistic view. 

Matthew: Did your PMs own the P&L?

Justin: No. They didn’t technically own the P&L, but when I think about the new products, that was all we talked about was the number of customers and the amount of revenue. I think you actually need to think very carefully about those targets on product people. I actually don’t recommend ARR being the right target when you launch a second or third product in the very beginning because it’s a lot easier when you have an existing customer base to do bespoke software consulting-y stuff to close a couple big deals, and it doesn’t scale. That was the challenge with the prior example we shut down, the PM was able to get three deals done, it was actually a lot of ARR. All three of them were multiple  $100k ARR deals, and we were like, “This is great!” But it was too bespoke to those customers, it didn’t scale and we couldn’t get any additional customers. So that’s when I realized that the number of customers was the right thing at the beginning. Then, eventually, you get it to revenue. 

Matthew: I mean, I don’t think I want to go down this rabbit hole right now, but that’s a whole other discussion about the challenge in early SaaS product, of customization and the best practice or best way to do things. I spent some time in consulting as well at Deloitte. They did a lot of custom SAP implementations, and we were constantly adjusting how the software worked to try and fit someone’s business process, which was always a disaster, frankly, and cost absurd amounts of money. The reality is that you should build a best practice piece of software and tell business people to adjust how they work, which nobody really likes, but people are way more flexible. I’ve seen a lot of companies where they have a unique feature of some sort for every customer, and it just becomes completely unsustainable and unscalable every time. Then, suddenly, you can’t build new things anymore, and you turn into a giant tech debt management shop, and it’s no fun.

Justin: I agree. For Amplitude, that was our MO. We were building for the future of what it looks like to use data to build products. But I will say, the downside of that is that if you don’t have a leader at that organization who knows how to drive that change management in the company, your software will fail. To pair with that, I think we were late to the game in building out the services side for when we went after enterprise. It worked great when we were just focused on tech because everything was happening in tech. We saw early wins with companies like Ford and Burger King, who had leaders come in from Uber or Microsoft and changed the way they operated. Amplitude took off, and they became multi-million dollar customers. But then you look at the exact same industry, and we had customers like Honda, who churned out after being a $50k customer for two years. The software was exactly the same; it had everything to do with the fact that, for whatever reason, Honda just didn’t have the change management program in place. So, at some scale, you need to take control of that as a software business and either build it yourself or partner with a bunch of service organizations that can drive that change. 

Matthew: Yeah. All right, I’m going to shift gears up a little bit. I have one last really interesting question for you before we get into some lightning-round-type questions. So, one of the biggest challenges is being the Head of Product at a founder-led company and figuring out the dynamics of balancing who is responsible for the vision and roadmap decisions. It’s tricky when founders have, and you know this because you have been one yourself, kind of have a special authority. How do you think about the role of a CPO in a startup where you have that unique dynamic of having a CEO who might think, “I’m the Head of Product, really. I make the decisions.” Maybe you haven’t had this experience, or maybe you’ve experienced it somewhere in an older, more professional organization. 

Justin: I think you have to be really clear on what everyone’s roles and responsibilities are. For the CEO, I think about the company vision, like what kind of company we want to build and the company strategy. My mental model was that the CEO and I kind of shared the product vision, but he’s coming at it more from a company strategy like, “Where do I think this industry is going?” And I’m thinking of it more of like, “ What are the core problems and underlying trends within technology that I think will allow that to happen?” But the product vision, I think, has to be a melding of the two. I don’t think it works if you have a CEO who completely owns it and a PM who just executes. I also don’t think it works the other way where it’s a PM who has a different vision than the CEO; that won’t work either. That’s kind of the messy middle, but it should be messy. I think it’s a superpower when you get to have multiple brains that are really forming that vision. 

On the execution side, I think that really does need to sit in the world of the Head of Product. But that doesn’t mean you should shut your CEO out. You want them to be part of that, but you’re having conversations around product strategy with them. At the end of the day, as a Head of Product, your job is to articulate the product strategy and then figure out who is best to execute it. 

I think another piece of advice I would offer, and maybe this is a little bit more founder-specific, but you need to design yourself around the intricacies of the founder. Spenser (CEO and Co-founder of Amplitude) is incredible at finding out what the most important thing we need to be focused on right now that will drive us forward over the next 6-12 months. Once he figured out what that one thing was, it was going to get fixed. He would drive it with an urgency that you have never seen before. And so, every once in a while, that was in your area. And I saw execs that failed when they took it personally and tried to manage him. For me, when it was in my area, I just recognized that, “Yeah this isn’t great, and it is super important.” I almost thought about him as being a super IC PM. I remember when we were working on a new pricing plan, he told me that our first-time user experience was just not where it needed to be. And I completely agreed. We hadn’t been focused on it, we’d been focused on enterprise and multi-product. So, the first step was to acknowledge it. And then he wanted it fixed right away. So I paired him up with one of my top PMs, and then I encouraged him to just do what I would have done otherwise, which would be to spend a lot of time with the team to fix it. It worked perfectly because I didn’t have to be in on any of the meetings, and then in our 1:1s, I would check in on how things were going. I was coaching the PM he was working with on the side, but that was the right way, in my opinion, to work in that kind of environment. When Paul Graham wrote the founder mode paper I kind of chuckled, because to me  that was theway Spenser always operated. You may not have a founder that’s like that, but the point is that you need to figure out how they operate, and then you kind of have to mold yourself to them. 

Matthew: That’s great, thank you. All right, so you’re not running a product org today, but let's say you are starting somewhere new, and you had to. If you were designing from the ground up, how are you building software? Like, what methodologies are you using, or are you doing your own thing? What are your favorite tools? Imagine you get to choose your tooling, your ticketing, your wiki, and everything like that. What are you choosing?

Justin: Good question. It’s funny because I was always very open to allowing teams to try a lot of different tools, and that was actually something I’ve learned along the way, that once you get to a certain size, you eventually have to standardize. I’d probably try out Linear because I haven’t used it yet, and I’ve heard people like it. Honestly, tooling matters less to me than what the core fundamental principles of building product are. 

The first is that customers are a part of the team. The first thing I would do is decide that 20% of every PM's time should be spent talking to customers. A lot of people hear that, and they’re kind of shocked because it’s a whole day a week spent talking to customers. I would do a quick diagnostic on how often the PMs are talking to customers, and I bet it would be not enough. Then, I would focus on building all the infrastructure that makes doing that possible. Part of the thing that makes it happen is that you have to actually make it easy for PMs to talk to customers because if they spend all their time figuring out how to get to customers, they won’t have that many conversations. So, that would probably be the first thing that I would focus on. 

The second thing I’d do is probably, depending on the stage of the company, focus on taking whatever the batch size (meaning how often we build things) is, and I would probably cut it in half. If right now we are doing things on a quarterly basis, I would see if we could start measuring things on a six-week basis. I’ve just found that work fits to the batch size of planning, and so if you want more velocity, you just reduce the batch size. So, if that were a problem, then I would probably focus on that. My other principle is to iterate to learn. So, let’s reduce the batch size and figure out how to learn things a lot faster. 

The third thing would probably be that I would look at where the idea is coming from for all of the features we’re building. At a lot of organizations, all of the ideas are coming from PMs, and I don’t like that. I would lean into how I could get designers and engineers to actually be able to come forward and propose their solutions. There’s a lot of different things you can change there. Like, just have people write a one-pager instead of PRDs because an engineer or a designer won’t want to sit down and write a whole document. If you do that, then you’re only going to have PMs that are actually getting it done. 

I can go into details with those things, but those would be at least a couple of the areas that I would probably dig into if I were joining a new organization. 

Matthew: Awesome! Well, we’re out of time; that’s what happens. This was a lot of fun. Thanks again for taking the time.

Justin: Of course, this was fun. Thanks!

About ProductFTW

ProductFTW is a weekly newsletter about product management, with a focus on real-life experiences in startups. We want to help product leaders be successful by giving realistic approaches that aren’t for giant tech companies. We know you don’t have a full-time product designer on each team. We know your software probably hasn’t been used by millions of people worldwide–yet. We’re here to bridge the content gap from building your product and team to scaling it.

Part of the Product Talks series — interviews with experienced product managers across HopSkipDrive, Smartsheet, The Zebra, perigon°, ClosedLoop AI, and Totavi.