Lessons from Stripe on adding new products - Assessing ideas, structuring teams, and tactics for product reviews | Tara Seshan (Watershed, Stripe)

Brett Berson: Well thank you so much for joining.

Tara Seshan: Thank you. Excited to be here.

Brett Berson: So wanted to kick things off by talking about one of my favorite topics, which is, uh, going from single to multi-product. 

And maybe we could sort of start there and have you share a little bit about maybe what Stripe was like when you joined, and what kind of that path into the first few products looked like.

Tara Seshan: I joined Stripe in, um, early 2015, and so the company was, maybe, almost not 200 yet. Uh, there still was very little adult supervision. Um, It was mostly everyone running around trying to figure things out. And from a product standpoint, there was the core payments API, and we hadn't even launched any other payment methods yet,

it was just cards. And then we had started exploring, uh, this thing called Connect, uh, where Amber Feng and Cristina Cordova had built a initial version of this like multi-party payments idea that someone like Shopify or someone like Lyft could be able to route payments in multiple directions to multiple entities.

There was also like some early explorations of what else could we do on top of payments? Um, but by and large there, it was a one, it was a one product company, pretty much. And it was one product with one main feature and that, and that was taking payments, uh, with credit cards. And it's in like the classic Stripe fashion of doing so.

Um, without a UI, with Stripe JS, with instant onboarding, like all of those things that made Stripe so unique back in the day, but really this one single product, that drove a ton of the product market fit. 

Brett Berson: What did the company do to start to think about what are the next few products, and/or business units we might want to create?

Tara Seshan: I think the most important thing as you begin to think multi-product, if you're a product that has initial product market fit for a core, what else does that specific user want that would make their job better? Like the classic line of your B2B user wants to get promoted, what is the thing you can give them that helps them do so?

And when Stripe was thinking about the second products, one of the easy angles for that is who is our buyer? It's that developer who's like integrating payments early on, and like what could you give them, that same buyer, to make their lives meaningfully better? 

And so that's how Radar the fraud product came about, where it's like, well, all these people are taking payments on cards, and you know what sucks about doing that? Fraud. 

Let's, let's give them a tool uh, that can make that a lot easier. And given that we had that focus, that our user was the same person who was buying payments, we were able to really, um, similarly narrow down the set of features that made a difference for that user.

Certainly there's other dimensions that you can think about as you're trying to go multi-product. One is like, does going multi-product allow you to unlock a net new user base that you weren't targeting before? So that was Stripe Connect was the other kind of early multi-product bet that really worked out for the company. And that was, Hey, we've been targeting, uh, folks who are trying to take, for lack of a better term, vanilla payments.

Let's then think about people who are marketplaces and figure out a tool that can take on more of the complexity for them of building a marketplace business. And do the, you know, underwriting of your initial accounts, the routing of payments, the like, balance calculations, all of that for them. So that's, that's one angle for it.

But the other angle, the angle I think is really fruitful within a company is sell something else to your same buyer and you, you kind of know that user and you know their needs. You're much more likely to succeed by giving them an additional product than trying to launch a product that targets something wholly new altogether.

Brett Berson: when you think about selling another product to the same buyer, or you think about building a new product that basically expands TAM would be kind of the broadest way, I think, to articulate it, how were those decisions made?

And was it done in some sort of framework or it just was intuition? A lot of, fraud is a big issue, we're gonna launch a fraud product to the same buyer. What was the level of sophistication in thinking about basically resource allocation in this sense?

Tara Seshan: I think a hugely important part of this is that those initial secondary bets, those things outside the core, can't be expensive. Um, at least that's how it worked with, with Stripe, that core payments maybe took, uh, 75% of the engineering bandwidth. 

Um, the, these, each of these bets maybe took the remaining pieces, uh, with expanding to a net new TAM taking a lot more of that resourcing than something like this new fraud product. I think the idea and part of what incentivized the early team to work so hard on this was that you got very few resources. 

You had like a couple, you know, three or four engineers, you're trying to work on something and get a proof of concept really fast, and then earn your way to more resource allocation.

And I think that's kind of a, a smart move on the, on the executive side by saying, great, we're gonna, we're gonna fund this core bet, and then great have, have as few people as possible as you need to iterate on something early. We're not gonna overfund it. Because actually in that early stage of trying to establish something, actually having more resourcing holds you back.

As counterintuitively as that seems like more people to bring along versus people who you're ideating with actually create, um, drag on that process. So actually having very few engineers like. Again, I think it was maybe two to three in the early days, like heads down, working on something together.

This product is for developers, we didn't need a ton of user researchers or didn't need a ton of, um, additional people, I did all the sales myself. It took the like communication, coordination, uh, cost out of that initial product building entirely until it became really clear that it was worth paying that for additional velocity.

Brett Berson: Can you talk about that in more detail? How you thought about org design, what does that look like to do well, or what did you kind of figure out about that small pod to make that work?

Tara Seshan: I think the initial idea for a lot of those products tends to come really bottoms up. 

So you want, um, folks who are close to the users. Be that your product development team, it should be your product development team in a lot of ways, um, or others come up with a set of ideas and filter out to the, the more promising ones.

Initially there'll be like 50 bad ideas on the table for those types of ancillary products and probably like three or four good ones. And so you want to be able to bottoms up identify, what are those three to four good ones. 

Brett Berson: And is that done just with taste or was there a way that there was a more systematic or precise way that filtered fraud all the way to the top of the five or three reasonably good ideas?

