Does Stripe Have Product Managers Or Do Engineers Manage The Products Themselves?

14 January 2013

 

We don’t have any dedicated product managers today. Or, more accurately, engineers manage products themselves.

Some of our recent launches include Stripe Connect (stripe.com), support for Canadian users, and Stripe.js version 2 (stripe.com). 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 (taskforceapp.com) and a number of open source projects. Amber had a long list of products (amberfeng.com) under her belt. Ross founded 280 North (wikipedia.org), built 280 Slides, and co-created the Cappuccino (cappuccino.org) web framework. Ludwig single-handedly designed and built Observer, a real-time web analytics tool. Ben started Kickoff (kickoffapp.com). (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 (fourteen 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.”