Product Talks with Matthew Goldman - ProductFTW #50

For our final post in the Product Talks series, we’re featuring Matthew Goldman. Matthew is the Founder of Totavi, a consulting firm focused on fintech, with a career that spans Green Dot, AT&T, Wallaby, Vertical Finance, and Bankrate. Over the past ten years of working together, Matthew has not only become one of my closest friends but also the person who taught me everything I know about product. His approach is clear, hands-on, and methodical. He believes product managers should be embedded in the team, not off in a corner writing strategy docs. He showed me that real product work means writing the documentation, breaking out the tickets, and working closely with engineering every step of the way. He shaped how I think, how I work, and what I believe product management should be. I’m so excited to sit down with him and share his perspective with everyone else. For more of Matthew's product thoughts, see his previous ProductFTW posts.

Ellen: Hi Matthew. How are you today?

Matthew: I'm lovely.

Ellen: Could you please state your name and current occupation for the recording?

Matthew: My name is Matthew Goldman. I'm the founder of Totavi, a consulting firm for fintech.

Ellen: How did you get into product management and what career path did you take to become a PM?

Matthew: I think I sort of always wanted to be a product manager, but I didn't know what it was. I'd certainly never heard the term growing up or in college or anything.

I was working as a strategy consultant at Deloitte straight out of college and trying to find a new job because I didn't like what I was doing. I had always liked working in technology and I had some experience with small technology companies, maybe you wouldn't call them startups because they weren't venture backed necessarily. I was applying to all sorts of random jobs. I applied to be a financial analyst at a company because I was doing a lot of that consulting, a lot of Excel work.

Then I got sent this job posting for a product manager at Green Dot, which at the time was probably about 60 people and had just closed their Series B. I didn't really know what it was, but it sounded interesting, like this intersection of business and technology. I applied for the job, magically I got it, and I've sort of been in product ever since.

Although I've had, I think, a very nontraditional product experience. I spent very little time as a product manager, doing typical product manager things. Like even at Green Dot, I immediately got re-orged into a title called Manager of Retail Cards. I was not managing the experience but managing the like integrations with our partners and going on sales calls and things. It was very outward facing. It's been a strange path.

Ellen: Because you've had an untraditional path to product management, how did you know that you were doing that role? Like what did it mean to you to be a product manager versus a manager of retail cards?

Matthew: I think titles are funny and people get hung up on them. I have often thought that there's a lot of people these days who have the title product manager and have no idea what the job really is.

Luckily, I had worked in the product organization. For the first year I was at Green Dot, I had good mentorship there from both my direct manager and the head of product. I did some traditional things, like I wrote a PRD. I was given a PRD and asked, “Can you write something like this, but for this other project?”

I really did a lot of reading and research on what product looked like then. That was an era when people were talking a lot, certainly, about Google's concept of product managers. I tried to just really focus on the essentials of the business strategy and the technology of “what problem are you trying to solve?”

We at the time were originally a very traditional structured company with waterfall development and business analysts who worked in technology and who wrote detailed requirements. We weren't doing that stuff as the product team. We were more, like, higher level, I guess you could say.

I also had already built my own companies and written software from scratch. I had started a company in college where I was, I guess, the CTO, although I didn't think of myself that way. I came up with the whole product and built the whole thing myself as an individual developer and had to make all those decisions, whether it was design or technology, whatever. It was terribly written. I'm a terrible programmer. 

But I think those things helped me understand what the job really was, which I still think, most importantly, is understanding the problem to be solved and how you can meet a user's needs. The rest of it is logistics. And whether you do them or someone else on your team does them, whether it's the project management or developer management, those are important aspects, but it's not the core of the issue to me.

Ellen: Do you have any advice for new product managers?

Matthew: I think if you want to get into product, you need to build a product yourself. The entrepreneurial spirit is very important to me, not surprisingly. And while you don't have to start your own business, I think you have to understand the whole thing. Because the people who have the title and are bad at it have learned about it entirely inside large organizations where they don't have enough true responsibility for the outcome.

When my boss, a guy named Kostas, hired me at Green Dot, he actually was very funny because he said to me when he offered me the job, “I am not hiring you because you work at Deloitte. I'm hiring you because you've had your own businesses in the past.” I thought, like, what a weird thing to say to me. But I realized later what he was saying was, “I know you can just figure out how to get stuff done and you can make decisions because you’ve had to do it for yourself.” You can be flexible and all those things.