Tara Seshan: I certainly think there's a tops down evaluation of these ideas like now when I'm in the sort of seat of evaluating ideas that are coming to me, um, I think of a few factors. One, how costly is it to get to initial hypothesis? Like how fast will we know? Um, two, there's like, it has to be a compelling answer to why now.

There's so many things you could do that there has to be some intersection of like the moment and the opportunity. That makes a ton of sense. 

When as stripe got larger and larger, the question became not only why now, but like what's the opportunity on the table for this idea? Like, this has to be an idea where we could eventually work it out to Patrick's, you know, sort of bar was, is this gonna add like $10 billion of enterprise value to Stripe?

Eventually, like, could you paint for me a path where that could happen? Um, and that's a, that's a very specific way of thinking about it. Um, But soon enough that became criteria as Stripe continued to scale just because the opportunity, cost of the time and the investment became higher and higher. 

But in that early, early stage, and as I think about this as an early stage for Watershed, for me it's the, like, how lean can we go, and how fast can we get to an answer of, Hey, this is working, or this isn't, and answer is a, you know, answer for now.

and then two, what is it about this moment? What makes this idea something we have to do now? We can't do it later. There's like a unique at bat for it at the moment that makes this something we have to jump on.

Brett Berson: Okay, so going back to, you were kind of mid flow of explaining what it actually looked like and what the team construction looked like.

Tara Seshan: Yeah, I think you, you want the team to be really self-sufficient, so you want the team to not have to reach outside of itself to borrow expertise from other parts of the organization. Like certainly within the organization, there are parts of the code base that they can benefit from and things that they can borrow and things they can use.

Um, But you don't want the team to have strong dependencies on any other part of the company. And so you're thinking as few engineers as possible. Two to three. Um, maybe for in c-, if it's a big project and you, you know, want resilience, when folks are going on vacation, you want them to have all the expertise necessary.

So in this products case, you want someone who understands the models and machine learning side. You want people who can like, build lots of really interactive front end product. Um, You want folks who can kinda do both and think about the intersection of that product and the API.

You want a product slash do everything it takes sort of person. Like I was selling and doing the product design, and then also going into our models and trying to write human readable explanations for like why the model scored things this way versus that way. Like you want people who will just do anything. Um, and so as few people as possible with the maximum number of skills.

And they don't have to be great at all of those things. 

They just need to be willing to do it, to do it enough to test, um, and then just let those folks run.

Brett Berson: So you sort of talked about from an org design standpoint, super small team, three or four engineers, kind of generalist, producty person Do you think there's something unique about that product person that is differential to all the other great product people at Stripe or at any company

when you think about who should go do that?

Tara Seshan: I think there, there are certainly subtypes of product people and some are suited for this type of thing. And some really, really aren't. Like most people segment product managers or product people in general into are you a platform PM or are you a product PM ?Um, are you an optimization PM or are you a, uh, zero to one type? Like as you get to a more mature phase, like that really, really matters.

You need a mix of those people at the company and you should actually be really intentional in the early days in like who you're hiring to fit those needs. Um, but actually one of the things that made the most sense for Stripe in the early days and I think made sense for Watershed, I was building out the initial PM team, is I like really strongly believe in hiring people for potential, not necessarily for experience for those types of roles in particular.

Like hungry and high potential person who's dedicated to growing quickly, can build more value for the business than a statusy or experienced person who is less high potential. And so I think the hard part here is trying to understand, of those early high potential candidates, who is great, given the paucity of detail in their background.

And so folks who don't have a resume whose screens signal to you are, it's, that's the hard part. Um, but I strongly index towards, especially for those initial type of bets, hiring those people more than anything.

Brett Berson: What is your process to get to conviction that somebody could be really exceptional? Given to your point a lot of times you're intersecting them earlier in their career, they have a smaller body of work that could be a proxy for their ability like, what does your own personal process look like?

Or like, what's your internal algorithm in your brain that's sorting someone from like, I need to hire this high potential non-credentialed person versus this other high potential non-credentialed person that I don't think is truly exceptional.

Tara Seshan: So I think I, I have a few criteria. One is that the most important is probably do they show hunger? Like candidates have to show they care, which should separate them in that initial screen. 

So do they go above and beyond to show their interest? Do they message you repeatedly? Do they do something special to set you apart?

Like, I had a candidate recently that made me a YouTube video of why they wanna work at Watershed, which sounds random, but these signals actually really matter. If they're hungry now, they'll be hungry in the job, which is great for the company. And I think that's very key. Even if a candidate's coming to you through more traditional channels, like do they show hunger from their past experience?

So did they get their past job in an unusual way? Did they materialize an opportunity from nothing? Do they start stuff? Do they do a ton of zero to one hobbies to try to make their opportunities. They need to show a lot of hunger in the background. The second is high horsepower. And this is like a non-negotiable.

If they don't show high horsepower in some way, then like it's a no. So like, do they have a great side project? Do they write very excellent blog posts or documents or articles that show incisive analytical chops? then And then there's a question that actually, Chris Cox recommended to Watershed, when I was trying to hire PMs really early, which is like get someone to tell you about something they've learned recently in an early interview conversation.

And I think, did they learn about something complex? Can they explain it really well? Do they show de- like understanding of detail is also really, really important. 

And then like one of the last couple things I look for is wins above replacement. Like, yes, it's a sports metaphor, but like someone at their same stats, like do they do better than that person somehow in terms of outcomes because of some other ineffable quality that they bring to the, to the thing.

