Maintaining the Speed of a Startup while Scaling to Enterprise

Cheryl Gledhill at UXDX APAC. Video: https://youtu.be/BKO8pWGP1uA

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

Why startups move fast and corporates move slowly

[00:00:00] I'm going to be talking to you about how you maintain startup speed while working in an enterprise. I generally don't like starting the first couple of minutes of a talk with a bio, because I think you should just jump straight into the action, but it's quite relevant here. I've spent the last 10 years working for startups in Australia and in the US. I came back a couple of years ago and started working with a startup accelerator, taking in 50 startups every year and taking them from ideation through to product market fit with technical build. So I really cut my teeth in the startup space, and learned how to move really quickly and get the most value out of everything you're doing.

[00:00:39] Over the last year I've moved across to a scale-up. As Rory says, I've come to Zip, which is a buy now pay later company in a massive growth phase. So I've got a lot of lessons on how to keep that startup speed within a corporate.

[00:00:55] What is it that makes startups so fast? How do they get products to market so quickly? Ultimately it comes down to runway. Startups don't have the runway to deliberate for weeks. You don't have time to sit there and wonder if this is the best approach, and bring everybody on board about whether the button color here should be blue or green. You need to be really, really decisive.

[00:01:16] And you need to be efficient. Startups have a lot of constraints, and constraints can be this great thing because they force you to be scrappy and creative. You also don't need to get anything through legal, compliance, risk and marketing, because generally you're one or two co-founders and you are all of those teams, so you can make decisions really, really quickly. You've got to keep this forward momentum, because if not, you're going to run out of money.

[00:01:44] As opposed to that, in corporate, decisions can sometimes move at a glacial pace. You get this idea that trickles up through management. You've got your decision makers, they get analysts involved, you've got research, legal, marketing. You eventually get this cautious implementation that's a bit of a shadow of the original idea, because big companies can afford to make slow decisions. You can take the time to get the full picture before you're acting.

[00:02:14] That's very unlike a startup, because in a startup the stakes are so high and you often have to act when you've only got 30% of the picture. So when you're in a startup it's really hard to understand why big companies are so slow to move. But the reality is lots of us are in really highly regulated industries. I know from seeing you on Slack there are lots of people here in health care, lots of people in finance, lots of people in government, and you can't move that quickly when you've got these regulated industries. You've got to be very cautious.

[00:02:48] There's also the issue of legacy software. My company is seven years old and we've already got a lot of legacy software that we're dealing with. I know Alana from Westpac is going to be talking later, and she works for a 200-year-old bank. So all of a sudden you've got this software that just takes such a long time to do anything with. It's not all microservices built from the ground up like you have with a startup.

[00:03:12] And as teams grow, we just need a lot more process. I'm working on a project at the moment where we've used a lot of the startup methodology to move things really quickly. I was in a meeting about it last Thursday and we came to this decision really quickly, using a lot of the startup ways of doing things. And then the product manager said, "Okay, great, we've made this decision. I'll take that to steering committee in two weeks and then we'll come back with next steps." That just seems to be the way things work. It takes a long time to get the right people in a room to run these decisions by them, and that's another reason why things are so slow.

[00:03:50] It's also about focus. Most startups have one product, one project, one problem that they're trying to solve. At the moment I'm on four major projects, and I'm one person in a product team of 120, and each person I'm dealing with also has multiple projects going on. So everybody's attention is really split. There are lots of different priorities, and there's lots of transaction cost in trying to move quickly and make decisions quickly, with all of the handoffs and the different communication that needs to happen to make sure everybody's on the same page. This is why large companies can only move at a fraction of the pace of a startup: our focus is split in a bunch of different directions.

Dunbar's number and what happens past 150 people

[00:04:35] I want to talk a little bit about organizational psychology before I get to some of the solutions, because I'm a product person, and that's what we do: we want to understand why things work the way they work before we start to unpack some of the solutions. A lot of it can be traced back to this guy. This is Robin Dunbar. He's an English anthropologist, and he did a lot of work on early societies, like early tribes and agricultural communities, and primates. His theory is that humans have about 150 connections that we can make before communications and relationships start to break down.

