Building Products at Stripe

Created

Jan 19, 2023 8:01 PM

Go deep and move fast

Ken: I’m struck by the juxtaposition between moving fast but going deep. Is there sometimes tension there?

Michael: Those things can sometimes be in tension, and it can be difficult to strike exactly the right balance. But the way that I think about it, if you know where you’re trying to get to, then you can afford to go really deep because your effort is focused in the right direction.

Stripe runs on written long-form documents in a way that I haven’t seen before. So that means somebody can go deep, like all the way down, and then distill it back out to everybody else. So you don’t have to do all of that work yourself. It does require a lot of reading for sure, but the benefit is great clarity of thought on complex topics.

Engineers, partnerships, PMs, everybody is producing documents. That’s part of how Stripe has always worked, from a perspective of trying to get to the right answer and make sure the best ideas come through, not just the loudest voices. It helps facilitate the flow of information in a world where we’re increasingly remote.

Product “shaping”

Ken: Walk me through a typical new product or feature. How does it start?

Michael: We expect every product manager to be actively talking with customers and really spending a lot of time understanding customers. But it’s not just a product management thing. Engineers are expected to be talking with customers as well.

So a lot of the time, you’re starting from an actual user need that an actual person has expressed to you directly. And then they’ll either tell you what the product is that they need because it’s adjacent to something that we’ve already built, or you understand their problem, and then you go design the right product to solve it. And then you can take that and test it with those same customers. A rapid iterative loop with the right customers solves for a lot of common product development pitfalls.

At Stripe, we talk about product “shaping,” which is a term I hadn’t encountered before. Shaping is the process of creating a rough solution to a concrete user problem — it fills the space between the broad strategy and the detailed product specification, or the PRD. This process frontloads a lot of the critical thinking about what you’re planning to build and why. Still, you haven’t necessarily fleshed out the requirements in a way where someone could go and implement them yet.

The product shaping document will come at it from the perspective of a user. And, you know, a lot of the time, those look like a description of a user story, and you’re walking through a story interspersed with code snippets because a lot of our products are APIs. These documents are basically walking through someone’s experience, and there are curl commands here and there showing how everything is done via an API at each step. They play the role that mocks or wireframes might play in a consumer product UI.

Creating a new ACH charge using Stripe’s Payments API on the command line

Ken: A challenge I hear from B2B companies is once you reach this level of maturity, you have big customers who are asking you for something specific. And the mistake that a lot of companies make is to just build whatever the loudest customers are asking for, and you lose your focus. The classic innovator’s dilemma. How does Stripe stay fresh and making sure you’re not just transferring a list of features?

Michael: That is definitely a challenge. You obviously want to take care of your customers, and your business is actually running on those customers. But we never want our roadmap to be just the list of things that people have asked for. That’s where the longer-term thinking comes in. You have to balance the short-term, reactive stuff with the long-term. Stripe has a very, very long time horizon. If you know where you’re going over time, you can reason clearly about which specific asks are one-offs vs indicative of emerging trends relevant to many users.

Multi-decade abstractions

Ken: What does long-term mean for Stripe? How far out are you looking?

Michael: We talk a lot about building multi-decade abstractions. I personally like to think 10 to 30 years to get out of the three- to five-year mode, but generally here people do say “multi-decade” a lot. Patrick and John and the entire leadership team are clear that this is a long-term bet and that we’re still very early. That long time horizon comes from the top, and it’s in the culture. And my sense is it’s been like that at Stripe since day one.

Ken: This is fun to hear because I’ve argued for 30-year product visions before, but not many people have taken me up on it!

Michael: It’s always hard to look 30 years in the future and craft a particular product, but I think you can look at long-term trends. Stripe, if nothing else, is a long-term bet on the internet and globalization: commerce moving to the internet. Those are multi-decade trends inherently. It’s a bet on technology and startups. You can pick some of the long-term trends, and say “this is where things are going,” and you can then skate where the puck is headed on that front.

Then you can evaluate your short-term moves in light of which of those are actually taking you in the right direction. And which of them are maybe deviations from that direction. It’s important to know what hill you’re climbing. Then it’s much easier to know if the path you’re taking is optimal, or slightly sub-optimal, or headed off in the absolutely wrong direction.

Comparing Stripe and Google

Ken: How is Stripe different from Google, a company we both know well?

Michael: It’s tough for me to compare because it’s such a different stage. I’ve heard from Xooglers at Stripe that it feels like Google in 2005, but I wasn’t at Google then. Google was 20,000 people at the point where I joined [in 2008]. And so a lot of the way it feels different to me is that it’s just so much smaller. Either way, it definitely feels easier to get things done here, with fewer layers to work through and more focus on getting to the right decision and getting there fast. And the amount of focus on really deeply understanding and working backward from users is also quite different.

There’s a lot of similar things, for sure. Both companies have long-term big visions and optimism about the impact technology can have on people’s lives. Both companies value technology and are product-focused.

Ken: Google’s use of OKRs plays a big role in reinforcing long-term planning and ambition. Does Stripe use something similar?

Michael: I would say we’re still settling into the right overall planning structure. We have multi-year plans at a company level, the actual narrative strategy that looks out several years and says, okay, this is the direction we’re going, and here’s how we see things evolving. And we are increasingly using a quarterly and annual goal-setting process similar to OKRs. I am running my team on quarterly goals plus two-page documents per area that frame those goals, and then specific project plans and strategy docs flow from them.