And so in their past work, did they show creativity in identifying the bigger problem, or opportunity at hand, versus showing lots of behavior that involves like taking orders from the boss. Like if they did a lot of the creativity thing, that's key. And then next, like did they drag something across the finish line?

Like most smart people are actually terrible at having the drive or follow through to take the thing over the finish line, drag it through. 

I remember my boss at Stripe when I was initially hired, told me we were interviewing a candidate who worked at Bain. And my boss was like, oh, you know, most of these Bain candidates, they don't like, I, he's usually a no because oh, they're just, they just wanna do strategy.

But this guy talked about how he implemented a call center project and he stayed on the project like three months longer because he wanted to see how it went. And he like visited the call center and like took calls with them. And my boss was like, actually, you know, all the other stuff, not that signalful, this bit of it is the most signalful thing.

Um, because most people wouldn't do that follow up and like stay in the details till it's done. And that's a really important quality here as well. 

So it's all these little things like absent the usual resume, GPA like, you know, they built these 10 things. Like I think it's looking for these qualities that help me really understand, is this a high potential person I wanna take a bet on?

Brett Berson: What are the most common anti-patterns or fail cases? Meaning you hired person X in this archetype and you ultimately had to let them go. Is there threads that tie the errors together? 

Tara Seshan: One of the most common ones is that they're great in a way that the organization doesn't need. Like I can think of someone of this profile that we hired at Stripe to be a PM. 

This guy was super high potential. He had built a bunch of amazing apps. You talk to him and you can tell he has a ton of enthusiasm.

He got to Stripe and immediately it was clear that he was not PM shaped in this Stripe way. As in he like didn't wanna sit down and write a rigorous document on why this thing makes the most sense. Instead, he wanted to like do a bunch of research and ideate, or had a really hard time getting cross-functional buy-in on his thing, and Stripe really requires you to, you know, get legal on your side and get risk on your side and all that kind of stuff.

It was clear he couldn't do any of that. But he was really passionate about something else. And so he soon got really, really smart on that new domain. And Stripe was in this position of like, wait, this guy's clearly brilliant, but we absolutely don't have a place for him and he's researching this new thing.

Is it worth spitting up a new team just to support him on this new thing? Or should he just go do that somewhere else? 

And in the end, like, he went to go do it somewhere else and he's like doing an amazing job and he's like built his like own thing that is incredible. But he just wasn't a fit for the organization.

And honestly, that's the most common failure mode with this kind of thing where you hire someone who you do see glimmers of greatness in them, but they're just not great in the way the organization needs. And the organization like, organ rejects them in some ways for doing the thing that they are so great at.

Brett Berson: So given the few things that you tend to look for in this type of person, how does that map to when you actually sit down with them? Like what are you doing with that time, and are there other sort of inputs that allow you to forecast those three areas: hunger, horsepower, wins above replacement?

Tara Seshan: Yeah, it, it's somewhat these questions. So I mentioned for the, the horsepower question I asked them like, oh, tell me about something you've learned recently. Like hunger I'm probably not even talking to them unless they were hungry enough cause they're, you know, sending me YouTube videos and, and things like that to, to get in the conversation.

The wins above replacement, I'm looking for like that creativity and resourcefulness and I just ask them about their past projects. My opening question for those types of interviews is almost always like, tell me about your, like the projects you've worked on thus far. 

If your life is like a book, give me the chapter titles version and then I jump in on specific areas that I think have something that makes me wanna dig in further. And then I look for non order taking and follow through. Like if you ask people the standard, like what project are you most proud of? It's very telling to hear the type of story that they tell. The types of things that they're most proud of will almost always be things that are reflective of their, their strengths.

I think that, uh, if they don't give you a story that requires a lot of team coordination, you explicitly ask for that. Or ask for the thing that has the most people slash constituents involved to gauge whether they're a driver or a passenger on these types of things. Like that's a really important dimension.

Also another like factor that can hide folks, like make them really diamonds in the rough, is that, um, they might do high quality work in a low quality org. So they might be doing a lot of great stuff in a place that just doesn't, it isn't great. When you look at this, there's certainly some small signals that can help, like even like promotions and even a low quality org can be signalful.

But it just goes back to that feeling that I mentioned earlier, that this person is the person who's single-handedly dragged a thing across the line, despite the environment that they're in. And that they have a real chip on their shoulder given their background and a thirst to prove themselves.

Brett Berson: Looping back to where we began talking about multi-product, multi-business unit. Are there early products that you were involved with? Let's go back to the multiple product, same buyer that didn't work, and were there any interesting insights from that?

Tara Seshan: I think there was certainly a product, like a bunch of products that we thought were multiple product, same buyer that turned out not to be. And so we had a huge like crisis moment in the middle when we realized that the approach we were taking was not the right approach. So a great example of this was like, Billing at Stripe.

So Billing is this product suite that consists of subscriptions, invoices, revenue recognition, SaaS metrics. It's that whole like recurring revenue quote to cash part of the business. 

And we had naively launched it in the beginning in about 2018 with this idea like, oh, great, the same person who is integrating an API for one time payments is going to be the same person integrating and evaluating an API for recurring payments.

And so our approach for product development for this area was, I actually like, built a cohort of users that I wanted to stay really close to. And at the time it was like Notion, Lattice, like a few more who were all doing recurring payments. And so I just wanted to like be in their business all day, every day and see how the folks at those companies thought about subscriptions.