A lot of the best hires I've had, whether engineering or product folks in my career, have been people who have had their own side projects. Again, they don’t have to be like businesses. Maybe it’s “I wanted to make an app to do this thing for myself and I went and I did it.” Maybe it's not a great app, but you have to learn all this stuff to get there, right. You have to come outside your silo.

If someone came to me and you know, they were in college or whatever and was like, I want to be a PM, I'd say, “Okay, go figure out how to build a piece of software.” Right? Go find a problem that people have, do that research, and actually build the thing; be very hands on. 

I don't use a lot of the frameworky stuff. I don't tell people to read the Lean Startup playbook or whatever. I don't even know how to do those things. Yeah, I think people get very distracted with business maps and it's a good way to stay busy or something. And I'm sure some people find it helpful, but I'm more like, just go! Just go muddle your way through something and figure it out and build your own style.

Ellen: You have me thinking a lot about what it takes to actually build a product from start to finish. It's a lot more than people realize, I think.

Matthew: Yeah, it's important. We’ve done a lot of training on these things.

It’s important to be good at writing a clear user story. But if you can't even understand how to figure out what user problems are, then you don't get to that part. It's great to be able to run a clean sprint with your team. But that's project management. That's part of the job in a corporation. And in big companies, as we've seen, you might have a project manager or a scrum master or whatever helping you with those things. But it only matters if you're building something useful that people want to use or buy or whatever. And everything else is ultimately like noise.

Ellen: And knowing how to effectively research to know if you're even solving the right problems. Back to what you originally said - start with the problem. What is the right problem to solve? And we've seen that a couple of times recently where people haven't done the research. 

Matthew: Yeah, I think there's a common saying about people coming up with solutions first. Sometimes the solution might pop into your head, but before you build the product, you have to figure out what is the real thing that that solution is addressing.

A lot of people think, “I built this cool thing, I must be able to sell it to people.” And the greatest products are built with a deep understanding of some underlying problem that people were not even aware of as a problem.

I think in the fintech world, my favorite example is actually Stripe. Everybody knew that accepting payments online wasn't great, but nobody thought about the problem crisply enough until Stripe to build a great solution to it. We all just accepted it as the way things were. That's the insight about a key problem that might be staring you in the face. Plus, you know, the timing and the execution that makes something successful.

Ellen: I know it's not your favorite product book, but It Starts with Why, if that's the only thing you took away from that book is the title, it's a pretty good starting place to figure out.

Matthew: I mean, I don't have an opinion. I never read it.

Ellen: You didn't read it? I thought you had, and it wasn't your favorite.

Matthew: I don't remember it. Maybe that's how much it meant to me.

Ellen: You’ve definitely read it. I think you even have it in your bookshelf. Anyway, if that's the only thing you take away and that's the only thing you read was the title, that's a pretty good indicator of where you should start with.

What has been your biggest challenge as a PM and how did you overcome it?

Matthew: There are three types of challenges, I think. One is when you try to do something, and you can't figure out how to actually do it. Like with Wallaby, I had a great problem and a great idea but there were external factors that prevented us from doing it. In many ways I think of that as one of my greatest challenges. And the answer was to solve an adjacent problem.

There's also challenges like people challenges, and then there's kind of team management challenges. And I think certainly in that vein, I think a lot about the function of being a product manager. Because the Wallaby problem isn't necessarily an execution problem or a tactic problem. It's more external.

When we were at Bankrate, we had to transform an organization, and I think that was the biggest challenge. We had a company that did not know how to build software efficiently, as many do not, actually. I'm very cynical. Most companies are quite bad at what they do and survive anyways.

Bankrate could not ship product, could not keep the site running, could not reduce costs intelligently through cloud optimization. It couldn't do anything right. It was quite terrifying. Our friend Kamelia, her favorite analogy is we had to rebuild the car while it was driving down the road. We couldn't just stop.

That was such a huge challenge. I certainly had some of my lower moments and some of my higher moments. We were able to achieve some really great things, like really rebuild pieces of software and migrate the site to the cloud. 

My favorite example is Zach’s project. [Editor: You can read more about this in Zach’s Product Talks.] It used to take us 90 minutes to publish a website, which is terrifying. We managed to, in less than a year, change it so we could do it in seconds from Slack, which was totally transformative and a requirement of the business from a compliance standpoint. But getting there was over a year of really hard people and process management and really core product stuff. We had to change how we prioritized, how we built software, how we organized teams, all those things. Which is maybe more product leadership, but definitely the most challenging time of my career in many ways.

