Does Stripe have product managers or do engineers manage the products themselves?
Answer Wiki
Some of our recent launches include Stripe Connect, support for Canadian users, and Stripe.js version 2. They were overseen by Amber Feng and Ross Boucher, Sheena Pakanati, and Alex MacCaw, respectively. All are full-time engineers.
As we’ve grown, we’ve tried to be careful about the structures we put in place. A lot of companies seem to naturally—almost mimetically—adopt a fairly “normal” hierarchy: product managers, engineers, designers, project managers, etc. Given their universality, it’d seem plausible that they’re roughly optimal.
I believe that having dedicated product managers probably isn't ideal in every situation, however. They’re very effective in many companies, and having full-time product managers might even be right for Stripe at some stage, but it’s not what we want right now.
I think there are a few reasons as to why this is working well for us today:
- The engineers who build our products enjoy, and are good at, figuring out what the product should do—not just how the implementation should work.
- Since many of the people who work on the Stripe product are users of it (half of them had already used Stripe before they joined the company), they have a good feel for what product improvements might be useful or important.
- Most of the people who work directly on the user-facing parts of Stripe have managed products before, and enjoy the process of figuring out how they should work and what they should do. Before Stripe, Saikat and Sheena built Mockingbird. Alex built Taskforce and a number of open source projects. Amber had a long list of products under her belt. Ross founded 280 North, built 280 Slides, and co-created the Cappuccino web framework. Ludwig single-handedly designed and built Observer, a real-time web analytics tool. Ben started Kickoff. (As it happens, many people who don’t work directly on the user-facing parts of Stripe also have similar experience.)
- We’re still pretty small. In a larger company, where there are meetings to attend, outside partners to talk to, legal considerations to investigate, etc., product managers can help deal with the non-engineering work that arises. So far, our workflow has been to have the people doing the implementation work directly with the rest of the company to figure these aspects out.[1] This might not scale to Byzantine complexity, but it works well today, and having the complete picture in someone’s head has a lot of value.
- The engineers building the product are pretty self-sufficient and are able to hack on most levels of our stack. If someone wants to build even a major new feature, it doesn’t require a coalition of engineers and a manager to oversee the effort. (That’s not to say that people tend to work by themselves. Quite the opposite: because there isn’t much hierarchy or a product manager, there tends to be a lot of discussion, internal testing, and suggestions and help from others.)
There are obviously many great product managers in the world. Still, to the extent that having a “product manager” implies having a separation between the person who builds the product and the person who manages it, a few downsides seem to come up repeatedly:
- They can slow the iteration that’s at the heart of creating great products. If the same person is designing and implementing, the feedback cycle takes place within that person’s head. Even if product managers have equally good ideas, they’re likely not able to experiment with as many of them.
- Though this certainly doesn’t always happen, I think it’s easy for product management structures to make programming less fun. Most people fall in love with programming because of the ease with which you can jump from an idea to a tangible, working reification. If that path takes a detour through a product management organization, a lot of the joy can dissolve. I’m always worried about trading off enjoyment for ostensible efficiency. Even if it is more efficient, if someone ends up spending 30% less time hacking on a project because it’s just less enjoyable, you’ve probably still lost.
Many people at Stripe have founded start-ups before (14 of us, I think), and part of our goal in shaping the company isn’t just to build a successful product, but also to create the best long-term work environment we can. If something is immediately expedient but will lead great people less satisfied over the long-term, we don’t want to do it.
In building a product, I’ve always thought that “consider doing some things that don’t scale” is pretty good advice: manually add content, go visit your early users in person, review all the contributions by hand, etc. Figuring out how to eliminate the unscalable parts as you grow is much easier than trying to design the scalable solution from scratch.
We‘re trying to do the same thing with the Stripe organization. (Almost all of our emails are internally public. How long can we sustain this? I’m not sure.) We’ve hit lots of bottlenecks, and the claim here certainly isn’t that we’ve figured everything out.[2]
Still, not having product managers is working well today, and my suspicion is that we won’t end up with something that looks exactly like most other technology companies. But it’ll be interesting to see how it unfolds.
[1] Though this post focuses mostly on product engineering, the engineers who work on other parts Stripe, not to mention the people who work on design, business, support, etc., are all pretty exceptional. I suspect the workflow described here works only if everyone gets along very well and has a similar perspective.
[2] Sometimes, I vaguely feel that “how we work” posts have the feel of Potemkin villages. “Everyone is blissfully happy and nothing could be better.”
Related QuestionsMore Answers Below
TL; DR: Stripe has product managers now.
Product Management at Stripe
One of Stripe’s core values is that everyone is empowered to do whatever is necessary for Stripe, regardless of role. From sales to support, design to data analytics, many people are dedicated to building the best experiences for our customers. In particular, engineers play a critical role in defining, shaping, and executing on product vision. Historically, this empowerment was key to building an organization without product managers.
Since Patrick Collison’s Quora post in December 2012, Stripe has grown a lot — in number of employees, and in the size, complexity, and cross-functional nature of the projects we tackle to achieve ever more ambitious goals. Engineers and designers (along with many more from business and user-facing teams) remain deeply involved in making our products great.
Product managers help fulfill our goals by representing the customer, working with engineering and others to define and produce great products, and facilitating cross-company communication. In short, product managers help build better products, and also help teams build in a better way. Also, we bring donuts.
The Team
Product managers were first introduced to Stripe in June 2015, when the company was about 250 people. Currently, the product management team has 6 members.
We are growing the team thoughtfully and not too fast. Given that Stripe operated (and thrived) for 5 years without any product managers, we want to make sure that any additions are well-integrated into Stripe’s culture and processes. As Patrick predicted in 2012, we probably “won’t end up with [an org] that looks exactly like most other technology companies.” This is still very likely to be the case, not only for the product management org but for many teams at Stripe.
The role is still by no means fully defined today. Anyone joining the nascent team now has a huge opportunity to help shape what this role means at Stripe. We are hiring :)
Related Questions
Still have a question? Ask your own!