And I actually noticed a bunch of those companies had hit really fast growth inflection points very early on. And so in the case of Figma as an example, the person that we had talked to on a day-to-day basis used to be the engineer, and soon it became their VP of Finance. And I was like, oh no, I, we are not building product for this guy.

And this is a wholly different buyer and he wants things, I don't even know the words he's asking. And accounting, which may be very obvious to everybody else, but wasn't obvious to me at the time is like, wholly counterintuitive. Like everything doesn't work the way you think it should work. And it's probably because like Florentine bankers in the 14th century designed it, but it feels so tricky.

And so we were making a bunch of these product decisions, from first principles where it absolutely didn't make sense to reinvent accounting, um, to make this product work. And so we had a, had a sales team staffed up against this product. They had quotas and folks weren't hitting quota, um, because they were selling now to this finance buyer that it was like, your product doesn't make sense. It doesn't do the things that I want it to do. 

You all assumed that it was developers that you were trying to sell to, and certainly developers were involved in decision, but they're not the decision maker anymore, like the sole decision maker. And so we have to do this full rehaul of the products, like our invoices used to be stateless, and now we had to have a state of paid and unpaid, or like in progress or credit notes or those types of things.

We just had- ended up having to like meaningfully reevaluate what we've been doing. And it was because of two things fundamentally. One, we had assumed incorrectly who the user was of this product. And two, we had just under accounted for growth that as a company grew, the initial buyer and user.

Would not be the same as when it hit velocity. And that is a fundamental like engine of Stripe's business that the businesses you acquire in the early stage grow to become big. And we had just completely missed, um, that as a like, important dimension for how our users changed. And so it was a, it was a struggle for a while, like when sales are not hitting quotas, like everything is bad, um, within, within a product development team.

And so we really had to do a ton of reexamination of the product, what mattered, do expensive migrations and refactors to get, you know, invoices, to have states as an example. We got there after a, after a little while, but it was a like making that call of, oh wait, this is not working and I understand why and we have to make this switch like to account for a new user type, was an incredibly painful one.

Brett Berson: I mean, you mentioned this a little bit, but what was going on that set you up to get that wrong out of the gate?

Tara Seshan: I think it was because the, we were pretty new business focused. We were focused on the user at the moment of making the decision of whether to use Stripe or not for the cohort of businesses that were Stripe's core. So that is like startups who are, you know, monetizing for the first time. Who do they integrate to do subscription payments. 

And at that phase of company that is the developer, um, that is like a, it's a tiny company. They have like four people max at the whole company, right? Or maybe 10 if they're growing and scaling and are lucky. Like Stripe was becoming more mature.

We were selling to larger and larger companies over time, and those users were growing up. And so it was actually over the course of a couple years where the decision making power sort of shifted in our existing user base to more of a finance buyer. 

And that Stripe was now because we had an official Capital P product that was on the website with some landing page in the space, sales were also trying to sell this product out of the gate to larger and larger customers. And so it was like those two dimensions that changed who our user was, and made it so that we not only had to address the needs of a, you know, nascent just out of YC, uh, company that's trying to do SaaS, but also we started selling to Atlassian.

And their needs are just wildly different, uh, than, than that small company. And just goes back to the same APIs had to serve both. And so how do we balance both of those user needs in an elegant way? Giving the enterprises all the, you know, knobs and dials that they choose while still maintaining some sort of like simplicity and ease of integration for the small companies.

Brett Berson: Was it easy to make that decision in, in the sense that I think you could have had this aha moment, which is like entirely different buyer, massive overhaul of the product, let's just put a pin in that for now and go back to what are the needs of our core customer today?

Tara Seshan: I, I think the thing that forced our hand here, is we wanted to avoid the Heroku problem, right? Where it's you-, your users grow up off you pretty quickly. Again, the, the whole engine of Stripe's business is your users should not grow, grow off you like as they scale, you make more money and they make more money.

What really forced my hand is like if a Figma or a Notion or any of one of those companies would churn off of our subscriptions tooling onto something else. And so in many ways what guided our product development that we were really lucky, this is where you do have like really close users as design partners, is like those fast growing companies working with us to make sure that this product was something that they could continue to use.

And that's what really helped, um, make sure we did the right thing.

Brett Berson: Did you find that building the Billing product, as a way to allow your customers to grow and not leave you, set things up differently than if you thought about Billing to go after mid-market or upmarket out of the gate?

Tara Seshan: It's like always easier in a lot of ways to do the prevent churn off of you versus win someone out of the gate. Prevent churn off of your product the, you know, center of gravity is with you still. The user doesn't wanna do the extra work. In fact, like the finance user isn't very empowered to get engineering to reconsider and reintegrate and get a whole set of new APIs.

In a lot of ways, you have this captive customer who has given you their like, time and attention over years. They've integrated your product, they, they wanna make it work ideally. 

And so, it was, we were like, again, very lucky to have that flavor of the problem versus I think it would've been much, much harder if we had to, unseat somebody else, like have someone do a true rip and replace and get us out of there and, and get something new, in the door.

I also think just the pressure you have to be 10 x better at, at that phase than what whatever they had before versus we just didn't, we just needed to not suck with the, with the other way. 

Or at least we have the latitude at the beginning to just not suck. Of course, over time they would say, all right, and what else are you doing for me?

Every, you know, renewal, but in the beginning at least, it's like, make my pain go away. Don't yet, you know, knock it outta the park.