What Stripe values in a PM

Ken: I know Stripe didn’t have product managers in the beginning3 or at least anyone with that title, as surely people across the org were doing the work. I remember meeting with [co-founder] John [Collison] in 2015 when PM was just starting to be formalized, and he wanted to soak up everything we’d learned at Google, especially about growing and mentoring PMs.

Michael: I’ve been here for a year and a half, so I wasn't present for the evolution of it. It was at an inflection point when I joined where it was truly building out PM as a professional function. I joined well past the point where Stripe had decided that it was really important.

But I still didn’t know what I was going to be walking into. I’ve joined teams where you come in, and they’re “Oh, a PM. What am I supposed to do with you? Why are you here?” When I arrived at Stripe, I had one-on-ones with all of the engineering leads on the team and asked them about what they do and what their challenges were, and what they wanted out of product management. To a person, they knew exactly what they needed [from PM], and there was a huge amount of demand for help from us on lots of fronts: strategy, identifying target users, prioritization, helping set direction, and communication. That said, I do think we are still playing catch up in building up capacity on the product management side. [Note: Stripe has tons of open product roles!]

Ken: Who do you look for? What kind of PM would thrive at Stripe?

Michael: I think way back to 2010 when I first read your hiring essay [How to Hire a Product Manager], and it’s still canon and applies super well. We want technical PMs, strong product instincts, lead by influence, channel multiple points of view. At Stripe, we look for not just smart people but quick people. You will do well if you’re very, very agile. Being able to ingest a lot of complexity and then find a path of clarity through that. Quick-thinking, quick-acting people do really well here.

We also want people who will not be held back by a lack of somebody handing them a checklist of all the steps to go through. Being able to thrive in ambiguity. You may have something in mind, but you go talk to customers and learn something totally different. People who are fluid with that will do very well. I do think we also look for PMs who are very technical for most roles.

Ken: Does that mean a CS degree?

Michael: Not a hard and fast rule, but our interview process does test people for their ability to actually think about technical problems. I think we go a step beyond understanding how systems work. Are you comfortable getting into it and thinking not just about how it works but about how it should work? It is not just the ability to work with engineers but also empathy for how the developers are using our infrastructure to build their systems.

You also have to have some degree of taste. While “taste” can be hard to define precisely, in some sense, whatever the domain — whether it’s music or something else — if you spend the time and you put a lot of thought into appreciating something, teasing apart what makes it great, and building a thoughtful, opinionated perspective, that’s taste.

Stripe’s website circa 2011 (from the Stripe Engineering Blog)

Taste and the role of design

Ken: Say more.

Michael: It’s something that really does come through when you look around Stripe. One of our operating principles is “really, really care.” And you can tell when you’re talking to somebody just how much time they spent thinking about and caring about whatever it is that you’re discussing.

If they’re talking about an API, have they really deeply considered it? Are they passionate about the details? Those people who do so end up spiking high on taste. It’s craftsmanship and a huge amount of dedication to getting all of the details right. Much like a designer who’s putting all the pixels on the screen and getting the colors exactly right. That same degree of care applied to API development.

Ken: One of the things I find fascinating about Stripe is the extent to which the company is known for having outstanding design. Obviously, that includes the marketing site and the developer documentation that is cleaner and more beautiful than anything I’ve ever seen. So it’s interesting that a B2B company without a lot of UI is known for centering great design.

Michael: Right, people just really, really care about those things. I don’t know how that happened originally. Part of it is just who Patrick, John, and the leadership team are and the kind of people that they attracted. There’s a surprising amount of tastefulness and just caring about every angle of everything. Whether it’s the user experience, support experience, or how the brand presents itself. There is just the feeling that it should all be exceptional. We should push for an extreme quality bar on all of the fronts.

Certain people are attracted to that, and they attract more people like them. And then it becomes part of the culture, right?

Like what you hear? If so, there are scores of product management job openings at Stripe in hubs around the world and remote.

Recommend Reading

@Suhail Stripe did not have people with the Product Manager title for several years. First person with the PM title was hired in 2015 (5 years after founding). But.... there were people that were performing the PM role before that and were clearly doing that quite well. Role ≠ Title

Product Jobs

Airtable, Product Manager, Collaboration, Mountain View, CA

Cameo, Product Managers and Senior Product Managers, Remote

Clubhouse, Community & Growth Operations Manager, San Francisco, CA or Remote

Cockroach Labs, Staff Product Manager, Security & IAM, Remote (US)

ibble, Senior Product Managers, Austin, TX

IXL Learning, Product Manager, San Mateo, CA

KQED, Product Manager / Senior Product Manager, San Francisco, CA

MongoDB, Product Manager, New York, NY

Robinhood, Director Product Management - Crypto, Mountain View, CA

Stripe, Heads of Product, Product Leads, and Product Managers, Remote

Thought Machine, Product Manager - Card Issuing and Product Analyst, London, UK

Uber, Product Manager - Financial Products, San Francisco, CA

Webflow, Lead Technical Product Manager, Developer Platform, Remote

To submit a job listing for consideration, fill out this form. Listings are always free.