Building and Scaling Products From Scratch with Dave St. Geme of OpenMind

Dave St. Geme - S3E4

Kayla: [00:00:00] Thanks for tuning in to Product Chats. On today's episode, I talk with Dave St. Geme, who is the previous VP of Product at Origin, and we talk about building products and scaling products from scratch and also hiring. So hope you enjoy the show and don't forget to leave us a review.

Hey Dave, thanks so much for coming on today.

Dave: Yeah, thanks for having me. It's great to be here.

Kayla: Awesome. Well, in a minute or less, can you tell us about yourself?

Dave: I'm born and raised in St. Louis, Missouri. Migrated out to the Bay Area over a decade ago for school. I went to Stanford and then have spent almost my entire career in either founder or product leadership role across a variety of great companies.

Most recently leading the product org at a company called Origin, and then before that at a company called Blend. And then now I'm just exploring. I've been working on a new concept of my own and figuring out what exactly I wanna work on next.

Kayla: Can you tell [00:01:00] us a bit more about what you're currently working on?

Dave: Yeah, definitely. So the concept is called open mind, and the idea is, or the purpose is how do we unlock the knowledge of the world and make that available to people at scale? So particularly, In high growth software environments, like what I'm used to, I found that it's really difficult to connect the right knowledge from the right experts with the right people and companies at the right time.

And I'm exploring how we can actually do that at scale.

Kayla: So with that, like are talking about like your current role and what you're currently working on, let's like back up a little bit and talk about how you actually got into product and what that journey looks.

Dave: I think I got really lucky, not embarrassed to say that.

So after school I started a consumer travel software company with a classmate from undergrad. This was in 2011, and we actually were basically starting Hotel Tonight. It was not Hotel Tonight, but it was very similar to Hotel Tonight at [00:02:00] the exact same time as Hotel Tonight. We just did not know about them yet.

We ran that company for a little over a year. We raised some money. Ultimately, the Hotel Tonight just kicked our butts and we unfortunately had to wind down the company. But that was my first foray into software and it was a wonderful experience and I learned a lot. And one thing that I really understood from that experience was how much I actually liked the product building and quote unquote, product management aspect of the co-founder job.

I had never heard of the title "product manager" before, and so I was able to parlay that into a gig at Intuit. I was basically introduced to some folks at Intuit. They were building out some new FinTech products and I was lucky enough to convince them that I would be a good candidate for the job and the rest is history.

Kayla: Awesome. And then with that also you talked about like the building of products. Like what are some of your favorite frameworks or things that you, best practices that you use when you're building out a product?

Dave: It's [00:03:00] very different depending on the type of buyer that you're building for the type of end customer that you're building for.

So, you have data products, you have developer-facing products, you have pure direct to consumer products, you have enterprise products. There's vertical versus horizontal SaaS, so there are all of these different types of products and businesses that you can build. I've spent almost my entire career, the vast majority of my career in B2B2C companies, which I think is really fascinating because you're simultaneously building for two end customers.

You're building for the enterprise who is the paying customer, but you're also building for the end customer. So it's a consumer user. So for example, with Blend, we're building enterprise software that helped people streamline the lending process and sort of back off office tasks. But we were also building an experience for people like you and I who are actually going through the process of getting a mortgage or a consumer loan.

And it's just a really interesting, I think, dynamic. I think it introduces new challenges, and [00:04:00] I'm happy to talk through those challenges, but most of my experience has been in B2B2C product management.

Kayla: So let's tap into those challenges. Can you tell us a bit more?

Dave: You know, the way that I think about it is, you have to have maybe like an additional level of rigor in terms of how you're thinking about for whom you're building and what problem you're actually solving.

When you're building a B2B2C product, it's really critical that you're very clear about who the, who the customer is that you're building for. Are you building for the actual buyer who's gonna lay out the cash to support your business, or are you building for the end customer, the person that will, in all likelihood, be one of the primary stakeholders and users of your software?

Given that in any product organization, there's an infinite number of things that you could build just for one stakeholder. It's an interesting additional challenge because you now have multiple stakeholders and you not only have to prioritize around what you're building for each of those stakeholders, but whom you actually [00:05:00] want to prioritize.

So that's one of the interesting challenges that I think makes it really fun.

Kayla: So with that piece of like prioritization, when you're working with both of these audiences, how do you figure out what even to prioritize?