Brett Berson: What about, what's different about, if we sort of come up with these three different sort of categories of product. One is, products sold to the same buyer, same customer. The second is, same customer, the products sold to potentially a different buyer, overlapping buyer, overlapping constituent.

And the third is this idea of unlocking net new customers that wouldn't have been customers before. In that ladder camp, what's different about that in terms of people, org design, goal setting, sort of anything else that comes to mind?

Tara Seshan: One of the organizational things that's really important is give that team, treat it like a business unit actually, like don't treat it like a product team. So give them their salespeople, give them their sales targets, give them like the full end-to-end. They should almost feel like a startup within the company.

And I know that's a hackneyed phrase, um, but they should really feel like their own entity. Like they have their own, just about everything like including their, their marketing motion. 

I think also you really have to ensure that you're not, gauging their success the way you gauge the core businesses success.

So their sales targets look different. Their salespeople should be like, maybe you release them from, the same hardcore quota for a little while, so that they can help find product market fit. Again, you like staff your like founder seller type seller on that product area. 

You do not staff your like traditional like scaled seller on it. You put someone on there who can do their own sales enablement. The product manager might be doing sales and doing their own sales enablement as a part of that as well. So just a much, much, much stronger emphasis on these people basically have to act like a startup.

Sure, the parts that aren't like a startup is they're not like going out there and raising money for their thing and finding their own offices or whatever. But in some ways they are raising money from you, the rest of the company. Like you, the CEO and head of product, you almost treat them as if like, great, we're gonna have like, monthly board meetings and you tell me how you're doing.

Just like I tell our investors how we're doing.

Brett Berson: How do you think about prioritizing, right? When you think about kind of a net new buyer, net new product, kind of net new business, if you will. 

Cause in, in a lot of ways, you have so many more degrees of freedom. You can almost launch anything for anyone that's somehow related to the company. And so how do you think about we're gonna do X over Y? 

Tara Seshan: I think at the, the highest level, um, and especially for really early markets, which is what Watershed is in, like a market where we're still seeing a lot of it form, the important thing here is to have a view of what you want the future to be like. I think there is the Peter Thielism of like definite versus indefinite optimism.

Like you have to very definite optimism about how you want the space to shape up. You know, in 10 years every public company will need to do some level of carbon accounting and have a decarbonization plan to underscore that. Like carbon accounting has, unlike GAAP accounting has a really varied methodology.

Companies, um, are going to have to prove the efficacy of their methodology and will have to underscore that with a very in-depth decarbonization plan. And the best way for companies to decarbonize is through their supply chain and through buying clean energy. Like you have to have a very strong thesis for exactly what the future is going to look like, and feel like your product investments in the near-term are making that future happen.

You are both riding the wave and manufacturing the, the wave at the same time. In terms of where you're placing your bets, you're placing bets to hit near-term goals, but more importantly, placing bets to like feed that long-term outcome of that, that vision. 

And so in the case of, uh, Watershed, like it is a very early moment in Watershed's lifecycle to go multi-product. But we had to do so early because we think that the future is this integrated carbon accounting and decarbonization tool. Like you have to do both. 

That's what's like going to make people effective. That's what's going to make companies effective. And so it means early on in the product's lifecycle we had to spin up a decarbonization product, which is why we're investing in, in that supply chain area. And it does mean that you still follow all the same rules I mentioned earlier of like, you know, staff it as minimally as possible, more people doing stuff than people being brought along.

You want almost no one to be brought along. You want everyone, the team as lean as possible in terms of coordination. You give them their own go to market and then see how they scale. Like there, there is the same elements of that. But the like capital allocation decision on the like executive team part is given that vision, where should, like, where should we put the people and the money?

And it might be the right answer is like, just focus on the core, we're way too early. The core has gotta work and the core is the most important part of realizing that vision. Or you can make the call, wait a second, like this vision requires a couple interdependencies to exist and means we have to staff it earlier than we would otherwise.

Like to contrast Stripe and Watershed, the engine that powers Stripe is payments. It is payments. It's always gonna be payments like, payments is really, really vital. And Stripe should not have and did not like overreach into, multi-product before payments was like really, really, really working and like, working at the level of like, you know, we were fending off leads and letting them fall on the floor.

And in contrast, Watershed had to invest in multi-product really early because that vision requires that interlock. And so, you know, we weren't batting leads on- down and letting them fall on the floor, uh, before we invested in this, in this supply chain bet.

Brett Berson: I think you're sort of getting at this, but I'm really interested in the topic of 'when'. And we could talk about 'when' in either of the three cases that we've outlined. But given your experience, what have you learned about when to do any of these things, and how much of it can be done in a methodical way versus just an intuitive way?

Tara Seshan: I think the methodical answer to that question is there's a few ways for the company to grow, right? Like, expand into a new market via going into new countries, expand into a new market via going into a new product area that sells to a new buyer, like as you mentioned, like capture more TAM, sell more to your existing buyer or raise your prices.

Those are pretty much the options you have. And so whenever the company needs growth or as you anticipate needing growth, like you look at your- great, we need to hit these numbers. And this is where these, each of these dimensions come in, at some point we'll need to launch another product or launch another geo or raise our prices or, you know, launch another feature to charge more. 

And so you could come at it via a very analytical lens in that way, which is, we will do it whenever it's necessary so that we can grow the way we need to grow. We'll pick our option amongst those four based on how the product is resonating in market today, the, you know, willingness to pay of our buyer, the, like, potential advantages we have on adjacencies or like, how the geographic landscape is looking and our go-to-market engine desire to push in that direction.

