Product Talks with Zach Bartholomew - ProductFTW #45

For our eighth post in the Product Talks series, we’re featuring Zach Bartholomew, VP of Product at perigon°. Zach and I met when he applied for a product manager role at Bankrate in 2016. Our slow process had us almost miss hiring him, but we managed to make it work and I am so grateful we did. Since then, Zach has been a Founder and a Head of Product. He is also a regular contributor to ProductFTW.

Matthew: Hey, Zach. How are you doing? I know this already, but since we're doing an interview: who are you, what's your current job, and what does your company do?

Zach: I'm Zach Bartholomew. I'm the VP of Product at perigon, which is a startup that focuses on news aggregation right now. We have a big, different new app coming soon, but we'll see when this is published and if it's out by then or not. [Note: It is! Check it out]

Matthew: Tell us about your career path. What did you study at university, and then how did you get into product?

Zach: I got my computer science degree, and right out of college, I was a software engineer at AT&T for a little over four years. While there, I worked on a lot of Java backend middleware code and learned very quickly that I didn't like being that deep in the code. I like being technical, but just writing code all day, every day was not satisfying or gratifying. So, very quickly, I found myself searching for different roles.

At the time, product wasn't really a role. I didn't even know what it was. However, I started working on a new team at AT&T that was, in part, responsible for managing a lot of estimates that some of our consulting or contractor vendors would send. We would get thousands of emails a month that would have an Excel attachment with estimates and quotes for a given piece of work. My team was supposed to take those, open the attachments, copy the cells, and paste them into a shared spreadsheet.

I thought that seemed dumb, so I created this little application that parsed the email, had a database, and had a UI that allowed us to start tracking vendor management quotes. Very quickly, other teams were interested in this concept, so I ended up pitching it to our leadership team. They gave me a little money, like $300,000, to staff a team and build this application properly so it wasn't running on my desktop anymore.

That was my first introduction to product as a discipline, and I was the product lead. We built that app in about six months, and that was the kickoff to a career in product. I’ve had product roles ever since.

Matthew: What was your first role where you were called the product manager? What was different about that from your AT&T experience?

Zach: My first official role was more of an Agile role in a payments company. I think the official title was “Product Owner/Scrum Master.” It was very early in the days of Agile transformation, and that company was hot on that. I think realistically, I was probably more scrum master for the first few months, while I didn't know shit about the products or payments.

It was a little bit trial-by-fire because very quickly, I had to actually figure out how all this works, how I can make it better, and who my customers are—all of the classic product things. I think I was a little bit, I don't want to say over my skis, but I definitely learned a whole lot that I didn't even know I needed to know.

This was specifically for business intelligence and data warehousing. It definitely had a technical component which I was able to lean into a lot more than the payments aspect of it, which was definitely helpful. Then from there, I had a gap and took some time to work on other things.

Matthew: What brought you back to product?

Zach:  I got back into proper product management at a larger company, creditcards.com/Bankrate. I think what caught my eye was it was definitely still financially related. I did like working at the payment company, but I did want to have something a little more startup.

I think what you ultimately pitched me on was, we feel like a startup with money. I thought, “Awesome. That sounds really appealing.”

Matthew: Was it true?  Did it feel like you were at a start up with money?

Zachary: (laughing) No. No, not really

Matthew: I can't believe I said that to you. I was in sales mode.

Zach: It was mostly a good time. I was at creditcards.com for a few years and got to work on a big consumer facing consumer branded site, whereas historically my experience up to that point had been very enterprise focused or B2B.

I got to experience thinking about SEO and how to optimize for that. Ponder what does it mean to run campaigns and measure campaigns of not only SEO but SEM and other aspects. These are maybe more product marketing, but still makes you much more of a well-rounded product person. Things like optimization, funnels, and all that good stuff.

Worked with The Points Guy for about two and a half, three years, where we built a mobile app. I just continued to flesh out the missing parts of what it means to build and run software products. I've had mobile, I've had front end, back end, B2B, and consumer experiences.

With that, as I started getting titles that were more leadership focused, I definitely had the experience that I could lean into and say, “I've done this” where I felt much more competent for just about anything that could be thrown my way.

That ultimately landed me where I am today at perigon as Head of Product. Right now, we are just the API platform, which is very technical, and also leaning into the AI space, which I'm learning with everybody else right now. We're building a front end application, so I'm able to lean into my technical background and all of these other product-related things that you need to take a product from zero to one and one to hopefully millions.

Matthew: After all those varied experiences, what does product management mean to you, or how do you explain it?