Ellen: The 90 minutes thing still blows my mind. And the fact that you're saying that we had to migrate to the cloud in 2013, it feels really far behind.

Matthew: And now, very few people build stuff outside the cloud, although some people are going back to it [designing outside of the cloud]. I tell people there are things that are fundamentally cheaper. It's just whether you want to deal with it. I just had this conversation with somebody yesterday, right? Like racking and stacking your own machines, which is actually how I got started in technology as a sysadmin, is fundamentally going to be cheaper at a certain scale. But you also have to have someone who has to do all that stuff and maybe you just don't want to deal with it. Cost optimization is not the only thing; there's also an operational aspect to it.

Ellen: Yeah, and security benefits, and things like that. What is a lesson that you've learned as a PM that has changed the way you work or think or collaborate?

Matthew: I think that one of the key things about being a product manager is that you have to lead through influence. You're normally not everyone's manager and you can't just tell them what to do.

I'm afraid a lot of PMs think that this is going to be their life when they take the job, because it sounds fancy. Or there's the famously wrong “you're the CEO of the product” thing, which is one of my least favorites. You have to bring people along and be an influencer.

Although I was probably always someone who had some skills for doing that, I did not think of myself that way, like as a salesperson or as someone who would influence others. I realized in product, if I wanted engineering to do something or I wanted design to think about things a certain way, or I wanted to even get my project on the roadmap, I had to bring data and emotion and influence to bear to get an agreement because I wasn't the CEO. I couldn't just say, “oh, go build this." 

You see that constantly. It's really funny. Even in big companies, you have executives saying, “Well, I don't know if I can convince everyone to do these things.” It's very hard, especially in high paying, high flexibility, high intelligence technology jobs and companies, to just tell people what to do. They don't want to do it unless they think it's a good idea, so you have to bring that forward.

And that, I think, affects all parts of people's lives. Whether you have, you know, a partner or teenagers, as I do. Like, you can't just tell them what to do. You have to try to convince them of something and also be respectful of the things they're trying to convince you of and keep an open mind and understand that there are often many right ways to do things or right opportunities. There's not a single answer.

Ellen: I want you to touch upon the idea the product manager is not the CEO of the product, especially for this interview on product leadership.

Matthew: I remember when I was at AT&T, I'd been there for, I don't know, a few months in a product strategy role. I was really excited. I was like, “Oh, I don't have to be responsible for a team or delivery. I'm just going to sit here and make cool PowerPoints and do strategic thinking.”

That, of course, didn't last very long. Then they did a big reorg. They were like, “you know that strategy you came up with? Now you have to go implement it.” And they handed me a re-orged team and a bunch of products and stuff.

The people I inherited were told by their old boss that they were the CEO of their product. I said, “Well, that's not true.” You don't control sales, you don't control marketing, you don't control engineering. You can't set budgets. You don't have P&L responsibility, which was a thing we were changing in the reorg was to bring P&L responsibility into product. And you can't just tell people what to do. 

A CEO is a funny job in general. They're ultimately responsible for all these things, and people do report to them, and they have the right to hire and fire people, ultimately, all throughout the organization. They're the only person who can really do that.

 A product manager can't. You can't think, “Oh this engineering manager is slow, so I'm just going to fire them.” No, you have to go to your engineering leader and be like, “Can we have a chat about Joe and his delivery?” You just don't have these rights.

 You have to approach the job in a totally different way because you don't have that capability. And again, you have to work with your partners.

 The most successful thing I did at AT&T was because I started with, “This is an interesting product problem to solve.” Then I spent a bunch of time with my channel marketing leader to ask, “How do we sell this thing? And is this a thing we can sell?” We aligned on the pitch. It's what made the product successful. We could have made a cool product and if the sales guys don't care about it or don’t want to sell it or don’t understand it, it will go nowhere. 

Because this was a sales-force driven company, it was not just self-serving or whatever. I think that was very insightful. You had to think about everyone as your partner, not someone who reports to you. I get really cranky about that because I think it makes product managers really self-important and think they can tell other people what to do, and that's a recipe for failure.

Ellen: Yeah, it definitely makes it difficult to influence people if you approach it that way. What are three tools you use every day that you would suggest to aspiring PMs to learn, understand or buy? Is there a methodology or software you would suggest? 

Matthew: The most important thing that PMs have to be able to do is communicate clearly in a written form. There is a visual aspect, like diagramming. Whether you use Whimsical or you could use Figma, or I don't know, I guess you could use something older like Draw IO. We love Whimsical here, for these things.