Um, that's a really analytical answer. And Stripe often takes that very analytical approach, right? Like I mentioned, Patrick thinks backwards when you put a bet in front of him. Like, Hey, how is this gonna add $10 billion in enterprise value to Stripe?

But while I was, you know, at Stripe, getting that sort of like rigorous pressure from Patrick I also looked at like Jack Dorsey, right? And Cash App. The early story of Cash App seems to be the exact opposite. Where Jack Dorsey was like, you know, I have this intuitive belief that people people need payments to work this way.

We need to, you know, empower the masses to be able to be banked when they're underbanked. And I think a product of this shape can do it. And they kept plugging at it for years and years and years without like a, you know, super concrete business plan saying we're gonna make this thing happen. And, you know, true enough, now look at how successful Cash App is and what a giant part of the business it is. 

And so I, I don't wanna diminish that as a hugely driving factor in when you should be multi-product. Like, making those calls based on instinct has like sometimes helps you hit, you know, home runs rather than hit a bunch of like singles and doubles.

The analytical approach will get you a lot of like doubles and triples. Um, but I think the home runs really come from this like, intuitive call for like, how do I think the market is going to work? How do I think the world is gonna work? And like, let me make this bet in that direction.

Brett Berson: What about the concept of like organizational atrophy or developing this muscle. Like one of the things that, that I think some companies forget is that this work either of building a net new business, selling multiple products into the same buyer, et cetera. One of the issues with waiting a long time, which I think is conventional wisdom, is that the org doesn't develop the capability. And so you end up in year seven, okay, time for our next act or time for our second product or whatever.

And for a whole host of reasons, it, it tends to be hard just to sort of snap your fingers versus, I don't know, Atlassian, I think has done one of the best jobs of any company of doing this. You know, in year two they had their second product, and maybe that's survivorship bias and there's less to learn from there.

But do you think at all about like organizational muscle to do this well and how that maps to when you should consider any of these ideas?

Tara Seshan: I mean, I think it's, it would be hard to say that folks should do this early for the sake of building the muscle alone, just because the cost of doing it is quite high. And I actually am curious, I wonder how much an escape hatch things like acquisitions are. Like Atlassian famously, you know, very acquisitive as a business.

And one of the ways it's very successful in being multi-product is by buying a lot of their additional like product bets because they've also ascertained that all those things working super well together is not the main priority. Like it's important that Consul and Jira and Jira help desk and those types of things work well together, but maybe not like, I don't know, Trello, like the, the users are too different and it, and it's separate.

So I, I don't think there's a one size fits all recommendation on when companies should have this muscle, nor do I think that it's like a trap door decision that you can never develop this muscle, later on. 

But I do think that one of the most common reasons for this not working within companies is that, people judge the net new bet by the same yardstick that the rest of the company is judged on.

And that is not just an executive decision, it cascades all the way down. Like the sales manager who is thinking about like letting a seller go enable a net new product, will they allow for that seller to have like a slightly alleviated quota to make that happen? The marketer like, oh, well, you know, I stack ranked the impact of all of my stuff and you know, your thing falls to the bottom cause it's a new product like it's not gonna have as much impact as the other thing.

Those decisions happen throughout the organization all the time. And I think there is an important cultural motion that has to come from the top or from leaders that is like a, we are taking that new bets because we have to. Those actions are not going to be as efficient as betting on the core, but if we don't do it, we'll never have a successful business and like painting the vision of what that future looks like.

In 10 years, like this is what we want to be true and these are the components of that. It doesn't have to get that specific, but you can have these predictors of what the world will look like. And then sharing how like an integrated suite of products makes that happen helps people just also realize that importance.

Brett Berson: Can you share anything on rituals or documents or meetings or goal setting around this area of net new bets and sort of any of the three categories that we've talked about?

Tara Seshan: I think I mentioned with, with net new bets, especially ones that have a, their own go-to-market, selling to a new buyer, selling differently, you almost wanna treat the team as if you were their board and, and they were starting a startup in some ways. Like you're being a lot more hands-on than a board is.

The most important tool is like a QBR. You get them to put their numbers up top of the goals that you agreed on, have discussion of what are the things that are working, what are the things they're not working. 

And regularly ask them that same set of questions of why now? What's the thing that's happening in the market? What are all the hypotheses that we considered in terms of our ability to win here? What do you think our advantages and how are you using the company's advantages to build this net new product? And then how is it going based on our criteria we established to win?

And what's changed about your beliefs as a result? Like you just have to constantly ask them those same, that same set of questions and a QBR is the right way to do that in terms of just bare minimum level of check-in. But I also do like a monthly product review where I talk through these types of details.

And if it's a product, again, like I mentioned, the sell to the same buyer sort of thing. You wanna be really, really in the product details with them. In terms of that thing working well with the core,. The team's instinct is almost always going to be like, Hey, we're building our new thing and we have so many important questions to solve about whether people care about fraud management or not.

They're gonna underemphasize the compatibility with the core business. And so you're constantly looking at the UX to make sure that those things go well together. I think other rituals like also just goes back to who you hire, like hire ex founders for these types of founder-esque bets. 

They will be able to handle the ambiguity and they'll be able to rally the team and to think outside the box of their role in a much better way.

A lot of the PMs that we've hired to do that type of work are ex founders. And that was true of Stripe as well.