Zach: Man, there's so many ways to describe it. Ultimately, the product manager is solving a problem that a customer has. That’s how I would describe it to a layman.

What it realistically means is that if you're a good product manager, you're the linchpin; you're the person holding everything together and making sure everybody's aligned. There are aspects of project management, but also knowing the customer and what the customer cares about, knowing your product and how the product works both technically and from a business perspective, and all the levers that you can use to make better products that ultimately your customer wants and will pay for.

Matthew: If someone comes to you and is maybe switching careers or is earlier in their career and asks, “What’s your advice for me to get into product?” Or “How can I be a good product manager when I start?” What do you tell them?

Zach: I’ll give an analogy. Steven Trong came to me and asked that back in prod-ops days, and what I told him was, “Steven, you are the most knowledgeable person about this specific product in the entire company. And there are things that only you know how they work and how they impact the rest of the business. So, already, you have subject matter expertise, which is a critical competency of any product manager. I think you can take that and start to act like a product manager and say, ‘We need to build XYZ to ultimately bring more customer and user value to the overall platform. You can use that as a launching point to get into product.’ And he got into product and now is an amazing product manager, eight years later.

It's finding a big company, finding a project or a product that you can ultimately lead and then propel yourself into that more product role. That's all caveated by whether that organization supports products as a discipline, which many do not.

Matthew: Indeed. Do you have any books, blogs, newsletters, or other resources you recommend people read or do to learn more?

Zach: Yes, I actually have a few. I think the tried-and-true “Lean Startup” is a good one. Marty Cagan's books are a good foundation. I think the common refrain is they're not super realistic, which I tend to agree with.

There's a newer book that I think is just a PDF, but it's literally called “The Product Book.” I feel like it does a good job of balancing things that Marty Cagan talks about, and it weighs them up or matches them up. “Okay, but in the real world, it looks like this.” That's what I would recommend to a lot of people.

I think another one, more for PMs that are working on maybe front-end or consumer applications, is “The Design of Everyday Things.” The Norman book. Another classic that makes you just look at the world differently

Matthew: What was one of the biggest challenges you had as a PM, and how did you leverage those product skills to ship the thing or solve the problem, or whatever the case is?

Zach: Let me think here. I thought it was going to be where you lost the battle. I was thinking, “Oh, when we built that freaking CMS piece of sh*t as opposed to buying our own.” Anyway, not that one. Do you remember that?

Matthew: Yeah.

Zach: Hmm. Maybe I can talk about my current role. We are a post-revenue startup. I mean, we are a seed stage, but we are a multi-million-dollar business that was built with simply an API platform. We continued to get feedback and feel this pull towards expanding beyond just a developer product.

With that, we started to go out and test the waters of what it would look like to build something. Maybe not consumer, because developers ultimately aren't consumers, but what is pulling us? Why do we feel this pull?

Leaning into those product skills, we talk to current customers and people who might fit a profile of customers we want to have and really start to see what problems we think we can solve with an application rather than an API. Over the course of, let's call it the last eight months, we've gone from simply an idea to almost a full-fledged product that will be live in about a month.

We've gone with the classic: we talk to customers, we show them something, we get feedback, and then we iterate on that. So we've continued to do that for many months. Now, we have many more months to iterate upon it. Those core product skills, I think, will help to get from zero to one. Hopefully faster, but without feeling like you're just maybe chasing your tail or just kind of winging it. We feel like we had a foundation that we could lean upon that I helped guide us through and ultimately launch a very successful product.

Matthew: You're in an interesting spot, right? You're the first product hire at a company, and you're the Head of Product. Do you have anyone on the team yet? Do you have any other PM's?

Zach: Yeah, we have one PM right now. And then we have designers and the other product support roles.

Matthew: This is the thing I spend a lot of time pondering in many different situations: Being the head of product at a startup where you have a founder running the company and the founder is the visionary. How do you think of the role of head of product in terms of vision and roadmap when you're in that kind of situation versus if you were at a big company and a CFO is running the place?

Zach: Yeah. Balancing that is walking a tightrope because they started the company and they have the vision. I think it's being the enabler of that vision. In my specific example, Josh is quite technical, but there's a level of technical things he doesn't care about and doesn’t matter to him. And then there's also me being the sounding board. So, both empowering him and collaborating on a vision has been what we've been doing here, but it's also pushing back on things that may not make sense, not necessarily in support of the vision, but in support of shipping products.

There are many times when any CEO will say, "We should go do that shiny thing over there." It's one of my core responsibilities to make sure that we're pointed in the right direction and focused on the things that matter the most. In my unique situation, where we have a strong, very successful CEO and me as kind of his counterpoint, we can balance each other out.