A lot of what goes wrong in product development is miscommunication-based. Being able to communicate really, really clearly both in written form and in basic drawing is really, really important. I think people need to spend a lot of time focusing on that skill.

Conversely, product managers should spend a lot of time focusing on listening skills, which is super hard. I've read a bunch of pop psychology books about listening. My favorite one is called You're Not Listening. I love the attitude of it. It's by a reporter. It’s about the psychology of how to elicit information from people and how not to steer conversations. It's a good lesson for life in general, I suppose. It's still very hard to do.

Again, it comes back to understanding the problem and understanding how to communicate that problem and potential ways to address that problem. Everything else is just tooling. And I love tooling. I have strong opinions on tools and how to write tickets and whatever else, but that's very functional. If you can't do the primary stuff, then tooling is kind of irrelevant.

The most universal skill is essentially communication and listening. Then the writing part, because spoken communication is always hard to follow up on. So even if you have a meeting, product managers have to document it and say, “This is the thing we agreed to and does everyone see this and do they get it and are we all aligned?” Then you can go build things. If you start before that, you're just going to get into a mess.

Ellen: How do you manage cross functional work and communication across different teams?

Matthew: I think, especially in bigger organizations, it's really important to build rhythms that make it easy. For example, an end of development cycle set of demos. We used to do that at Wallaby. Every end-of-sprint, we would have people demo stuff. Sometimes, maybe the BD person would not understand a demo on a command line, which did happen all the time, versus something visual, but it rallied the team into “Here's what we're doing." 

Another important thing is aligning people on metrics and results, and having shared dashboards. A lot of times, there's this idea that if people have the same information and they're, generally speaking, intelligent and well-meaning, they will come to similar conclusions. A lot of the friction in organizations comes from people using different data. If you give everyone access to the data warehouse and they can just make up their own stuff, they might come to different conclusions. And there's a lot of nuance, right? Like, what is the right denominator for a conversion rate? Is it visitors or is it people who visited a certain page? Right? Or are we talking about performance of an SEO funnel, an SEM funnel, or an organic funnel, or all of it mixed together? So, giving people really clear dashboards is saying, “Hey, we're making decisions based on this set of data and here's how we all access it.” And it's all the same number.

Data is messy and people wish it weren’t, and they wish it were totally deterministic. You have to have that understanding. That understanding is important because then it helps align people on the goal and the measurement. It reduces a lot of the arguments. 

The other big thing is trying to get people to step back from their own individual world and make bigger decisions like once a year. To pick on BankRate, when I got there, prioritization meetings were just a brawl, as they are in many companies. We did this exercise where we got the executive team to agree on around five themes and to allocate resources based on those themes. Then each theme was given a pair of executive sponsors, who were responsible for making decisions largely inside their theme.

After that, prioritization got so boring we almost got rid of it because people had this broader responsibility. They went beyond “I'm the marketing person” to “I'm responsible for this theme.” Then we already had decided how resources work. It was no longer “I’m cranky.” Well, some people were probably still cranky, but it was no longer people asking, “Can I have more resources?” Because you know that for this theme, we've allocated 20% of the company and inside that are all these projects and you get to put them in order.

People were really forced to make their own decisions within this narrower universe. They can't think, “But can I steal from this other thing?” Because they already agreed that other thing was important and got its 10% of the resources or whatever. So having those big agreements, which are hard, I mean, that took days of an offsite and stuff to get to, reduces a lot of friction and creates a lot of alignment because you already made that decision. Then you can leave the nitty gritty to something less frictional.

Where you get really stuck on stuff is when you're arguing every little thing because there isn't that alignment. There are companies that are like that. When I worked at Green Dot, the CEO used to love to pit people against each other in prioritization. He would tell two different people to go argue for their project to be number one. But we would prioritize all 35 projects across everyone, all the time, and move resources around. It was a constant battle. We could have said, we have 35 projects, they fall into these buckets, and we've assigned these resources. That would have been a lot more pleasant, and we probably would have got a lot more done. You lose a lot of time to the thrash of reprioritizing and shifting things.

Ellen: Absolutely. Where did you learn about that methodology?

Matthew: The themes stuff? I sort of made it up, I think. I mean, a lot of these things are from reading a bunch of books and everyone's got a name for stuff. It's sort of like with the OKR-type stuff, where you have these key goals. I don’t use OKRs. I just kind of developed it from trying things and working with people. There's certainly influence from people who have been my coach and books I've read. But again, it's not like a formal methodology, it's just a way of approaching it.