Brett Berson: just on the point about monthly product reviews, whether it be in this style of product building or kind of, kind of working on the core, how have you ended up running them and designing those?

Tara Seshan: I have a set of 12 questions that I ask in every product review. And there's a very strict guidance of like, you cannot move on to question two until you've sufficiently answered question one. And question one starts off like very basically who's, who's your target user? 

And I love to, in that context of who your, their target user is, bringing that classic Enterprise Rent-A-Car example.

if this is like apocryphal or a real story. But when I tell it regardless all the time anyways, which is that when Enterprise Rent-A-Car was getting started, they were competing in a field with like Hertz and Avis and those guys had the airport real estate and they had the, like Audis and BMWs and Enterprise Rent-A-Car really had nothing.

And so there was absolutely no way to compete building the quote unquote best service or best product because they couldn't afford the cars and they couldn't afford the real estate. what they did instead is said, our focus user is going to be people who get into car accidents and our great feature is going to be car crash pickup.

And that means that we don't need great real estate. And actually the great car doesn't even matter because these people just want a car while their car is in the shop. And it allows us to like have a wedge in a specific market segment, without being the best. And over time certainly expanded and I, I, believe now they're one of like the foremost car rental services.

But it kind of started by making a very, very opinionated bet on who your target user is and allows you to compete on dimensions that other services and tools just find irrelevant. And so I constantly recite this story to my team just to underscore the importance of like, your target user is the most important question full stop for your product area. 

Like that is the best strategy choice you can make. And so if you cannot clearly outline to me who your target user is and why, and therefore like, you know, as you go through my set of questions like what features follow that are great for that user, like why are those features uniquely suited to that user?

It's, it's you know, dead in the water. It's, it's gotta be specific.

Brett Berson: are you able to rattle off the questions? 

Tara Seshan: okay, so my questions are like, who's the target user? what is the user need we're solving for? Like, give me a link to your evidence of why that need is actually a need and not a made up need. Um, how do we know we've solved for that need? How do we know it's self-serve and operations free?

That's a very specific question for the like, type of enterprisey strategic user type business that we're in, that it can often be easy to compensate with services, what a product should be doing. Um, what is a range of solutions to get us there? Like, it's always easier to agree on one solution if you've thought about alternatives. Uh, how have you leveraged the advantages that the company has?

In Watershed's case, it's like a ton of climate specific intelligence and reference data. And so at Stripe it was, you know, all kinds of Stripe assets, like the adoption of the API and our existing user base and our payments expertise, et cetera. But I do ask like, how are you leveraging the company's existing assets?

What's the intended experience from the user's point of view? And so this is where I love people to like, at Stripe like give me API docs and so I can like try integrating it myself or like show me with a user story, what are the requests the user makes at every sort, sort of step of the way. 

How quickly do we start learning whether our solutions are the right ones? Like what is the criteria, um, by which we'll evaluate that. So this is like, what are your success metrics and let's get into a ton of details there. What do we actually build to provide this experience? And so include all of your key assumptions and challenges.

then last, like what's the plan to build it? So what's the work to be done? You know, the operational model, any risks or open questions. But those are my product review questions.

Brett Berson: And when you do a product review monthly, you run through all of them?

Tara Seshan: It depends on the team. So again, I, I don't proceed to the next question until the questions at the top are answered. So sometimes a team will come to product review and say, I've only answered four. Um, but we're gonna spend a ton of time on the, like, all the evidence I've collected for why this is a user need, help me interrogate whether it's a user need or I just have happy ears right now.

And I was like, great, that sounds like an awesome product review. Let's run through that stuff. Um, Sometimes teams will say, great, well, I answered one through six in the previous review. Now let's get into details about like the intended experience, like walk through the product in a ton of detail and then we'll talk about early user feedback as to whether this is the right solution or not.

So it's not all the questions in every review. 

Brett Berson: 

Do you normally have this written out in a doc ahead of time or this is how you verbally sort of run the meeting?

Tara Seshan: It's all written down in a doc ahead of time. 

Certainly you don't have to write reams and reams of prose like write the thing at the beginning and then link me to a bunch of evidence that you have otherwise. And I'll usually pre-read that before the meeting and then come in and try to make it all discussion.

Brett Berson: So how did you land on this?

Tara Seshan: I think most times when teams are coming to you, uh, with the thing that they've built, they will gloss over some of these early stage questions. 

Um, they'll come straight to you being like, this is the product experience. And no matter how good anyone is, as a, as a evaluator of software, if you're building something where you are not the user, you are going to need some amount of like context as to who the user is and how those assumptions are formed to be able to evaluate what's important. 

Uh, what you really want is to give the right critique and the right guidance, and where should you push next in terms of evaluating your hypotheses.

Ultimately, you're trying to build something that wins, and so no one expects anyone to get anything right on the first try. Like software is never done. And software is always bad in the first version of it. 

And so, with the assumption that you are looking at a bad piece of software because it's the first version that someone's built it is very hard to evaluate a bad piece of software without context. And so these questions are mostly meant for two things. One, how do I get context? And two, let's say a team went through all these questions and then the product review was canceled somehow. Like maybe I had an emergency or whatever.

Was it a waste of time for them to do this? Were they just prepping it for me? Or is it useful thinking for their actual product development? And my goal was to make it actually useful regardless. Like I fill out these questions honestly when I'm building something. Like I still, I CPM a team and I review my own stuff. But I also fill out these questions, um, because it's just, it's just the questions you should answer for any product.