Dave: Ultimately, I do think it depends on the company, but ultimately what I always try to not lose sight of is who's paying the bills.

And so, ultimately in a B2B2C company, the enterprise is paying you. And so it's really critical that no matter what stakeholder you're solving for, you might be building product for the end consumer. It needs to solve a significant buyer pain point. It needs to solve something for them that they're going to be willing to pay for.

And so one thing that I found helpful is oftentimes when you're speaking to an enterprise, they'll state a problem at a very high level. They'll say, I'm just gonna use Blend as another example. But they'll say, it's too costly to originate a mortgage, right? We think it should be half the cost. And that's great.

That's a big, huge problem. But it's really important to them break that down [00:06:00] into what are the sub problems that ladder up to that bigger problem, and who are the people that are actually encountering those problems? And then what is the magnitude of each individual problem. And so if you're able to get to that level of granularity where you can say there are actually these 10 problems that are experienced by enterprise stakeholders, these five problems that are experienced by consumer stakeholders.

This is the specific dollar cost that each of these problems is costing the organization every year. You can start to get down into the nitty gritty of, okay, what is the actual first problem that we wanna solve, and how will this directly add value to our paying customer, as opposed to coming at it from the standpoint of who's talking the loudest or maybe what's the most fun or beautiful thing to build.

That's just one of the kind of rules of thumbs that I use.

Kayla: And with that, it's about listening to your customer. And so when you're listening to your customer, are you doing user interviews? And also what is the right sample size of actually getting that data on what you should [00:07:00] build out?

Dave: It's really interesting because it depends on the stage of company that you're at. So a lot of my experience has been in really early pre-product market fit, pre-revenue companies, and then scaling with those companies and the discovery process actually changes pretty significantly depending on that stage. So in the really early pre-product days or pre-product market fit days, it's hard to rely on data.

It's hard to make empirical decisions because you just don't have that many customers or users or data points, and so you really have to rely heavily on speaking to your customers and trying to identify, this is kind of trite at this point, but identifying not like what they want, but what are their specific pain points, and understanding as deeply as you can.

What are their existing processes? Where are they experiencing the pain? Like I said earlier, what is the magnitude of the pain so that you can start thinking about the solution from first principles as opposed to will customer ask me for for this thing? So I think in my experience, it's really important to [00:08:00] talk to as many of those early adopter customers as you can.

10, 20, 30, 40 if you can. And you'll start to pattern match. As you have those conversations, you'll start to see similar challenges that people are facing. You'll start to understand a relative priority across those challenges. So, early days, I think it's really being as close to your customers or target customers as possible.

And if you can get a handful of pilot customers that are willing to be design partners and say, Hey, we're gonna think through the solution with you, we're gonna work really closely with you to help you understand the inner workings of our org. That's a huge accelerant because you're able to really get into the minds of the people that you're building software for.

I think as you're in the later stages, especially if you're building more things on the consumer side, you can be much more data-driven. You can start thinking about things like funnel optimization. Or if you're getting direct feedback in the app through things like NPS scores. Or you can look at engagement of specific features or products within the app.

And now you know, I'm gonna do a plug. I didn't even [00:09:00] know I was gonna do this, but there's a really cool product that I've used called Sprigg that helps you do surveys really quickly and easily. Products like Canny where you can actually get user feedback directly in the product, those are all things that enable you to make decisions in a much more data driven way. Once you have that level of scale and usability.

Kayla: So I wanna go back to that piece around listening to your customers, right? That's one piece of, hey, when you're building a product from scratch, start listening to your customers. Get this core group of like your people who just love you and are willing to invest their time, right?

And say, Yes, I'm invested in your product and I wanna spend the time helping you build this out. But besides listening to your customers, like what other pieces are coming into play when you're building something from scratch?

Dave: It's important to also get as much objective evidence as you can from either directly your customers or the market.

So for example, I'm just gonna keep going back to the mortgage, but what we found is oftentimes across companies, people's individual pain [00:10:00] points are not necessarily representative of the organization's pain points. No matter how high in the organization that person is. So one thing that we did was we actually worked to get really granular level data on what customer's mortgage origination process was.

You know, if it's a 50 day process, how long is each specific task in that process taking? And then we equated that to a certain dollar amount of cost that the organization was incurring. So we're able to do an additional level of pattern matching there because if someone said, Well, it's really hard for me to do this and it's really inefficient and it costs me a bunch of money, and then we saw that anecdote lie squarely within the most expensive part of the process, that's a signal to us to dive a little bit more deeply.