[00:05:15] He was looking at it with an anthropological lens, but the same principles apply in business. In groups of less than 100 people, startups can operate really cohesively, using these informal, reciprocal ways to regulate behavior. We all understand where we sit with each other, who owes who a favor, and what that person's agenda is. In a startup, the lack of structure and informality means you get work done really quickly, which means you can move really quickly.

[00:05:43] But as groups get bigger, over about 150 people, the human brain doesn't have the capacity it needs to stay on top of who owes who a favor, what that person's agenda is, and who do I go to for this. There's this new level of social complexity that means you're not collaborating as effectively as you once did. To continue to function past 150, you need to get some established rules or some outside authorities.

[00:06:08] For those of you who are in corporate, see if some of these sound familiar to you. Over 150, teams start fighting with each other, and it starts to become more visible and intense. I was just dealing with this one this morning. Duplicate work happens with surprising regularity. Lots of people are trying to solve the same problems, and that's a great thing, it's very positive, but the result is there's lots of time wasted, or even more infighting between teams as everybody's trying to approach these systemic issues. Literally that happened this morning: I was like, "Wait a minute, I'm working on this, and you're working on this too," and we were at the same place. That just happens with these communication breakdowns.

[00:06:49] At bigger size you get a lot of people in the business who just spend time cleaning up other people's messes. Sometimes entire teams are created to solve problems that were created earlier on in the workflow. And this one kills me as a product person: it means people in the business spend more time fighting internal problems than they do adding value to your users. Just think about that for a moment. I know people here are designers and engineers and product people, and I know everybody is really driven to create value for our users. That's what gets us up every morning as product people, and none of us want to be spending our time fighting these internal battles rather than shipping value. Very typically, the business starts to get top heavy. We add more layers of management and more levels of leadership, and we get more rules about how work should flow.

How companies work around it, and the user as the campfire

[00:07:47] There are ways of solving it. How do you work around this Dunbar's number of 150? There are some structural things that companies have tried. Amazon have this idea of two-pizza teams, where every internal team is small enough that you can feed them with two pizzas, so that's eight or nine people. That just means you've got smaller teams, you're not managing timetables and communication, and you get more time to actually create great products and ship them, because you're not spending all of your time communicating with each other.

[00:08:17] Gore-Tex have about 10,000 employees, but they start splitting the company or sites every time they get to about the 150 mark. When they start to get to 150 people, they'll split in half and take the office next door or set up another factory, just so they can keep the cohesiveness and the speed that they're working at.

[00:08:38] Uber has solved it in a really interesting way. Every time they move to a new region, it's treated as its own standalone company. Everybody in the new region is doing things like setting prices and doing the marketing, and all decisions happen at this local level. It means the brand isn't really unified globally, but you get rapid growth as the byproduct of that, and it means they can innovate really, really quickly.

[00:09:03] I know I am talking to a room full of designers and engineers and product people, though, and I don't know about you, but I don't have the choice to say, "Oh well, let's just split the company in three and we'll move next door, and that will solve the problem." But there are other ways that we can work around this Dunbar's number. One thing that does bring cohesiveness is having shared values. You really can't connect people back to a core mission through process and compliance, which is generally what people try and force. It needs to be this emotional connection. So it's the perfect time for product people to step in, because often we are so connected to that emotional space.

[00:09:43] In my experience, a relentless focus on the end user is the campfire that everybody can gather around. It's really this value that we can all live and align ourselves around. At Zip, it's one of the reasons I joined this company: they're very values focused, and our first value is being customer first. That means as a product person, everything we do is for the benefit of the user, which is this amazing space to be in. So one of the things that can really draw all the different teams together, when we start to have infighting or we start butting heads, is bringing it back to the focus on the user.