Brett Berson: Do you adjust the questions or emphasize certain questions with different importance when you're doing net new bets or net new products?

Tara Seshan: Yeah, I think, um, the question of how quickly do we learn whether our solutions are the right ones, which is like my question nine or so. Um, I tend to really, really emphasize that for new bets. Especially the speed thing, because if it's a new bet that has its own go-to-market as, as we've talked about, like something that's going to be sold to a different buyer in a totally different motion, that's just gonna take longer.

And so the thing I ask for with that question is, short of doing a full sale cycle, cause you're gonna have a lot of fits and starts with that. Like what are ways that you're learning whether this thing makes sense and is right? 

Like are you maybe looking at like competitor sales? Are you like doing a ton of user interviewing? Are you, another really great example is sometimes, when folks are selling to CFOs, you go do a, like, practice sell with those contract CFOs and see whether they find the product interesting or resonant.

Like I always ask for creative ways that people are getting at that question with a net new product. Cause if you're just waiting until they close their first deal, it's gonna take way too long. 

Brett Berson: When you are spending time with customers, it could be an existing customer working on a new sort of part of the product, it could be a net new customer. Are there any little things or ways that you spend that time that you find really useful for informing what you're building, how you're building it, how you're selling it?

Tara Seshan: Um, there's that like David Ogilvy quote that, executives use research rather than judgment when it comes to evaluating something akin to how a drunkard uses a lamppost for support rather than illumination. Like I think sometimes, especially with enterprise, we over rely on research or RFPs or the things that customers say.

And I think in my mind, the best product stems from a very, very strong mental model of the domain and the users like and UXR can help you get to such a model, and validate it along the way. But it's important to view the sort of syllogism as UXR, model, product, not UXR to product. 

And the main way to do this is like, have your hypotheses and have your model prior to going into user conversations. And when you're in the user conversation, um, you're looking for just a couple anecdotes, like in a couple pieces that helps prove the user need.

And then later on when you're like, when you've actually got the product, the user might be testing it or using it. Um, something that a really great user researcher once told me is go into the pro- the meeting, like expecting the user to sell you on the product. Um, rather you selling them. Like your default skepticism should be so high that the user is actually trying to convince you that this thing is necessary.

Um, and there's a bunch of tactics and ways to do that, but sometimes it ends up with the user being like, no, no, no, I promise it is useful. Like I'm using it in these five ways. And you just wanna let them feel that they have room to say that this thing is useless and they actually don't engage with it, and it's not really the right thing for them.

And if you're selling it to them, they're more likely to say yes, yes, yes, than the things you wanna hear, versus if you're default skeptical. And in fact, almost like not even owning the product, like, Hey, this is the thing my buddy designed. I don't, I don't think it really works. You tell me what you think. Like that, that's much, much better as a way of evaluating something.

Brett Berson: When you explain the idea of developing a model, can you give an example to bring that to life in terms of what, maybe in the context of Watershed, other products you've worked on, like not the product or anything, but what your well formed model looked like?

Tara Seshan: A good example is like the classic early days of Stripe on how the UX of Stripe JS should work. So back in the day, the context was like the best alternative was PayPal. Like everyone was using this like tool that did a full page redirect to PayPal site where they collected a bunch of information about the customer, they checked the customer out.

The customer's landing page at the end of that checkout was still PayPal. Um, and then you could maybe click a button to re re navigate right to the site, like the payment experience was so, extra like systemic, like it was, it wasn't at all in control of the developer. It wasn't at all in control of the product.

It was so out of the, um, it was so outta the experience and the like opinionated set of principles that Stripe came up with was like, developer focus payments experience will let developers like build the entire UX of Stripe or of their payments, like without having this like giant redirect, we'll make as few pixels as possible, Stripe and everything else will be the developers to design on their own. 

Like there was a strong belief that giving people autonomy and letting them design on their own was, was the right like model and solution.

Brett Berson: What were the inputs into that?

Tara Seshan: You should be spending all your time trying to validate, like is the problem, I think is a problem actually, um, an issue for companies and do they feel it urgently? Um, does it matter enough? Like is it on their top five things that they're worried about? If yes, then great.

Now I know the problem's a problem, like I'm going to come up with a set of principles about what the solution should look like and design a version of the solution. And then I'm gonna research whether the solution is actually solving the problem. But your inputs into forming principles is always just like problem validation, at least in my mind.

Brett Berson: To wrap up, I'm curious, when you think about this sort of broad area of new bets, is there someone who's had an outsized impact on the way that you think about this work? 

Tara Seshan: I think of course, um, working at Stripe for so many years, um, getting the, the Patrick calls and like grilling of why your proposal makes sense has just introduced a ton of rigor. And to, to how you think about it specifically the 'why now' question. Like Patrick would always remind everyone, Hey, Stripe has 9 million opportunities in front of it like, why this opportunity and why now? 

I think the other person who's really shaped the way I've thought about this is, I used to have a manager at Stripe named Shreyas, who's now very Twitter famous or like famous across the internet. Um, but I was lucky enough to, to work for him for, uh, a year.

And Shreyas is the person who told me about, like, it's all about the target user. You just gotta make sure you pick your target user correctly. Like everyone always, um, everyone always like overestimates the impact of like specific features and being the best product, like being the best product is not an answer.

You have to be the, like, the right product for your target user. Um, being the best means nothing. 

Brett Berson: Great. Perfect place to end. Thank you so much.

Tara Seshan: Thank you Brett. Really appreciate it.