Extreme Product Design: Building Things People Actually Use with Stripe's CTO | David Singleton, CTO @ Stripe
•Download as PPTX, PDF•
0 likes•107 views
Stripe CTO David Singleton shares insights from the company's focus on going the extra mile to obtain user feedback and even more extreme lengths to turn that feedback into successful products. He’ll show how one simple rule helped the company grow from a single API to a sophisticated platform, and discuss the challenges of managing change, defining product-market fit, and designing infrastructure that can scale.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Extreme Product Design: Building Things People Actually Use with Stripe's CTO | David Singleton, CTO @ Stripe
Similar to Extreme Product Design: Building Things People Actually Use with Stripe's CTO | David Singleton, CTO @ Stripe (20)
More from saastr
More from saastr (20)
Recently uploaded
Recently uploaded (20)
Extreme Product Design: Building Things People Actually Use with Stripe's CTO | David Singleton, CTO @ Stripe
- 1. Extreme Product Design: Building Things People Actually Use David Singleton CTO Stripe @dps 1
- 2. 2
- 3. 3
- 4. 4
- 5. 5
- 6. 6
- 7. The software we build today is really easy to change. 7
- 8. The software we build today is really easy to change. 8
- 9. 9
- 10. 10
- 11. 11
- 12. 12 Write a failing test Make the test pass Refactor TDD
- 13. You’d start with an idealized vision for your project and work out a specification 13
- 14. You’d start with an idealized vision for your project and work out a specification 14 You’d build your project and iterate only within the team You would ship the project sending a disk in the mail
- 15. You’d start with an idealized vision for your project and work out a specification 15 You’d build your project and iterate only within the team You would ship the project sending a disk in the mail
- 16. 16
- 17. 17
- 18. 18
- 19. 19
- 20. 20
- 21. 21
- 22. 22 Three tenets of “extreme product design”
- 23. 23 Three tenets of “extreme product design”
- 24. The first tenet: iterate fast, and get feedback from the right users. 24
- 25. The first tenet: iterate fast, and get feedback from the right users. 25
- 26. The first tenet: iterate fast, and get feedback from the right users. 26
- 27. Users first Move with urgency and focus Be meticulous in your craft Seek feedback Deliver outstanding results 27 1 2 3 4 5
- 28. 28
- 29. 29 User manual FAQ Press Release Customers
- 30. 30 User manual FAQ Press Release Customers
- 31. 31 User manual FAQ Press Release Customers
- 32. 32 User manual FAQ Press Release Customers
- 33. 33 Patrick and John Collison - Stripe cofounders (2010)
- 34. 34 Patrick and John Collison - Stripe cofounders (2010)
- 35. 35 Patrick and John Collison - Stripe cofounders (2010)
- 36. 36
- 37. 37
- 38. 38
- 39. 39
- 40. 40
- 41. 41
- 42. 42
- 43. 43
- 44. 44
- 45. The second tenet: find friction and eliminate it, quickly 45
- 46. 46 users see something; you get feedback from them; and you iterate and then ship an improvement.
- 49. 49
- 50. 50
- 51. 51
- 52. 52 $ curl https://api.stripe.com/v1/payment_intents -u sk_test_4eC39HqLyjWDarjtT1zdp7dc: -d amount=2000 -d currency=usd -d "payment_method_types[]"=card
- 53. 53 $ curl https://api.stripe.com/v1/payment_intents -u sk_test_4eC39HqLyjWDarjtT1zdp7dc: -d amount=2000 -d currency=usd -d "payment_method_types[]"=card
- 54. 54 $ curl https://api.stripe.com/v1/payment_intents -u sk_test_4eC39HqLyjWDarjtT1zdp7dc: -d amount=2000 -d currency=usd -d "payment_method_types[]"=card
- 55. 55 37% of small businesses earn their first dollar or euro before having a business bank account
- 56. 56
- 57. 57
- 58. 58
- 59. 59
- 60. 60
- 61. 61
- 62. 62
- 63. 63
- 64. 64
- 65. Scale and continuously improve. Become a learning organization. 65
- 66. 66
- 67. 67
- 68. 68 User Get feedback Iterate Fix quickly
- 69. 69
- 70. 70
- 71. We invite everyone at Stripe to talk to users. 71
- 72. We invite everyone at Stripe to talk to users. 72
- 73. Encourage a culture of transparency and collaboration. 73
- 74. 74 Encourage a culture of transparency and collaboration.
- 75. 75 Encourage a culture of transparency and collaboration.
- 76. 76 Encourage a culture of transparency and collaboration.
- 77. 77 Encourage a culture of transparency and collaboration.
- 80. Working closely with users over long periods of time provides a strong feedback loop. 80
- 81. 81
- 82. 82
- 84. 84
- 85. 85
- 86. 86
- 87. 87
- 88. 88
- 89. 89
- 90. Even small efforts can have a huge impact over time 90
- 91. 91
- 92. 92
- 93. 93
- 94. 94
- 95. 95
- 96. 96 Iterate fast, and get feedback from the right users. Find friction and eliminate it quickly. Scale and continuously improve. Become a learning organization.
- 97. 97
Editor's Notes
- Hi, 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. CLICK
- the pyramids at Giza CLICK
- or the Roman Colosseum…CLICK
- maybe something more modern like the Golden Gate Bridge. 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. CLICK
- I am a software engineer by training, and in my field we have 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. CLICK
- 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 using it creates. The massive efficiencies of scale. CLICK
- But that’s not what this talk is about. This talk is about the other difference: CLICK the software we build today is really easy to change. That means we’re constantly building the plane while we’re flying it. CLICK
- And while that metaphor is 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 they offer to build great products that customers will actually use. CLICK
- This talk is titled “extreme product design,” which is a riff on the idea of “extreme programming” (or “XP” as it was called) that was popularized in the 1990s. CLICK
- So let’s go back to those ancient days when people were still buying and selling software on CD-ROMs, CLICK
- 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”-- CLICK
- –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 and coding the simplest solution you can. This was also a time when ideas in programming shifted to focus on things like pair programming as we found that collaboration and real time feedback led to better outcomes. CLICK
- If you had a time machine and could go back to see people building software in the 90s, this is what the process would look like: CLICK You’d start with an idealized vision for your project and work out a specification, often hundreds of pages of turgid, tedious prose which was usually agreed upfront with the customer. CLICK
- Then you’d build your project and iterate only within the team trying to make sure that everything worked as close to the spec as possible.CLICK And then you would ship the project–usually, literally–sending a disk in the mail, and hope it met the users’ actual needs.CLICK
- This “waterfall” model of shipping projects has in many ways disappeared at many companies in the tech industry today. Building software this way… it didn’t always work very well. Large software projects were notorious for missing key user expectations when first delivered and ending up way over budget and behind schedule. CLICK
- What was so revolutionary about XP and what ended the era of this waterfall project model is that XP embraced the value of rapid iteration and feedback cycles to solve the right problems and adjust project timelines and scope. CLICK
- 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. This enabled a development team to try new things, and then to react quickly to the results of those experiments. CLICK
- As you can see from the activities on the left hand side of this diagram, the results of feedback will influence activities at higher or lower levels of organization. CLICK
- Building software the XP way worked - projects built this way were less likely to fail. Extreme programming and related ideas like agile development out-competed the existing ways of managing development teams and changed the way we build software. CLICK
- Now, I’m not arguing that software engineers have the answers to every problem. But I would venture that many of us here have already embraced the core ideas in XP and its philosophy in our product design process. CLICK
- So I’m going to propose something further: that embracing these tenets in everything that you do will lead to a better user experience, a more grounded product strategy, and more successful product launches in the future. CLICK
- There are 3 tenets I’m going to propose of what I’m calling “extreme product design.” First some brief background and disclaimers: Stripe is focused on building economic infrastructure for the Internet, so our approach might not be exactly the same one that you take. CLICK
- But our users range from some of the largest companies to the smallest startups and solopreneurs… so I sincerely hope these examples are going to be generalizable. CLICK
- 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. CLICK
- 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: products that are too complex, too sophisticated, or otherwise inaccessible. So like many of you, the values we have created for ourselves include ones that are centered on our users. CLICK
- At Stripe we have a set of operating principles. These aren’t abstract values that we stick on the wall, but rather behaviors that we have distilled from the most effective Stripes. The most important operating principle we have is “users first”. CLICK
- 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 stats. But users have more needs than we could ever think of, so we have to find ways to understand them and get their feedback. CLICK
- 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: Werner Vogels, Amazon’s CTO and one of the chief architects behind AWS. Wener outlined their approach to designing for users in a process that Amazon calls Working Backwards. CLICK
- The process starts over here on the right, with an idealized user for the product. Then they create the kind of documents you typically expect to be written after your design work is done: a press release, a FAQ, an outline of the customer experience, and then the user manual… they do all of that before writing any code. CLICK
- This approach has gained prominence in recent years, and we use it at Stripe as well. It’s incredibly useful to help establish a shared product vision, align teams, and address any concerns from internal stakeholders. CLICK
- At Stripe we work hard to extend this approach outside the four walls of our office, and we do it as early as possible. Every product design reaches an inflection point, usually after hundreds of hours of work, when it is first shared with a customer. CLICK
- The extent you can move that event to the left of the timeline is the extent you can spend time building a great product, rather than having to guess. CLICK
- That’s something that is embedded in our DNA as a company. Our founders started the company because it was too complicated for a startup to start accepting payments online… and they built some of the first products by pair programming alongside our earliest customers– CLICK
- –they would build the integration right there, sitting with them, writing code and talking. We are still trying to make our user experience as close to this as possible! Generally, some of our most successful and versatile products have been a direct result of listening to our most discerning users.CLICK
- For example, one of our early users was a company called Zimride, CLICK
- which we all know today as Lyft. 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 that 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. CLICK
- 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 loads. And at the time, we were providing an easy way for Lyft to work with their CUSTOMERS… but that is only one side of the problem. CLICK
- So we co-developed two products: one for connected multi-party payment accounts, and another that gives drivers the ability to decide when they get paid out. In less than a year, more than half of Lyft’s drivers were using the new instant payouts feature, and Lyft saw it as a competitive advantage when recruiting drivers.CLICK
- We then iterated: we heard from our user that drivers wanted a great mobile experience, since they essentially worked from their smartphones. So we built a mobile app that handles onboarding, reporting, and all of the other things the platform needed. CLICK
- Now, this wasn’t a common set of problems for all of our other users at the time, but by focusing on an acute problem for one of our early users, we ended up supporting an entirely new category of online platform. That category, it turns out, was growing. CLICK
- Getting feedback from a leader in this business category helped position us for product success with others. Today, these platforms continue to proliferate and include companies like WooCommerce, which is helping people from the offline economy go online. CLICK
- 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 and we ask them for suggestions about how we can improve. CLICK
- Up and down all levels of our organization we share the stories of actual users and the problems they’re trying to solve. Don’t talk about customer wins in terms of dollar figures. Talk about them in terms of the opportunities we can unlock for those customers. CLICK
- We also look at every external forum as an opportunity to solicit feedback. Seriously, if you have any feedback for us today–go down to the Stripe Founders Lounge after this talk. Tell them David sent you. CLICK
- 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: CLICK
- users see something; you get feedback from them; and you iterate and then ship an improvement. That loop should be able to run in less than a day and ideally less than an hour. CLICK
- This is the next feedback loop in extreme product development. The cycle time between identifying an issue and fixing 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 the lights on. But once you deliver on the core promise of your product experience, start refining it. Quickly. CLICK
- 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. CLICK
- When we built our first API to charge cards, our expectations around how card charges might work were baked into our code. But users wanted to accept other payment methods too. Our product assumed that card transactions would complete almost instantly. CLICK
- But as we expanded, adding bank debit and bitcoin transactions, those assumptions were challenged--Bitcoin payments would sometimes take hours to complete and bank payments, sometimes days. CLICK
- We needed to go back and rethink some basic concepts at a fundamental level. CLICK
- 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 ecommerce experience that they could add to their site. Others did their business by email or over the phone. CLICK
- 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 and on, because we found out that these were ways 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 users. CLICK
- For a more recent example, what about BANKING for our users? CLICK
- For a more recent example, what about BANKING for our users? Did you know 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 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. CLICK
- Later, Shopify launched a product called Balance that provides a simple money management account for their customers’ online businesses. Their customers can access the money they make through the same interface as their store— CLICK
- they can get paid faster, pay lower fees, and have one less point of friction in their daily lives. The product product is built on top of Stripe, but the experience is seamless because we keep all of that complexity hidden. CLICK
- Creating space for internal teams to do their jobs is an enabler of this kind of product design approach. If you are giving teams the remit of building for your users, 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? CLICK
- 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, designers, and product people be super productive. CLICK
- 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 our internal builders more effective. We want to make sure they can work autonomously as much as possible while still building products that fit together really well. CLICK
- We also thought for years about how to identify the small problems and niggles that might never make it to the top of any one team’s roadmap, but in aggregate add up to a frustrating experience. We made it as easy as possible to report these “paper cuts” (as we call them) - a single click in our internal tools - because then we can track and measure them. CLICK
- hat 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. CLICK
- Having a philosophy of problem solving that is internally and externally consistent is a powerful thing. Action inspires more action, and if you claim to have a culture of problem-solving, you really need to back it up. There is no place where this becomes more obvious than in a company’s commitment to fixing everyday, quality-of-life issues. CLICK
- If you want to summarize the first two tenants we just covered, it would be this: ensure you have a rapid iterative loop 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 it isn’t always easy. Especially as your company grows. That brings me to my third and final point.CLICK
- 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. CLICK
- Learning organizations were another idea popularized in the early 90s by people like Peter Sen-GEE at MIT. Senge writes about the five things every company needs to do in order to embrace the ideals of learning and continuous improvement. CLICK
- These include things like developing your own personal vision for how your organization should operate, understanding the assumptions that color this perception, encouraging dialogue, and developing actionable strategies that work for everyone.CLICK
- This should be simple, in theory. Start with a user. Get feedback. Iterate. Start small and fix things quickly. But 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. CLICK
- In engineering we talk about tech debt–the deferred decisions and compromises that lead to problems down the line. But culture debt and management debt are problems that are just as real and can have just as big of an impact on your ability to deliver products for your users or customers. CLICK
- Now, I do not have all of 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 have scaled up at Stripe, and have worked to preserve that users-first culture. CLICK
- Some things are simple: we tell everyone 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 at the company to sit in on conversations with our users or have independent ones. It can be very daunting for people to ask for feedback or engage with customers. CLICK
- Everyone is 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 that we’ve perfected, but it is something we constantly work towards. CLICK
- Encourage a culture of transparency and collaboration. In social psychology there’s this idea called behavior modeling. It says that most behaviors are learned by observing the behavior of others. If we want to create product teams that communicate, are collaborative, and are open to feedback, then we need to model these behaviors at all levels of the organization. CLICK
- At Stripe we use a variation on the common objectives and key results template for goal planning. But we also try to expose those goals to everyone at the company on our intranet. We also built a system that automates the creation of project launch emails. At Stripe we celebrate shipping or you might say “launching” new features or new products… new systems, too. CLICK
- I think everyone probably does this. But we actually templatized this and developed a process so that projects across sales, marketing, IT–these are functions that are just as valuable to the company, and we want to feature them, as well. CLICK
- It may seem a bit small when you describe what it is, but a 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. CLICK
- The takeaway here is to make sure everyone has a goal that ladders back up to the user experience or reduces friction. Make sure that there is company-wide visibility to help foster collaboration. CLICK
- Investing in collecting feedback is another important thing we have done as we have grown. In the early days, every API error would trigger an email to our CEO’s inbox, and every support ticket would page our executives’ cell phones. That’s one way to get visibility into product issues! CLICK
- Of course this doesn’t scale, but some of our early ideas for building feedback loops were great, and continue to inspire us. For example, the original IRC channel we used to solicit and act on feedback from some of our earliest users has its spiritual successor on Discord. CLICK
- Working closely with our most opinionated users over long periods of time provides a strong feedback loop. This has led to the creation of our first customer advisory board, where we can engage deeply with users to understand where we are succeeding and where we need to challenge ourselves to grow. This kind of high-touch engagement builds trust, and helps us identify users who have uniquely interesting feedback to give. CLICK
- I’ve talked about a lot 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 is this wonderful thing called social media, after all! CLICK
- Nowadays we often can get quick and often useful feedback just by asking a question on Twitter. Given enough time and monitoring, this feedback can not only be qualitatively interesting, but quantitatively interesting, as well. CLICK
- One example of how we translate ongoing user feedback with a faster iteration cycle and company-wide alignment comes from our API design and product integration process. -We have a rigorous API design process that allows most internal teams to independently pursue new products and start to design their own API interfaces.CLICK
- -They go through the process we described at the start of this talk, working backwards from a user problem, describing the functionality, and so on in documentation...CLICK
- …for internal stakeholders, like our cross-functional API review team. CLICK
- -We conduct user testing to learn about how real users might adopt the new feature and what tensions might come up. CLICK
- -We also look at the metrics for our existing APIs. Developers can comment and submit CSAT metrics directly from our documentation site or their own Dashboard. -We then produce an early version and have infrastructure in our systems to gate in specific users to provide as much early feedback as possible on a real, working API that we haven’t yet shipped to the world. CLICK
- -These gates help us rapidly iterate on designs with beta users. This enables us to invite external users to try a new feature before it’s released to the general Stripe user base knowing it already works for our real-world users. Teams are encouraged to trial a few designs with users to settle on the best option; the Issuing API was developed behind a gate for over a year. CLICK
- -Our team irons out any bugs, documents the new feature, and issues a new API version. -When we’re ready to go live, we incrementally roll out the feature to users across the platform, and keep a close eye for issues that might crop up. Everything goes back to those ideas I outlined before. CLICK
- To close this talk, I wanted to share a quick story. CLICK
- This is Jadav “Molai” Payeng, an environmental activist who works in the Golaghat district in India. In 1979, Payeng looked out at an island where a forest had been clear-cut a hundred years prior. He decided that even though he was only one person, he wanted to make a difference. CLICK
- 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 the first few plants along for years and perfected his approach. He experimented with introducing local fauna, doing things like bringing an entire ant colony to the island in a rowboat. Bamboo shoots gave way to saplings. CLICK
- Saplings turned into a forest. Ants and insects were followed by larger creatures. Little by little, year over year, he learned the craft of forestry by trial and error. CLICK Now, Payeng is called the “Forest Man of India.” and the island has been transformed from a barren sandbar to a lush 1,300 acre forest. CLICK
- In 2010, local authorities were shocked to discover that the island is a haven for endangered species like elephants, rhinos, and tigers. All of this was accomplished because of one person’s commitment to working on an obvious problem. CLICK
- At the start of this talk, I mentioned building big things. The secret is that there is no secret: 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 peoples’ lives and help make them successful. CLICK
- The core ideas I discussed here are simple: do something, start small, get feedback, and iterate. CLICK
- If you commit to these steps, you can have a meaningful, cumulative impact on the world around you… just keep going. The world around us is full of feedback. So I encourage you to go out and build the things that the world needs. CLICK
- Thank you.