He has strengths that I don't, and vice versa. And I think we have a good partnership where we're both pointed in the same direction, but he's more long-term, and I'm more in the short to medium-term. Maybe that's a good way to think about it.

Matthew: One of the other things I think a lot about with product is our process orientation and building the pipeline for shipping. How do you think about, given your range of experiences – at startups and at zero to one companies, you've worked in series B, you've worked in giant corporations – how do you think about tuning the level of process and the approach that you bring and, using your current company, how are you deciding how much process or how little process? Can you talk to us a little bit about how you guys work? What is the method? Is it Agile? Is it something completely random? Is it just the Zach method? What are you actually doing?

Zach: I would say we've tried a couple of things, specifically about Perigon. We've tried a few different things. The current team has done Agile in some form or fashion for a good long while. I think we're all pretty competent and experienced in traditional Scrum/Kanban, so we wanted to try something a little different.

We tried one-week cycles, which were more Scrum/[Kan]ban. We would do typical planning and talk about what's on deck. We would not do grooming because we would have one-week cycles. We would do grooming and planning all in one go. That was interesting and kind of worked when the team was very small. When we had three or four developers, that worked fine.

As we've grown to double that and beyond, it simply does not work. The amount of planning that the product team has to do just isn't possible in that one week kind of sprint. Nor is it realistic as we start to build bigger things. Is it realistic for an engineer to build a relatively complex feature in one week? I think at certain stages, you start to reflect: This is slow, or this is just not ideal for our current scenario. So, as we reflect, we can say, “This doesn't feel right; this doesn't feel like it's optimized anymore.”

We followed that one-week cadence for about a year—up until we were about seven or eight engineers. Now, we're moving back towards the more standard two-week Scrum planning.

So we do grooming, planning, things like that. And that works ‘til it doesn't. I don't know at what point it doesn't. That’s what I've been using for a long, long time.

Matthew: What tools are you using? Whether it's tickets or wiki or whatever. I'm asking everyone this because I'm so curious about tool choices.

Zach: We use Linear and Notion. Our process right now is road mapping in Notion. Everything starts with a kind of business case or a one-pager. It's the who, what, when, where, and why that helps us get a sense of the foundational things.

Once we decide that this is a project we should actually go and do based on a number of factors, the product manager will create a PRD, and then that PRD will kick off a tech spec. Once the tech spec is done, we then review it as a larger group and then tactically break things into tickets and tasks.

This is another thing we experimented with: having the engineers break the PRD into tickets. That did not work at all. I think it can work if you have a product-minded engineering lead or engineering manager who can help balance some of that. But we did not, so it didn't work at all. Now, we're back to products as a result of the tech spec and PRD.

Product then creates smaller component-sized tickets that we then put into the sprint work. Linear is used for all of that. Notion is simply core documentation. PRD, tech spec, and everything else that's tactical is in Linear.

Matthew: How do you do sizing?

Zach: We do sizing at a project level. So t-shirt sizes, we kind of say small to extra-large. Small is around a week. Extra large is eight-plus weeks. And if it's that big, we should break it down even smaller.

We don't size tickets right now. So that's interesting, maybe? I don’t want to say controversial. But we don't size. Especially at this point, when we're about to ship a product, we are very much Kanban style. Historically, we didn't size either. We just said, “How do we feel like this looks for the week or the two weeks?”

Again, because we're so small and just scrappy, I think we would, most of the time, get it all done. But we will have to start to figure out what sizing looks like at a more tactical level.

Matthew: How frequently do you release, or do you do continuous?

Zach: We do continuous. We release just literally any day of the week. Hasn't bit us in the butt yet.

Matthew: I mean, if you have the right pipeline, you can do continuous. I think that's okay.

Zach: Yeah, I think this has been a positive experience from that perspective because, like I said, we push all day, every day, and haven't really run into issues.

Matthew: I think one of the interesting things about product, as we're exploring in this series, is that there are so many ways that you can do it, and it's very situational. In fintech, in particular. This is interesting.

There's a podcast series that was being done by one of the industry-analyst types, and he talked to Ramp and Brex, which are effectively the same core product. It's a corporate spend card. Ramp has continuous delivery, and Brex does three releases a year or maybe four. It's super fascinating that they operate totally differently, even though I think they're relatively similarly sized companies. Brex is probably larger and has more complexity to it, but it's a reflection of the CEO and Head of Product’s decisions.

They have really different ways of how they approach software decisions and releases, and they're both valid. Right? There's no correct answer. There's only the right answer for you. So don't size. Do size. Continuous. I don't care. Whatever works. That's my opinion.