A lot of industries also just have industrywide data on these things. So how many people are experiencing a problem, different ways of quantifying the problem, whether it's in terms of time or money, or stress levels, or NPS or whatever it is. So I think that trying to be as objective as [00:11:00] possible and combining that with a direct customer feedback is really helpful.

Kayla: I think parts of that, like the piece of that is being like intimate with the like understanding of what is the actual process that your customer goes through. You may not come from a specific background, but being able to say, Okay, I understand that it takes this amount of time, or I understand the actual process.

Cuz without like that really understanding of what your customer goes through. You're not gonna build out a great product.

Dave: That's a really good insight. That's one of the most critical qualities in a PM, is the ability to have that adaptability. Few people will work in the same vertical for their entire career and will be solving the exact same or solving for the exact same stakeholder their entire career. So in my career, I've solved for consumers who are trying to build a budget I've solved for mortgage underwriters who are trying to not mess up. I've solved for financial planners that are trying to bring efficiency into their operation.

There's all sorts of things and the adaptability component is huge [00:12:00] because if you're one eager enough to go sit down next to your customer or your user and understanding what she's doing on a day to day basis, what tools she's using, what her pain points are, and then you're able to build an understanding of what it's like to do her job or be in her shoes.

That's a really critical component of building an effective solution that addresses a real problem.

Kayla: So now we're kind of hopping into the hiring and growing teams and the like adaptability piece and being able to just get in the trenches, listen to your customers, go out. What are other things, I would say, like that differentiate a good like product manager versus an okay or subpar product manager.

Dave: I'll double down on that first one really quickly, just to hammer home a specific point, which is like the customer obsession aspect or the user obsession. It doesn't matter if you're building a product for a developer or a data scientist or someone trying to buy a home. Could be anyone, but people who get excited about [00:13:00] going and sitting next to somebody and understanding what their job looks like and what their workflows look like.

Two, I was really fortunate to work for Intuit as my first employer because they really championed and created this notion of follow me home. Literally sit down next to your customer to understand what they're doing and what their pains are. So that's one I look for people with extreme customer or user obsession.

There's a couple other things. I think one thing that I've started to look at more as I've progressed in my career is, People who are really outcomes-oriented. So, oftentimes when I'm interviewing people, what I'll see is I'll ask people something that they built or something that they're proud of, and they'll talk at length about the solution and what it does, who's using it.

But there's a total lack of what was the motivation to begin with, what was the outcome that you were seeking to affect, and then what was the actual outcome of launching the product or the feature? Or whatever, because I think effort is great, obviously, but if you put a bunch of effort into something and there's [00:14:00] no outcome, then that's kind of the equivalent of putting no effort into it.

And so I really look for people who really clearly tie the target outcome and then the actual scene outcome to what they're building. I think that's just a really, really important mindset to have. And then the other thing I really love and I look for in people that recruit to report to me, but also in people, if I'm joining a company, people who will be my peers or my boss, or whatever it is.

This idea of the best idea wins philosophy. So people who aren't overly protective of their own ideas and having to be right and their idea or their solution, having to be the one that's implemented. But people who don't really care where the idea came from, as long as it gets you to the best possible customer outcome and the best possible company outcome.

I think that's just, it's such a critical mindset to have both from a collaboration standpoint, but also just from a getting to the best outcome as fast as possible standpoint.

Kayla: So I think with that also, it's about having a bigger purpose [00:15:00] within the team, right? And understanding – this is about me, but it's like, what are our goals?

And so how do you, like, instill that in a team and make sure that they're always looking towards that, those goals, and always aligning what they're building out to those goals?

Dave: What I see a lot of organizations do is they have a really like strict separation of work between product design and engineering, where it's like, all right, product comes up with all the ideas and the product strategy, and that's what our job is. Design takes whatever that idea is, and they turn it into something pretty. And then engineering just takes that design and the specification that's hyper discrete and they just write code. I don't wanna knock that philosophy.

That's just not what I do. At Origin, we were able to have a really great partnership between product engineering and design, where we use standard process called dual track Agile. Where it's really about getting each of those stakeholders very involved at the very beginning of projects so everyone can understand what is the customer, the persona [00:16:00] that we're solving for, get clear insight into the problems that they're having, and then have a seat at the table when it comes to thinking about.