[00:10:21] One thing that's been really successful in our teams is having the designers not just report back on insights when they run user interviews, but actually gather people around and watch videos of users either struggling with the product, or talking through their financial situation, or talking about what they're thinking about our marketing. People can't really argue with the way our actual users are using things. I know I'm at a design conference so I shouldn't really say this, but I'm not a massive fan of personas. But I think they can be really helpful, if you don't have these videos, for bringing your users to life for people in the company that don't have these regular touch points. So having this focus on the user is a great way of aligning all of these teams around these common shared goals.

Fail fast

[00:11:11] "Fail fast" is such a Silicon Valley cliche, and I know it's just this sound bite that everybody throws out there, but failure is a really important part of product experimentation. If you're fearing failure, you don't take risks, and you end up just creating a me-too product based on something that's already out there in market. Failing fast to me just means lots of things that I try are going to fail, and I would much rather fail in a week than fail over nine months.

[00:11:38] And I've done that. I've worked on projects back in enterprise, before my startup days, where you spend months creating this business case, you go through these implementation plans, you build it, and then you launch it out into market and you don't get product market fit. There's nothing so demotivating as failing slowly. It really sucks the life out of a team. So the goal is really getting that learning quickly, because not every idea has legs. We've all got hundreds of ideas. Some of them will wither and die, and some of them you can nurture and water and they will grow, and you want to know the difference between the two before you put too much work into it.

[00:12:24] When I started at Zip, I had a hypothesis about the way that I thought we should structure our shop. I came in thinking, "This is the way it has to be, and this is such a great idea." I'm going to take you through some experimentation methods in a second, but I used some of these and realized within about three weeks that I'd actually made a ton of assumptions going into that idea. Using these methods I failed really quickly, and I'm so glad I did. I came in, I tried something, I failed, and it was great, because it just freed up my headspace to move on to the next thing, and I didn't put a team of engineers on to spend three months building something that probably wasn't going to be successful.

[00:13:10] We really use the lean startup methodology. It's this cycle of build, measure, learn, and the goal of doing this is to minimize the time that you spend on each loop. Really, you should be in this build, measure, learn cycle every single sprint. And it's really important that we actually publicize our failures here, because you want to create an environment where it is okay to fail, because you're not failing this massive project, you're just de-risking your assumptions along the way.

Experimentation and its limits in regulated industries

[00:13:41] How do we do that? It's all about experimentation. When I say experiment, an experiment is something that you can be crafting in a day or two. If your experiment is taking longer than a week to pull together, you need to think about a different way to experiment, because you're not thinking about it in the right way. It needs to be something that you can very quickly push up, get actual user feedback, get real intentions and real behavior, before you go into build.

[00:14:04] I will just caveat this by saying a lot of these methodologies are things that we use in lean startup, so I'm assuming that you're working with digital products in an unregulated market. If you're in a very heavily audited market, or if you're building engines that go into airplanes, please ignore everything I say, because I don't want my airplane falling out of the sky because you're running an experiment. There needs to be rigor when it comes to commercial sensitivities.

[00:14:36] I've actually made this mistake before. I worked in a healthcare startup and I thought, "Oh, it's simple, we'll just use these lean experiments to do this." I didn't realize that when you're running healthcare, you've actually got to store this data for about eight years afterwards in certain ways. I'd just pulled together this Trello board so we could quickly test whether users were going to behave in the way I thought they were going to behave, but it uncovered this minefield of legality. So healthcare and very regulated industries are very, very different. Just be quite aware of that.

Fake doors

[00:15:14] You've probably seen this page a lot on Facebook. This is Facebook's way of experimenting. It's a fake door, and it's one of my favorite ways to very quickly test intent. You put up a link to the feature that you're thinking about. Facebook might be thinking, "Oh, we should launch a marketplace." Instead of building out the marketplace, they'll think, how many people are interested in this? And they'll see how many people click. All they do is track how many people click on that, then they look at their conversion, and that gives them an early indication of whether people are interested in it or not.

