“It’s not about building the best product. Being the best means nothing.” For product builders striving for perfection, these words might not seem particularly motivating, but for Tara Seshan, this advice is a phrase she returns to whenever she’s considering where to place a new product bet.
Before her most recent role as Head of Product at Watershed, Seshan spent a nearly seven-year stretch at Stripe. She joined the company at the sub-200-person mark in 2015, back when “there was still very little adult supervision” as she puts it.
Seshan spent a year of that tenure with Shreyas Doshi as her manager, from whom she picked up this lesson originally. “Everyone always overestimates the impact of launching specific features and building the best product, but that’s not the answer — you have to build the right product for your target user,” she says. Sounds simple in theory, but tough to consistently pull off in practice, particularly as a scaling startup takes bold swings at building out its product lineup.
Seshan makes an excellent guide on this topic, as she has a deep well of experience to draw on here. She was the PM on Radar, Stripe's first monetized product outside of core payments, and she helped scale Billing and Treasury from 0 to 1 as a product lead and GM.
In this exclusive interview, Seshan shares nine lessons from her playbooks for going multi-product, drawing on examples from both Stripe and Watershed. From advice on how to get the timing right and different ways to approach the problem of what to build, to tips for hiring great product thinkers and the specific steps she uses to run effective product reviews, founders and product leaders alike will walk away with tons of put-to-use tactics.
LESSON #1: Choose carefully from the multi-product menu
When Seshan joined Stripe in 2015, it was a one-product shop. “It was the core payments API, we hadn’t even launched any other payment methods out of beta yet,” she says. But the journey of moving from a single product to a wider array of offerings isn't as simple as bolting on new features or spinning up new teams — it requires a carefully chosen strategy. Here’s the menu of options, along with the pros, cons, pitfalls to watch out for, as well as insightful anecdotes from Stripe:
Same customer, same buyer
“If your product has initial product-market fit for a core user, what else does that specific user want that would make their job better? Think of the classic line that your B2B buyer wants to get promoted — what can you give them to help make that happen?” says Seshan.
“When Stripe was thinking about second products, one of the easy angles was asking first, Who is our buyer? It's that developer who's integrating payments early on. And second, what could you give that same buyer to make their lives meaningfully better?” she says. “One thing that sucks about taking payments on cards is fraud — and so that's how the fraud product, Radar, came about. We were able to narrow down the set of features that made a difference for that same user.”
It can be really fruitful to sell something else to your same buyer. You know that user and you know their needs. You’re much more likely to succeed by giving them an additional product rather than trying to launch a product that targets something wholly new altogether.
Same customer, different buyer
That laser focus on the customer can quickly turn into blinders, however. “There were several products that we thought were the same buyer that turned out not to be,” she says. Seshan cites the origin story of Stripe Billing, a suite that consists of subscriptions, invoices, revenue recognition, and SaaS metrics.
Seshan spearheaded the product’s launch in 2018, but it wasn’t a resounding success initially. “We had naively launched it with this idea that the same person who was integrating an API for one-time payments was going to be the same person integrating and evaluating an API for recurring payments,” she says.
Developers were still involved in the decision, but they weren’t the sole decision-maker anymore. “We were selling to larger and larger companies over time, and those users were growing up. We had customers like Notion and Figma, and we had just under-accounted for the fact that the initial buyer and user would not be the same when the company hit velocity. At Figma, the customer we talked to on a day-to-day basis went from an engineer to their VP of Finance,” she says.
“And so we were making a bunch of product decisions from first principles but it absolutely didn't make sense to reinvent accounting to make this product work. We had a sales team staffed up against this product, and folks weren't hitting quota because they were now selling to this finance buyer even though we weren’t meeting their needs. For example, our invoices used to be stateless, and now we had to have a state of paid, unpaid, or in progress. It required a ton of reexamination of the product, with extensive migrations and refactors. We got there after a little while, but we had to change our approach.”
New customer entirely
But new product ideas can spring from entirely new wells. “The other dimension of thinking when you’re going multi-product is if it allows you to unlock a net new user base that you weren't targeting before.” Seshan cites Stripe Connect as an example here.
“We were targeting folks who were taking, for lack of a better term, ‘vanilla payments,’ so we started to think about a tool that could take on more of the complexity for those building a marketplace business — the underwriting of initial accounts, the routing of payments, the balance calculations.”
LESSON #2: Tease out your vision and focus on making the “why now” case
Timing is perhaps the trickiest part of figuring out your multi-product strategy — how do you thread this needle? “One school of thought is we’re way too early, just focus on the core, that’s the most important part of realizing our vision. Or you can make the call that the vision requires a couple interdependencies to exist, which means you have to staff it earlier than you would otherwise,” says Seshan.
Both Stripe and Watershed have approached this crossroads quite differently. “The engine that powers Stripe is payments. It's always going to be payments. And so Stripe didn’t — and should not have — overreached into multi-product before payments was really, really, working — at the level of we were fending off leads and letting them fall on the floor,” she says.
“And in contrast, Watershed had to invest in multi-product really early in the company’s life cycle. But we had to do it early because we thought that the future is integrated carbon accounting and decarbonization tools — you need to have both to make companies effective. That vision requires that interlock. And so we weren't batting leads down before we invested in a new bet.”
With either path, however, there has to be a compelling answer to “Why now?” Seshan says. “What makes this idea something we have to do now, something we can't do later? Is there a unique at-bat for it at the moment that makes this something we have to jump on?”
When it comes to a second product, there are so many things you could build that there has to be some intersection of the moment and the opportunity.
The stage of your company, of course, also plays a role here. “As Stripe got larger and larger, the question became not only why now, but also ‘What's the opportunity on the table for this idea?’ Patrick’s bar was, ‘Is this going to add $10 billion of enterprise value to Stripe? Could you paint for me a path where that could happen?’ He would always remind everyone that Stripe has 9 million opportunities in front of it — why this opportunity and why now?” says Seshan. “At a much earlier stage for Watershed, it was instead a question of how costly is it to develop an initial hypothesis? How lean can we go and how fast will we know if it is or isn’t working?”
LESSON #3: Think through whether you’re making calls on analytics vs. instincts when you’re trying to score new runs
Digging deeper into the question of when to launch a new product, Seshan notes that there are two different approaches:
“The methodical answer is that there are only a few ways for a company to grow: 1) expand into a new market via going into new countries, 2) expand into a new market via going into a new product area that sells to a new buyer, 3) capture more TAM by selling more to your existing buyer or 4) raising your prices,” she says. “From a very analytical lens, you’ll pick among those options based on how the product is resonating in the market today, the willingness to pay of our buyer, the potential advantages we have on adjacencies or how the geographic landscape is looking. Stripe often takes that very analytical approach and Patrick thinks backwards when you put a bet in front of him.”
“But consider the early story of Cash App, which seems to be the exact opposite. Jack Dorsey had an intuitive belief that people needed payments to work this way and they needed to empower the masses to be able to bank when they're underbanked. And so they kept plugging at it for years and years. And now look at how successful Cash App is and what a giant part of Square’s business it is. So instinct can be a huge driving factor in figuring out when you go multi-product.”
The analytical approach will get you a lot of singles and doubles. But the home runs really come from those intuitive calls on how you think the market and the world is going to work and betting in that direction.
LESSON #4: Bring a dose of definite optimism to your thesis
“Particularly when you’re in a really early, developing market, the important thing is to have a view of what you want the future to be like. There is the Peter Thielism of definite versus indefinite optimism,” says Seshan (a Thiel Fellow, we'd note).
“You need very definite optimism about how you want the space to shape up. For Watershed, here’s what that looked like: In 10 years every public company will need to do some level of carbon accounting and have a decarbonization plan to underscore that. And the best way for companies to decarbonize is through their supply chain and through buying clean energy. You have to have a very strong thesis for exactly what the future is going to look like, and feel like your product investments are making that future happen in the near term.”
You are both riding the wave and manufacturing the wave at the same time. You're placing bets to hit near-term goals, but more importantly, to feed the long-term outcome of your vision.
LESSON #5: Keep it lean by assembling self-sufficient business units
Figuring how many eggs to put in each product basket is another challenge teams grapple with. Seshan’s rule of thumb? Initial secondary bets outside the core can't be expensive.
“At Stripe, core payments took maybe 75% of the engineering bandwidth. Part of what incentivized the early team to work so hard on new ideas was that you got very few resources. You had three or four engineers and you were trying to get a proof of concept really fast, to earn your way to more resource allocation,” she says.
That meant, while proving out an idea, teams had to get scrappy. “For Radar, the fraud product was still built for developers, so we didn't need a ton of user researchers. I was selling and doing the product design, and then also going into our models and trying to write human-readable explanations for why the model scored things in certain ways. It took the communication coordination cost out of that initial product building entirely — until it became clear that it was worth paying that for additional velocity.”
Don’t overfund your new bets. In that early stage of trying to establish something, more resourcing actually holds you back. You want as few people as possible with the maximum number of skills.
That may seem counterintuitive, but as Seshan sees it, you want more people doing stuff than people being brought along. “You don't want the team to have strong dependencies on any other part of the company. They don't have to be great at all of those things, they just need to be willing to do it.”
Here’s how to think about it from an org design perspective: “Treat it like a business unit, full end-to-end with their own salespeople, targets, and marketing motion. Do not staff your traditional scaled seller on this. You need a founder-seller type, someone who can do their own sales enablement. The product manager might be doing sales as a part of that as well,” she says.
“‘A startup within the company’ is a hackneyed phrase now, but they should feel like their own entity. Obviously, they aren’t going out there and raising money and finding their own offices. But in some ways, they are raising money — from the rest of the company. So as the head of product or the CEO, have ‘board meetings’ where they tell you how they’re doing, just like you tell your investors how you’re doing.”
Treat the team as if you were their board and they are starting a new startup — but be a lot more hands on than a board is.
LESSON #6: Run these highly structured product reviews to stay on track
If you’re looking for ways to structure those regular check-ins on new product progress, Seshan cites Stripe's processes as one well worth adding to your toolkit.
“Of course, there’s the QBR, which is an important tool and a bare minimum level of check-in. But Stripe would also do a monthly product review to dig into the details. Specifically, there is a set of 12 questions that Stripe leaders ask in every product review. And there's a very strict guidance that you cannot move on to question two until you've sufficiently answered question one,” she says. “You don’t get to all of the questions in every review. Sometimes a team will come in and say, ‘I've only answered four, or I answered one through six in the previous review, now let's get into the others.”
The key here is not letting folks skip over some essential context-setting by jumping right into the product experience.
You're trying to build something that wins, and no one gets anything right on the first try. Software is never done and it’s always bad in the first version. But it’s very hard to evaluate it without any context.
“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 but then the product review was canceled. Was it a waste of time? 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. I honestly fill out these questions when I'm building something because it’s just the questions you should answer for any product.”
With that context, here are her questions in full, with commentary on what to dig into:
-
Who is the target user? “This question always brings me back to the Enterprise story,” she says. (Yes, the car rental company.) “Not sure if it’s apocryphal or a real story, but I still like to tell it. Enterprise was competing with the likes of Hertz and Avis. Those guys had the airport real estate. They also had Audis and BMWs. Enterprise Rent-A-Car really had nothing. And so there was absolutely no way to compete by building ‘the best service’ or ‘best product.’ What they did instead was focus on a different user — people who get into car accidents,” she says. So instead of focusing on providing fancy vehicles, Enterprise offered a unique crash pickup service. “Over time, they were able to expand. But it started by making a very, very opinionated bet on who their target user was and it allowed them to compete on dimensions that other services and tools just didn’t find relevant. It is the most important question to ask, full stop. If you cannot clearly outline to me who your target user is and, therefore, why the features follow are uniquely suited to that user, it’s dead in the water. It's got to be specific.”
-
What is the user need we’re solving for?
-
Can you share a link to your evidence of why that need is actually a need and not a made-up need? “Is it a problem that’s actually an issue for companies and do they feel it urgently? Does it matter enough? Is it on their list of top five things that they're worried about?”
-
How will we know if 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 type of enterprise, strategic user type business, where it can often be easy to compensate with services, instead of what a product should be doing.”
-
What is a range of solutions to get there? “It's always easier to agree on one solution if you've thought about alternatives.”
-
How have you leveraged the company’s existing assets or advantages? “In Watershed's case, it was a ton of climate-specific intelligence and reference data. And at Stripe it was the adoption of the API, our existing user base, our payments expertise, etc.”
-
What is the intended experience from the users’ point of view? “At Stripe, I would love for people to give me API docs here so I could try integrating it myself. Or it could be showing me with a user story the requests the user makes at every step of the way.”
-
How quickly will we start learning if our solutions are the right ones? “I always ask for creative ways that people are getting at this question, especially with a net-new product that’s going to be sold to a different buyer in a totally different motion. If you're just waiting until they close their first deal, it's going to take way too long. And so the thing I dig for is, short of doing a full sales cycle — because you're going to have a lot of fits and starts with that — what are ways that you're learning whether this is the right move? Are you looking at competitor sales? Are you doing a ton of user interviewing? Say you’re selling to CFOs — will you practice selling with those ‘contract CFOs’ and see whether they find the product interesting or resonant?”
-
What are the criteria will we use to evaluate that the solution is the right one? “I like to ask what are your success metrics and let's get into a ton of details there.”
-
What will we actually build to provide this experience? “Now I know the problem's a problem, 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. The classic early days of Stripe are a great example. There was a strong belief that giving developers autonomy and letting them design on their own was the right model and solution.”
-
What is the plan to build it? “What's the work to be done? The operational model, any risks or open questions, and so on.”
LESSON #7: Change up your customer discovery to get the customer to convince you — not the other way around
As Seshan noted, while these questions apply to building any product — flagship or freshly conceived — new bets in particular need a strong answer to question number nine: How quickly do we start learning if our solutions are the right ones?
Avoiding the happy ears problem is especially important here. “Something that a really great user researcher once told me is go to the meeting expecting the user to sell you on the product, rather than you selling them,” says Seshan.
“In fact, you can even take the approach of almost not even owning the product, like, ‘Hey, this is the thing my buddy designed. I don't think it really works. You tell me what you think.’ You want to let them feel that they have room to say that this thing is useless and it's not right for them.”
Your default skepticism should be so high that the user is actually trying to convince you that this product is necessary.
LESSON #8: Hire for potential diamonds in the rough
In the jump from single to multi-product, Seshan doesn’t sugarcoat it —– this isn’t for everyone. “There are certainly some people who are suited for this type of thing and some who really aren't,” she says. “For new product bets, I strongly index toward hiring people for potential, not necessarily for experience. The hungry and high potential person who's dedicated to growing quickly, can build more value for the business than a status-y or experienced person who is less high potential,” says Seshan.
“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.” Seshan relies on the following specific criteria to help her find the diamonds in the rough:
- Hunger: “Do they go above and beyond to show their interest? Do they message you repeatedly? Do they do something special to set themselves apart? I had a candidate who made me a YouTube video of why they want to work at Watershed, which sounds random, but these signals actually matter,” says Seshan. “If they’re showing they're hungry now, they'll be hungry on the job.” Look for how they’ve shown hunger in past experiences — perhaps from getting their past job in an unusual way, making opportunity materialize from nothing, or simply starting something of their own.
- High horsepower: “If they don't show high horsepower in some way, then it's an immediate no,” says Seshan. “Do they have a great side project? Do they write very excellent blog posts or documents or articles that show incisive analytical chops?”
- Wins above replacement: Another sports metaphor, but in short, hirers should ask: “Does this person do better than the other person at their same stat level because of some ineffable quality that they bring to the table? Separating their actions from those of their team or the circumstance — would the end result of the thing they did have been significantly worse without their involvement?”
- Drag things across the finish line: “Most smart people are actually terrible at having the drive or follow through to take the thing over the finish line. I remember back at Stripe, we were interviewing a candidate who came from Bain, and often they just want to focus on strategy. But this guy had implemented a call center project and stayed on the project three months longer, visiting the call center and taking calls with them just to see how it went.”
Of course, it’s much easier to probe for these traits with a set of interview questions. Seshan shares her favorites below:
- Tell me about something you learned recently. Did they learn about something complex? Can they explain it really well? Do they show understanding of detail?
- If your life was a book, give me the chapter titles from your birth till now. "When you get the full story, dive into each 'chapter' and hunt for their real stories."
- 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 strengths. If they don't give you a story that requires a lot of team coordination, you explicitly ask for that. Ask for the thing that has the most people or constituents involved to gauge whether they're a driver or a passenger.”
For even more on this topic of finding diamonds in the rough, Seshan wrote more on this topic in her newsletter recently.
LESSON #9: Pull out a different yardstick to measure the success of new bets
When it comes to new product ideas not panning out, one common failure mode Seshan flags is judging 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 throughout the organization. The sales manager who is thinking about letting a seller go — will they allow for a seller to have a slightly alleviated quota to make a new product happen? The marketer who is stack ranking their work might let the new product fall to the bottom because it’s not going to have as much impact as the core product. Those decisions happen throughout the organization all the time.”
There is an important cultural motion that has to come from the top. Leaders need to say, “We are taking that new bet because we have to. Those actions are not going to be as efficient as betting on the core product, but if we don't do it, we'll never have a successful business.”