Zach: Yeah, agreed.

Matthew: You guys are pretty small, so you can also think about other experiences at large companies. How do you think about managing communication outside of product and engineering and managing alignment to other parts of the business?

Zach: I would say that’s, at least at perigon, it's definitely an opportunity we have because we are small. We simply use Slack for just about everything. We're not super formal with internal release notes or anything like that, which has caused confusion for sure.

Communicating to our customers is another area that we need to improve upon. However, there are maybe two ways I think about this.

There's the feedback loop from customers that is, I think, a little bit different. I have a core set of customers that I can reach out to and talk about ideas we have or testing things that they'll give us real feedback on. They're kind of our biggest fans, which is nice. Feels like a safe place.

On the other side, there's all the other customers where we kind of say, "We've done a product release and we want you to know about it." We have a couple of different ways we think about that. There's the basic change log that we have that gets updated with every release. We also have a team that is kind of an offshoot of marketing, but we have a developer advocate who creates videos on our behalf. He really tries to tap into the developer community. He creates demos and trials to show what's possible, not only with the product, but with the newest release. So we post this on YouTube, and we have a Discord. We're trying to keep an open line of communication with our developer customers in the places where they hang out.

Matthew: What do you think is the most rewarding part of being a product manager for you?

Zach: This is a big answer, but I think going from zero to one has always been the most fun part for me. It's like you have an idea, and then it's an actual thing that people are using, and they like it or hate it – either way. It came to life, and you are now hopefully making money and all those fun things. Zero to one, idea to product, is kind of where I think I get the most satisfaction.

Matthew: Looking back, what's the product that you've already built and shipped - so you can't use the thing you're about to ship - that you're most proud of? Could be an internal thing, an external thing. Something where you look back, you think, “That was such a great experience. I shipped something really amazing.”

Zach: I would say the initial version of The Points Guy app was amazing. It was very well thought out. It was inspired by Wallaby. There were definitely things we didn't do, but we leaned harder into the redemption part of the points ecosystem. I think we built a lot of cool stuff. I left before it really saw the light of day, but I was really proud of what we built. There were so many great things that we had in that first release that have been unfortunately gutted ever since, but I was really happy with the product.

Matthew: That's good. I mean, that's one of those things. Some of the things I'm most proud of that we've done are very internal. Of the things that we've done together, one of the things that I love that you did was the publishing tool at Cards.

Zach: Oh, yeah.

Matthew: What was that called? Viewbook. 

Zach: Viewbook, yeah.

Matthew: Viewbook was a project that the external consumer knew nothing about, but transformed the way the business was run internally and solved a massive amount of problems that we had no solution to at the time. I love those projects because you have a very clear need, you can solve it, and you guys solved it in a really intelligent way. It was transformational, and it made the business better and more reliable, and it had all these other things. It wasn't like, “Gee, I hope customers click on the blue button that I just built.” The core thing we did got at least an order of magnitude better as a result. I always think those are really amazing things. I love the nerdiness of product when you're like, “I fixed a thing that no one was aware of.” I mean, you don't have to be most proud of that, but I always thought that was an example we would use.

We were talking about our teams at Bankrate, and that was a huge thing we did because, as you know, when we all got there, we could barely keep the site running. It was delivering $400 million a year in revenue, and it didn't work very well.

Zach: That's a good one. I need to remember that in the future when I’m doing this again.

Matthew: My last question is a two-parter: What do you think the future of product is, and how do you think it's already changed since you got into the industry?

Zach: I feel like this is in large part true, but for a while I thought that if you had the right attitude, you were smart enough and driven, you could be a product manager. I think, in large part, that's still true, but my recent experience is I think product people are going to be more specialized.

I feel like we're getting to the point where lots of companies are no longer hiring product managers, or they’re changing what a product manager means. And I didn't understand that for a while, but I definitely do now. I think that going forward, product managers are going to need to have a certain expertise. We know that subject matter experts are something that product managers are often, but I think it's probably going to go a step further. I don't think you can just drop into a company and be a great product manager just on your past laurels. I'm trying to think of an analogy without throwing people under the bus.

From what little I know about Totavi, you clearly have subject matter expertise in finance, payments, and fintech. So you guys are amazing product people in that space. I don't feel like there's a general-purpose product manager role out there for too long. I think you need to be specialized.

Matthew: I think that's really interesting because we talk about this a lot. Is there that subject matter expertise required and what is it that we [at Totavi] do? So I think that's a really interesting point. Thanks for chatting with me today.

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.