[00:15:45] I know I'm talking to a room full of designers here, and you're all going to say, "But that's a bad experience." And you're right, it is, and every designer says that. It's an okay thing to do if you're going to use it really sporadically. If you just want to get a very quick read of intention, like "Is anyone interested in this feature? I don't know, let's put a link on the site for a day and see what percentage of people click," that's an okay thing. But you don't want to be running 100 experiments at the same time where everybody's just getting 404s all over the place. So just use this one really lightly.

[00:16:16] This is a more elegant way of doing a fake door. This was from a startup who were looking to see if they were going to charge for their services. It was a twofold thing: they knew that to be able to charge, they had to build in a payment gateway, and once you build in a payment gateway you need to build in a way to do refunds, so you then need to up your customer service. So they thought, "Let's just see if anyone's even willing to pay for this in the first place." They built this fake door into the acquisition flow where you choose your plan, and when you clicked on one of the plans you actually ended up on the free account anyway. That gave them this great read of user intent and what they were willing to pay for, without actually having to build that out. With this startup, they actually realized people were exiting at this point. They didn't have enough to be able to charge for it, so that helped them say, "We need to build up more features before we can start to charge for this."

[00:17:17] This was another startup that was trying to test whether they should offer different languages on their website. Again, adding languages is probably a good couple of months' work for your engineering team. So first they just put the languages on the website, and when somebody clicked on one it said, "Hey, thanks for voting for this language, this is going to be here soon." Again, a great way of really testing intent and how many people would use this feature if you actually offered it.

[00:17:44] This was one I ran. I'll do this if there's something that's going to take significant engineering work and it's something fairly new. Before we actually go ahead and build it, I really want to see: if we build it, will they come? So I test how many people are going to click on this and whether they're interested in it, and when you get to this you get a "Hey, thanks for letting us know you're interested in this, we'll email you when this feature is ready."

Concierge tests and smoke tests

[00:18:12] So that was the fake door, one of my favorites, and one of the easiest ways to run an experiment. You can pretty much put it up in five minutes. Another one of my favorites is known as a concierge. A concierge is like that little guy in the hotel. It's a solution with a little bit of tech, and as far as the user's concerned you actually have this technology running in the background, but it's actually, generally in startups, a couple of co-founders running around in the background going, "Ah, we need to plug this into this." I do a lot of this, where you can use the call center to mimic this real tech before you go into building it.

[00:18:47] My last startup was artificial intelligence for inclusive recruitment, and that sounds really great. I'm going to let you in on a little secret: I think 80% of early stage startups are concierge. When we say we're AI, or when we say we're blockchain, we actually mean we're a couple of founders running around pretending to be AI. For us, we knew we didn't want to build this until we actually had somebody who was willing to pay for it.

[00:19:14] There's a company in America called Zappos, which is a shoe shop. They sell fashion, and they had this very risky assumption in the early 2000s that people would buy shoes online. So they started off as a concierge. Tony Hsieh was the founder. He went to the local shoe shop, took photos of the shoes, and put them on a website. When somebody bought the shoes, he would run down to the shoe shop, go buy them there, and post them to the user, until he had enough validation that people were willing to pay for this. Then he built up the warehouses and the supply chains and the logistics and the e-commerce based on that. It's this great way of testing, because if it failed there was no harm to him apart from putting up a Squarespace website.

[00:20:03] A more high-fidelity way of testing, and again a lot of startups really do this, is the smoke test. It's a method for determining if there's enough customer demand for your value prop when you haven't actually built out the service or the startup yet. Often it's a one-page website that describes the product, and it gets the user to either sign up or put in some form of payment. It could be your email address and "we'll let you know when it's ready." The more high-intent one is to get somebody to sign up with real money.