It's not something you can do at every company because you need the CEO to buy into the concept, certainly, and make people align on it. You need a place where people are a little bit less selfish, maybe.

I describe a lot of things that I've done as versions. When I ran Wallaby, I used to describe what we did as our version of Agile. I'm not a strict methodology follower because I think you need to adapt to the situation. But you can take underlying concepts and use them so that people are familiar with them. Make it work for what you're doing, which changes depending on what you're building, who you're building it with, how big your team is, all those things.

Ellen: That's really interesting. What is the most rewarding part about being a PM for you?

Matthew: I love shipping product. I think it's just so cool to see something that you made out there in the world and people using it. Kind of like with the idea of NPS, which is this question that the McKinsey people invented, which is like, “Would you recommend this?” There are two great measures that tell you if you did a good job: one, would you recommend this; and two, how would you feel if this product didn't exist anymore?

That's the thing that was just amazing about Wallaby. We had super-passionate fans of our product and when it went away, people were upset. That was sad, but also very gratifying to know you had built something that really mattered to people and that they were going to miss when it was gone.

I'm a little overly enamored with shipping probably, at the expense of other things, but I just love the creativity and the building and the camaraderie of, “Hey, we made a thing. Here it is.” That's just really cool.

Ellen: Yeah, I love that feeling. What do you think the future of product management looks like and how has it changed since you became a PM?

Matthew: Well, it's changed a lot. When I started, almost no one was doing Agile, and most people didn't know what product was. When I went to work at a startup in 2006, post the whole dot com boom, people were like, “That's a terribly dumb idea. Startups don't go anywhere, whatever.” And now startups are so cool.

I got this hilarious email yesterday that said Money2020 has grown from a small conference with just fintech fanatics to 20,000 people. I was one of those fintech fanatics because I went the first year. That was very funny. 

Everything’s more popular. And that really changes the dynamic because you get a lot of people who bring new experiences and new thoughts. There's obviously good and bad to the growth of anything. And then the way we work has changed a lot because of remote work, as you and I have discussed many times.

I used to think of product as being very much an in-person/standing at a whiteboard/sitting next to your developer experience. And there are great things about that and there are great things about remote. That's really changed how we communicate. Like Slack is part of everyone's daily life. It did not exist when I started. We used ICQ at Green Dot to instant message across the building.

Ellen: I don't even know what that is. What is that?

Matthew: It's an Israeli instant messaging company that predates AIM and you got a number, so you had to know everyone else's individual number, and exchange the number in real life.

Ellen: Predates AIM? I don't even remember before AIM.

Matthew: I think AIM bought ICQ and then now they're both gone.

When I was in college, we all used AIM to communicate with each other. They had this mug where, if you donated to the senior class fund when you graduated, you got a mug and you got to put a word on the mug. I convinced almost everyone in my senior class to put their AIM handle on the mug. That was like how big it was.

So, just the way we communicate has changed dramatically. Looking into the future, I think the way we build software is changing because of what we're seeing with AI and tooling, those things really go together. It may be faster to build things, but it may be easier to go astray.

I don't think AI is going to take over the world personally and, I don't know, let us all do whatever we want because it'll do everything for us. I think it can be really dumb still. It's probably really far away from being a human. I don't think AI is creative. I think AI is really just regurgitating humanity, which can be useful, but it's a heck of a lot faster to write a little script now or build something out because you can have AI help you. That might really increase the pace at which we can do things, which is exciting. 

Ellen: I like the AI conversation. So, I think this is supposed to go on the top, but what did you study at university?

Matthew: Economics.

Ellen: And how long have you been a PM?

Matthew: It's confusing because I've been a CEO in between, but let's go with around 18 years now. 

Ellen: Have you always been a PM?

Matthew: Well, kind of. [Wallaby was] still a product-led organization. We didn't hire someone to run product until after we sold the company.

Ellen: What is your favorite book about product?

Matthew: I don't know. My favorite business book in general, which maybe is related, is Five Dysfunctions of a Team. Because I think that understanding those interpersonal dynamics are so critical. My favorite book about fintech is the Unauthorized Story of American Express because it's a swashbuckling story of company growth. But yeah, swashbuckling. They all were like shooting each other and stuff. It's wild. 1850s with a different world.

Ellen: I like to think about Wells Fargo moving money in the horse carriage. That’s all my questions. Thanks, Matthew.

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.