What problems do we wanna solve, and then how specifically do we want to solve them? Instead of just waiting till the very end, we've decided on the problem, we've decided on the solution, go build it. That just makes 1) it gets to better ideas and and outcomes. And 2) I think it helps the team move faster because everyone has a common understanding of for whom you're building.

So that's part of it. And then the other thing, which you already said is it's really, really critical that everyone in the org and everyone in a specific scrum team or whatever understands the objectives of the organization, but also of your discrete group. What I've seen other companies do as well as like the product manager is the one that sets the objectives and understands the objectives, and they're the one that understands how this aligns to the company mission and vision.

And like, no. I mean, everybody should have as deep of an understanding as ideally the CEO does, of why does this company exist? Who are we building for? How do we measure [00:17:00] our own outcomes? And if you're constantly giving that information to people and giving them ways to better understand those outcomes, then people are gonna be better positioned to come up with solutions that will actually address those outcomes.

Kayla: And so with that, I wanna pop back to the idea of collaboration and any like best practices or other ways, obviously like getting everyone involved at the beginning, but are there other ways that you can make sure that all teams are collaborating really well throughout the development life cycle?

Dave: In the past that different orgs, we've done early research / brainstorming sessions as a whole group. So it will include product design, engineering, user research. I'm a big fan of having user research or usability research, whatever you wanna call it, as its own dedicated function. And so what we got into the habit of doing is at Project Kickoff, it wasn't about saying, okay, we've already decided the problem that we're gonna solve and how specifically we're gonna solve it.

It was about saying, okay, this is our broader [00:18:00] team mandate. These are our objectives as a team, and how we're measured as a team and how we want to measure our success in terms of driving user outcomes. Let's just start the brainstorming process of what are all of the different challenges that people face so that again, you're really encouraging people at the very beginning to not go immediately into solution or build mode, but you're involving everybody in the sort of deep understanding of customer problems mode.

So we at Origin made a habit of just doing that as a project kickoff with every big project that we were gonna do, and our research team facilitated that and it was incredible and I was a big fan of that. And then I think the other thing, like I mentioned earlier, is the dual track agile, where if you can systematize getting engineering and obviously design into the problem discovery part of the funnel and not just doing it on an ad hoc basis. Whenever you randomly think it's the right thing to do. If you can systematize that, I think it really pays dividends.

Kayla: Around that I think like we've talked a lot about like leadership and what you look for in hiring, so [00:19:00] obviously there's aspiring product leaders that are listening to this today. And I guess the question would be like, what is one piece of advice you would give to an aspiring product leader?

Dave: This is probably advice I would've given myself a number of years ago, so hopefully it's helpful. But as a new leader, probably in any function, but in product in particular, because you're responsible for so much of the strategy of the company, it can feel like you have to have all the answers. It can feel like if you display any sort of vulnerability around like, well, I actually don't know what we should do there.

Or I actually don't know what the right solution is or something like that. I think that actually creates worse outcomes, and the advice I would give is – don't shy away from that uncertainty or that vulnerability. If you can show your team that you have that level of vulnerability, it sets the standard for: we are an organization that prioritizes a learning mindset, a growth mindset, asking questions as opposed to an organization where everyone is expected to be a day one expert. And then the other [00:20:00] thing is it just gives more responsibility to your direct reports. If you're always coming in and saying: I know the exact solution to that problem, whether or not you actually do, it's gonna be hard for them to grow in their careers as well.

And it's acting as a crutch cuz they're just always gonna come to you if they have any sort of uncertainty about something. So I would say lean into the vulnerability and lean into the unknown and be upfront with people about that.

Kayla: And I think that also goes to the point of right, like hiring people that are smarter than you because you don't always have to have the answer.

And you can even learn from your team as like they grow and mature and maybe you don't have an answer, but maybe because you hired someone that was smarter than you, they have that answer.

Dave: I totally agree.

Kayla: And then where can people find you?

Dave: Probably LinkedIn would be the best place. So just Dave St. Geme. Yeah.

Kayla: Thank you so much for coming on today.

Dave: Yeah. Thanks so much for having me. This was fun.

Kayla: Thanks again to Dave for joining us today on Product Chats. If you want more product management resources, feel free to head over to canny.io/blog and we will see you next [00:21:00] week.