[00:20:34] Superhuman launched, I think it was either last year or late '99 [?], as better, faster email. On the basis of this one-page website, they had 60,000 people subscribe for thirty dollars a month before they had written a line of code. Straight away that gives them the intent. It tells them that users are willing to pay for it, so go ahead and build the product that you're thinking of, because if you build it, it's very much de-risked by the fact that somebody was willing to put real money down. So again, the smoke test is a great way of telling customer intention before you've actually gone out and built out the full experience.

Rules for experimenting

[00:21:17] So experiment away, but definitely live by a couple of rules. Understand your industry boundaries. Don't experiment with other people's money, or their health, or anything that could kill them. That is not the place for experimentation; it is very much for customer intent. Be really tolerant of failure. Some of these are going to fail, and that's a great thing. The best thing about this is you can kill off bad ideas quickly, and it's not even that they're bad ideas; it might be that you're too early or too late for the market.

[00:21:50] Have really clear metrics going into this. Don't just experiment for the sake of it, and don't just think, "Oh, I wonder if users like this." Have a really clear hypothesis, like "I think 40% of users who land on this page will click sign up, and if they don't, it's not worth doing." Again, don't mess with the users. A 404 page is okay.

[00:22:11] But experimentation is not a replacement for ideation and discovery. You can't experiment your way into a great product. You need to start with this great product vision and experiment on the way to de-risk the fact that somebody might not want it, or they might not be willing to pay for it. You can't just run experiments and end up with this amazing product; you need to have the end in mind to start with. And final point: don't get sued. Really important one.

Do things that don't scale

[00:22:43] Another great startup tenet is do things that don't scale. I've found, being in a larger company, we tend to get really caught up in edge cases: "What are we going to do when this happens, and what are we going to do when we've got 2 million users?" A lot of the time that can really stifle early thinking when you're trying to launch something new, because you're trying to think about what's going to appeal to people now, but also, in a year when we've got a million users, how are we going to scale up the call center, or what do we do about this edge case? It can actually stop you from thinking through these great products and understanding if it's a good idea to start with.

[00:23:22] Startups do this because they actually don't have the runway to scale, but it's a great way of really getting that early validation. An example of this: Airbnb, when they launched, weren't getting any traction in New York. Their hypothesis was that people were taking these photos with their camera phones, early iPhones, and the photos looked crappy, so the apartments looked crappy. So they had a hypothesis: what if, with better photos, more people are likely to book?

[00:23:51] If they were an enterprise rather than a startup, they would have said, "Oh, we should train people in how to take better photos, and we'll do this online training and get them to take tests." They're a startup, so they just made a snap decision. The two founders flew out to New York, they rented a $5,000 camera, and they went door to door to the Ubers [?] that were listed and said, "Can we come in and take photos for you?" They did it for about 20 different apartments in one day. Super low tech, really effective. They found that once they put the photos up there, they got three times as many bookings on the listings that they'd taken photos for, and by the end of the month the revenue in New York had doubled.

[00:24:31] If you think about that, it's this incredibly low-tech, unscalable way of doing something, but they got this early validation, and that enabled them to really set up the photographer program. If you have a look here, this is where they started the photographer program. Obviously it wasn't just photographs that led them there, but it was this great way of getting early validation that yes, our hypothesis is correct, now let's build this thing that's going to scale across the world in different cities. They didn't sit there navel gazing, going, "I wonder if this is the problem." They just got out there the same day and made it happen.

Being comfortable as a disruptor

[00:25:12] If you want to keep moving like a startup within an enterprise, one of the things is you have to be comfortable being a disruptor. I'm a middle child, I'm a peacekeeper, I'm really conflict averse in my personal life. But I've had to come to terms with the fact that as a product manager, I need to have a really healthy tension between product moving quickly, getting out there and getting fast results about whether users are going to love the thing that I'm thinking of, and doing things by going through the proper channels.

