Extreme Product Design: Building Things People Actually Use with Stripe’s CTO

Hi, folks. It's great to see so many of you here. My name is David Singleton. I'm the CTO of Stripe. And today I want to share with you a few secrets about the way we build things, how that's changed over the years, and why it might be relevant for you. So I think when people at large think about large scale infrastructure projects, they often think about big software projects like Windows nt. No, I'm only joking. Of course they don't. They think about big public works, things like the pyramids at Giza or the Roman Colosseum, maybe something more modern like the Golden Gate Bridge. And while the average person doesn't typically think about building companies or SaaS products as massive feats of engineering, all of us here live that reality day to day. I'm a software engineer by training, and in my field we've gone through a transition as dramatic for us as I imagine the transition was for architects and civil engineers when they first started building with steel at the start of the 20th century. The first and most obvious difference between then and now is the difference in our digital infrastructure. Harnessing the power of the Internet to separate the burden of running the software from the value that it creates, the massive efficiencies of scale. But that's not what this talk is about. This talk is about the other difference. The software we build today is really easy to change. And that means we're constantly building the plane while we're flying it. And while that metaphor is, I think, often used as a negative, it's actually key to the SaaS revolution. The best products out there are now built by teams who iterate on the experience that they offer to build great products that customers will actually use. So this talk is titled Extreme Product Design, which is a riff on the idea of extreme programming or XP, which was popularized in the 1990s. So let's go back to those old days when people were still building and selling software on CD ROMs. And talk about someone named Kent Beck. Kent continues to be a key player in changing not just how we build software, but also products. He's the father of test driven development, an engineering approach which essentially flips the developer's mindset from focusing on crafting perfect code to focusing on defining the problems to be solved to and then coding the simplest possible solution that you can. And this was also a time when ideas in programming shifted to focus on things like pair programming, as we find that collaboration and real time feedback led to better outcomes. If you had a time machine and you could go back to See people building Software in the 90s, this is what the process would have looked like. You'd start with an idealized vision for your project and you work out a specification, often hundreds of pages of turgid, tedious prose, which was usually agreed up front with the customer. And then you'd build your project and you'd iterate only within your own team, trying to make sure that everything worked as close to the spec as possible. And then you'd ship the project, usually literally sending a disk in the mail, and you'd hope it met the user's actual needs. This waterfall model of shipping projects has in very many ways disappeared. At most companies in the tech industry today building software this way, it just didn't really work very well. Large software projects were notorious for missing key user expectations when they were first delivered and ending up way over budget and behind schedule. What was so revolutionary about XP and what ended the era of this waterfall project model is that extreme programming embraced the value of rapid iteration and feedback loops to solve the right problems and adjust problems, project timelines and scope to match. It changed the orientation of programming to focus on the needs of the outside world and made teams more responsive using a series of feedback loops. And that enabled a development team to try new things. React quickly to the results of those experiments and as you can see from the activities on the right hand side of this chart, the results of feedback will influence activities at higher or lower levels of the organization. Building software the XP Way it just worked. Projects built this way were less likely to fail. Extreme programming and related ideas like Agile development out competed the previously existing ways of managing development teams, and they changed the ways that we all build software. Now, I'm not arguing that software engineers have the answers to every problem, but I would venture that many of us have already embraced the core ideas in XP and its philosophy in in our product design process. So I'm going to propose something further that embracing these tenets in everything you do will lead to a better user experience, a more grounded product strategy, and more successful product launches in the future. There are three tenets in what I'm going to propose we call extreme product design and first, some brief background and disclaimers. Stripe we're focused on building economic infrastructure for the Internet, so our approach might not be exactly the same one that you take, but our users range from some of the largest companies to the smallest startups and solopreneurs. So I sincerely hope that these examples are going to be generalizable. The first tenet is iterate fast and get feedback from the right users. The first tenet of extreme product design at Stripe starts with the user. We call our customers users partially because it's a common term in the industry, but mostly because we really want them to actually use the things that they're paying for. Clayton Christensen pointed out many years ago that companies have a tendency towards building new things that are less and less useful for their customers. Over time, products become too complex, too sophisticated, or otherwise inaccessible. So, like many of you, the values we've created for ourselves include ones that are centered on our users. At Stripe, we have a set of operating principles. These aren't abstract values that we stick on the wall, but they're rather behaviors that we've distilled from from the most effective stripes. The most important operating principle we have is users first. Some of the users first things that we do are obvious, like making it easy to sign up and accept your first payment, or providing transparency into our reliability statistics. But users have more needs than we could ever think of, so we have to find ways to understand them and get their feedback. The good news is that I think most companies can easily optimize their existing product design process to massively increase the amount of feedback that they get from their users. Let's take an example. This is Werner Vogels, who's Amazon's cto, and he's one of the chief architects behind aws. He outlined their approach to designing for users in a process that Amazon calls working backwards. The process starts over there on the right with an idealized user for the product. Then they create the kind of documents that you typically expect to write after your design work is done. A press release, an FAQ document, an outline of the customer experience, and then the user manual. They do all of that before writing any code. And that approach has gained prominence in recent years, and we use it at Stripe, too. It's incredibly helpful to establish a shared product vision, align teams, and address any concerns from internal stakeholders. At Stripe, we work hard to extend this approach outside the four walls of our office, and we try to do that as early as we possibly can. Every product design reaches an inflection point, usually after maybe 100 hours of work or so when it's first shared with a customer. The extent that you can move that event to the left of the timeline is the extent to which you can spend time building a great product rather than having to guess. And that's something that's embedded in our DNA as a company. Our founders, cute picture here. Started the company because it was too complicated for for a startup to start accepting payments online. And they built some of the first products by pair programming alongside our earliest customers. They build the integration right there, sitting with them, writing code and talking. And we're still trying to make our user experience as close to this as possible. Generally, some of the most successful and versatile products have been a direct result to listening to our most discerning users. For example, one of our early users was a company called Zimride, who we all know now today as Lyft. And in the early days, they faced a lot of competition for customers from other startups offering similar services. They needed a way to accept whatever form of payment their riders wanted to use. But they were also competing for drivers. And those drivers wanted control over how and when they were paid out. They didn't want a traditional direct deposit every week. And at the time we didn't have anything that would offer their drivers a better experience. There's a ton of heavy lifting you have to do to run a business like this. KYC money, transmission licenses, tax reporting, there's tons. And at the time we were providing a really easy way for Lyft to work with their customers. But that's only one side of the problem. So we co developed two products, one for connected multi party payment accounts. It's called Stripe Connect. And another that gives drivers the ability to decide how they get paid out. And in less than a year, more than half of Lyft's drivers were using the new instant payouts feature. And Lyft saw that as a huge competitive advantage. When they were recruiting drivers, we then iterated. We heard from that user and many others that folks like those drivers wanted a great mobile experience since they essentially work from their smartphones. So we built a mobile app that handles onboarding, reporting and all of the things that platforms like that need. Now this wasn't a common set of problems for all of our users at the beginning, but by focusing on an acute problem for one of our early users, we, we ended up supporting an entirely new category of online platform. And that category, as it turns out, was growing really fast. Getting feedback from a leader in this business category helped position us for product success with others. And today these platforms continue to proliferate and include companies like WooCommerce who are helping people from the offline economy go online. We wouldn't have gotten here on our own. Users needs animate our work. So we look at every internal forum at Stripe as an opportunity to solicit feedback. We invite users into group meetings. We, we ask them for suggestions about how we can improve up and down all levels of the organization. We share stories of actual users and the problems that they're trying to solve. We don't talk about customer wins in terms of dollar figures. So much talk about them in terms of the opportunities that we're unlocking for those businesses. We also look at every external forum as an opportunity to solicit feedback. And seriously, if you have any feedback for Stripe today, please go over to the Stripe Finders Lunch, which is just right there after the talk and tell them that David sent you. Please. Here's the second tenet. Find friction and eliminate it quickly. I'll say it again, eliminate friction points as quickly as possible. Taking feedback is important, but the goal isn't to disappear off with that feedback and take years to perfect your product between releases. Early in the project, when it's still easy to change things, you need a feedback loop where users see something, you get feedback from them and and then you iterate and ship them an improvement to get more feedback on. And that loop should be able to run in less than a day and ideally less than one hour. This is the next feedback loop. In extreme product development, the cycle time between identifying an issue and fixing it determines the rate of product improvement and therefore of long term product quality. This assumes, of course, that you have a secure and stable foundation. You always need to keep those lights on. But once you deliver on the core promise of your product experience, start refining it as quickly as you can when writing code. The process of fixing faulty behavior is called debugging, and your goal here is to debug the customer experience, whether the points of friction come from the product itself or somewhere else in the customer journey. Years ago we had the opportunity to do both with our core payments API. When we built our first API to charge cards, our expectations around how card charges might work were baked into our code. But then over time, users told us that they wanted to accept other payment methods too, and our product assumed that card transactions would complete almost instantly. But as we expanded adding bank debits and Bitcoin transactions, those assumptions were really challenged. Bitcoin payments would sometimes take hours to complete, and bank payments often days. So we needed to go back and rethink some basic concepts. At a fundamental level, there were also lots of barriers for our users just to get to the point where they could accept payments. We started with an API, but lots of people just wanted a basic e commerce experience that they could drop into their site. Others did their business by email or over the phone, so Today, you can handle credit cards through our API, or you can email a link, send an invoice, generate a QR code. The list goes on and on. But we did that because we found out that these were ways that people wanted to accept payments. We want to move forward on both fronts, improving the experience of our products themselves and addressing the barriers that limit the accessibility of those products for our users. For a more recent example, what about banking for our users? Well, it turns out that 37% of small businesses actually earn their first dollar or euro before they have a business bank account. Our internal product teams heard about these problems and they set up a new service that would let platforms offer their own simple money management accounts to address this sort of gap in the experience of their users. Not long after, Shopify launched a product called Balance that provides a simple money management account for their customers online businesses. Those customers can access the money they make through the same interface as their Shopify store. They get paid faster, they pay lower fees, and they have one less point of friction in their daily lives. This product is built on top of Stripe, but the experience is seamless because we keep all that complexity hidden. Creating space for internal teams to do their jobs is an enabler of this kind of product design approach. If you're giving teams the remit of building for your users and they're moving in the right direction and they're doing it well, then why would you want them to spend their time doing anything else? And this is one place where I definitely think software engineers can set a good example for the rest of us. We think a lot about how to make sure our internal tools help engineers, design designers, and product people be super productive. Very early at Stripe, we built a developer productivity team, a group of people that peeled off of our product work and built tools to make all of the other engineers more productive. We wanted to make sure that they could work autonomously as much as possible, while still building products that fit together really well. We also thought for years about how to identify the small problems and niggles that might not even make it to the top of any one team's roadmap. But but in aggregate add up to a frustrating experience when you're trying to get stuff done internally. We made it as easy as possible to report these paper cuts, as we call them, with a single click in our internal tools. Because if you put them all together, that adds up to a massive opportunity to make our teams working lives more efficient. Already this year, our engineering success team has fixed hundreds of these issues. Even better, our Engineering teams have gotten feedback that they would never have gotten without this kind of a program. Having a philosophy of problem solving that's internally and externally consistent is a really powerful thing. Action inspires more action. And if you claim to have a culture of problem solving, you really need to back it up by actually doing that. There's no place where this becomes more obvious than at a company's commitment to fixing everyday quality of life issues. If you want to summarize these first two tenets we just covered, it would be this. Ensure you have a rapid iterative loop which, with the right customers, that fixes real world problems rapidly. Iterating based on user feedback means that your products will probably look very different in two or three years. It's necessary to keep up with your users and their pain points. But that's not always easy, especially as your company grows. And that brings me to my third and final point. Build your teams and processes with the goal of becoming a learning organization. The end goal is to adopt these practices at scale and continuously improve to transform your business into a learning organization. Learning organizations, by the way, were another idea popularized in the early 90s by people like Peter Senji at MIT. Senji writes about the five things every company needs to do in order to embrace the ideas of learning and continuous improvement. These include things like developing your own personal vision for how your organization should operate, understanding the assumptions that color this perception and encouraging dialogue, and developing actionable strategies that work for everyone. This should be simple in theory. Start with a user, get feedback iterate. Sound familiar? Start small and fix things quickly. But it turns out complexity in size, scale and the growth of your products can all weigh on your operations and threaten to push you into a state of non responsiveness. In engineering, we talk a lot about tech debt, the deferred decisions and compromises we made that lead to problems down the line. But culture debt and management debt are problems that are just as real and they can have just as big of an impact on your ability to deliver products for your users or customers. Now, I definitely do not have all the answers to these problems, I assure you. But I was once told that all advice is simply people telling other people what worked for them. So I'm going to share what has worked for us as we've scaled up at Stripe and we've worked to preserve that user's first culture. Some things are simple. We actually really tell and invite everyone at Stripe to talk to users start saying this as soon as they get in the door. In every Stripe 101 class I actively encourage every single engineer product developer at the company to sit in on conversations with our users or have their own independent ones. And you know, it can be kind of daunting for people to ask for feedback or engage with customers early on. Everyone's kind of afraid of saying the wrong thing or getting into trouble. So building a culture that embraces this, that prepares every employee and enables these feedback sessions, it's not something we perfected, but it's something we constantly work towards. Encourage a culture of transparency and collaboration. In social psychology, there's this idea called behavior modeling. It says that most behaviors you see are learned by observing the behaviors of others. If we want to create product teams that communicate, are collaborative and are open to feedback, that and we need to model those behaviors at all levels of the organization. At Stripe, we use a variation on the common objectives and key results template for goal planning, but we also work really hard to expose those goals to everyone at the company. On our intranet, we also built a system that automates the creation of project launch update emails. At Stripe, we celebrate shipping or you might say launching new features or new products, new systems too. I think everyone probably does this, but we've actually templatized it and developed a process so that all the things going on across sales, marketing, it, these are functions that are just as valuable to the company and we want to feature them as well. It may seem a bit small when you describe what it is, but new customer service process might be just as relevant or even more relevant for our users than a cool new product feature. We also share product and project metrics widely internally too. The takeaway here is to make sure that everyone has a goal that ladders back up to the user experience or reduces friction. Make sure that there's company wide visibility to help foster collaboration and investing in collecting feedback is another important thing that we've done as we've grown. In the early days, every API error on Stripe would trigger an email to our CEOs inbox and every single support ticket would actually page our executive cell phones. So that's one way to get visibility into product issues. Of course it doesn't scale, but some of our early ideas for building feedback loops were great and they continue to inspire us today. For example, the original IRC channel we used to solicit and act on feedback from some of our earliest users has its spiritual successor today on Discord. Working closely with our most opinionated users over long periods of time provides a really strong feedback loop. And that's led to the creation of things like our first customer advisory board where we can engage deeply with our larger users to understand where we're succeeding and where we need to challenge ourselves to grow. This kind of high touch engagement builds trust. It helps us identify users who have uniquely interesting feedback to give. I've just talked about a bunch of low bandwidth, high engagement channels for product feedback, but we all know that you don't need to wait until people come to you if you want to get their feedback. There's this wonderful sometimes thing called social media. After all, nowadays we can often get quick and often extremely valuable feedback just by asking questions on Twitter. Given enough time and monitoring and engagement, this feedback can be not only qualitatively interesting, but quantitatively interesting as well. One example of how we translate ongoing user feedback with a fast iteration cycle and company wide alignment comes from our API design and product integration process. We've got a rigorous API design process that allows most internal teams to independently pursue new products and start to design their own API interfaces and but keep them consistent with all of the other APIs that we already offer. They all go through the same process we described at the start of this talk, working backwards from a user problem, describing the functionality, and so on in documentation for internal stakeholders like our cross functional API Review team, we conduct user testing to learn about how real users might adopt the new feature and what tensions might come up. We also look at the metrics for our existing APIs. Developers can comment and submit feedback directly from our documentation or from their own dashboard. We then produce an early version and have infrastructure in our systems which allow us to gate in specific users so they can use it for real and provide early feedback on a real working API that we haven't yet shipped to the whole world. Those gates help us rapidly iterate on designs with beta users, and that enables us to invite external users to try our full end to end feature before it's released to the general Stripe user base. Knowing it already works for what they need, teams are encouraged to trial a few different designs, sometimes with users to settle on the best option. The issuing API, for instance, was developed behind a gate for over a year. Our team irons out any bugs, documents the new feature, and issues a new API version. And when we're ready to go live, we incrementally roll out the feature to users across the platform and keep a close eye for new issues that might crop up. Everything goes back to those ideas I outlined before. To close this talk, I wanted to share a quick story. This is Jadav Molai Peyang an environmental activist who works in the Golgat district in India. In 1979, Peyang looked out at an island where a forest had been clean cut 100 years before. He decided that even though he was only one person, he. He wanted to make a difference. The forestry service told him that no trees would grow on the island. So he tried to grow bamboo. At first, only a few small shoots managed to take root. So he nursed those first few plants along for years, and he perfected his approach. He experimented with introducing other local fauna, doing things like bringing a whole ant colony to the island in a rowboat. Bamboo shoots gave way to saplings. Saplings turned into a forest. Ants and insects were followed by larger creatures, little by little. Over the years, he learned the craft of forestry by trial and error. Now Peiyang is called the Forest man of India. And the island has been transformed from a barren sandbar into a lush 1300 acre forest. In 2010, local authorities were stunned to discover that the island is a haven for endangered species like elephants, rhinos, and tigers. And all of that was accomplished because of one person's commitment to working on an obvious problem. At the start of this talk, I mentioned building big things. The secret is, there's no secret at all. It's all about execution. Over time, perhaps none of the things we build will be as prominent or long lasting as the pyramids at Giza. But with the right focus, we can still build things that touch millions of people's lives and help make them successful. The core ideas I discussed here are simple. Do something, start small, get feedback, and iterate. If you commit to those steps, I think you can have a meaningful cumulative impact in the world around you. Just keep going. The world around us is full of feedback. So I encourage you to go out, listen to that feedback, and build the things that the world needs.