[00:25:43] I didn't run this talk through our marketing and legal team, for a reason: I don't like to ask for things in case they say no. The second you ask for permission, it gives people a reason to say no. If you've never been told no, you can just get out there and apologize afterwards. So I think to make great products, you have to be willing to go out there on a limb and bypass certain processes sometimes. You could sit there for hours or weeks in meetings going, "This is my hypothesis, I think we should do it this way." Or you could just get out there that day, put an experiment in market, and come back the next day and say, "Hey guys, I ran an experiment, and 20% of people did this particular behavior, so therefore let's go down this way." You can stop these really circular conversations very quickly. But that said, you've got to go out on a limb sometimes and have things that aren't necessarily perfect.

If you're not embarrassed by your MVP

[00:26:43] Another tenet of startups: you've probably heard Reid Hoffman say, "If you're not embarrassed by your MVP, you've launched too late." Again, if you're launching the COVID vaccine, please don't do this. Take the time to be scientifically sound. But if you're launching Snapchat, of course, ship it out there and get your user behavior first. Because of the importance of speed and being first to market, you really want to be launching fast and have that first mover advantage.

[00:27:15] You've also probably made a ton of assumptions about your customers and how they're going to use your product, and you're probably wrong. So eventually the embarrassment comes from, "Oh my God, I had this assumption, and we put this out in market, and people use this thing in a very different way than the way we intended it." But you're learning from that, so it's a great thing to get it out in market. That's the point of launching early: to start learning sooner. You've really just got to get it out there and get that user behavior to be able to go ahead and take that next step for product.

[00:27:50] There really is a tension here, because startups come from this attitude of "You should be embarrassed by your MVP, and that's okay," and corporates, because they've got a lot more to lose, approach it differently. The corporate mantra is "You've only got one chance to make a first impression." Realistically both of them are right, because people are much more forgiving of startups than they are of corporates, and you've got to find that tension about where your company can play.

[00:28:20] When we say "just ship it," it's not about shipping any garbage, because the point is getting it to market sooner. If you're burning through resources without getting any gain, or you're alienating your users, or you're getting lawsuits, you are shipping it way too soon, and don't do that. But if all that's going to happen is a user goes, "Huh, that's not their corporate font," really, that's not such a terrible thing if you're getting learnings. So before you ship anything you should just be thinking: one, am I providing value to my user, and two, is this my best attempt with what we have access to now, and am I going to learn from it?

[00:29:02] Be really prepared for a lot of battles. Again, when you're a startup, users are very lenient to you. They're very forgiving of less than stellar user experiences. But when you're a corporate, you've got a reputation that you've got to uphold. You don't want to be running an experiment that goes out to two million people in your base when you've had completely the wrong assumption about the way they think about your product or the way they're going to act.

[00:29:32] We do a lot of feature flagging. Feature flags are going to be your best friend. You can have an experiment, or this thing that you've shipped really early, but only give it to 5% of your users, or only give it to 10% of your users. That way you can ship something that's not necessarily incredibly watertight, but you can get these early learnings about the way people are going to be using your product.

Wrapping up

[00:29:59] To wrap it up: you are designers, you're product people, this is what you do best. Really center your team around the user. It is the one thing that everybody can gather around, even at a corporate. Just keep that user in mind and keep bringing it back to the user, because you can fight in teams internally about the best way to do something, but you really can't argue with users' attitudes when you actually see them using your product. So always bring it back. Bring any videos you can, bring any quotes, just bring those users to life for the rest of your company who don't necessarily talk to your users every day.

[00:30:35] Get out there and fail. Celebrate your failures, learn from your failures, don't make the same failure twice, but really celebrate the learning that you're getting out of it. Experiment. I've only shown you a couple of techniques here, but there are so many different ways that you can experiment. It doesn't have to be scalable, it doesn't have to be something that eventually makes it into production. It should be anything that gives you early intention from a user and helps you learn a little bit more about the way that they're actually going to behave.

[00:31:04] And don't ask permission. Get very good at apologizing and pretending: "Oh, sorry, was that the process? I didn't know that had to go through you. Sorry, I'll do that next time." But don't wait around for permission. Just get out there, get the learnings, and then you're going to come back with actual data about how users are going to behave.