Maintaining the Speed of a Startup while Scaling to Enterprise

So I'm going to be talking to you about how you maintain startup speed while working in an enterprise. And I generally kind of 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 startup accelerator taking in kind of 50 startups every year. Taking them from ideation through to product-market fit with technical build. So kind of really cut my teeth in the start startup space, learnt how to move really quickly, get the most value of everything you're doing. And over the last year, I've moved across to a scale-up, so as Rory says I've come to Zip which is a buy now pay later in a massive growth phase. So I've got a lot of lessons on how to keep that startup speed within a corporate.

So 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 you know bring everybody on board about whether the button colour here should be blue or green you need to be really really decisive and you need to be efficient. So startups have a lot of constraints, and constraints can be this great thing because it forces 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. So you've got to just keep this forward momentum because if not you're going to run out of money.

As opposed to that, in corporate, decisions can sometimes move at a glacial pace. So you get this idea that then kind of trickles up through management, you've got your decision-makers, they get analysts involved, you've got research, legal marketing, you eventually get to this cautious implementation that's kind of 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. Very unlike a startup, because a startup the stakes are so high and you often have to act when you've only got 30 percent 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. So I know from seeing you guys on slack there's lots of people here in health care, there's 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.

There's also the issue of legacy software. So 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 like she works for a 200-year-old bank. So all of a sudden you've got this software that it just takes such a long time to do anything with it's not you know, all microservices and build from the ground up like you do with a startup. And as teams grow we just need a lot more process. So I'm working on a project at the moment and we have kind of used a lot of the startup methodology to move things really quickly and I was in a meeting about it last Thursday and we came to this decision really quickly like we used a lot of the startup ways of doing things. And then the product manager is like okay great well you know we've made this decision I'll take that to steering committee in two weeks and then we'll kind of come back with next steps. And that just seems to be the way things work, it takes a long time to get the right people in a room to kind of run these decisions by them. So that's another reason why things are so slow.

It's also about focus, so 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 kind of 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's lots of different priorities, there's lots of kind of transaction cost in trying to move quickly, and make decisions quickly. And all of the handoff and the different communication that needs to happen to make sure everybody's on the same page. And this is why large companies can only move at a fraction of the pace of a startup because our focus is split in a bunch of different directions. So I want to talk a little bit about organisational psychology before I get to some of the solutions because I'm a product person and that's what we do right we don't want to understand the why things work the way we work before we start to
unpack some of the solutions.

So a lot of it can be traced back to this guy so this is Robin Dunbar; he's an anthropologist, he's English, and he did a lot of work on early societies like early tribes and Agricultural communities and primates. And his theory is that humans have about 150 connections that we can make before communications and relationships start to break down. So he was really kind of looking at it with an anthropological lens, but the same principles apply in business. So, groups of less than 100 people, you know startups can operate really cohesively using this informal reciprocal ways to regulate behavior. We all understand where we sit with each other and who owes who a favour, and what that person's agenda is.

So in a startup, the lack of structure and informality means you get work done really quickly, which means you can move really quickly. But as groups get bigger, so over about 150 people, the human brain doesn't have the capacity it needs to stay on top of you know who owes who a favor and what's that person's agenda and who do I go-to for ? So there is this new level of social complexity that means you're not collaborating as effectively as you once did, so to continue to function past 150 you need to get some established rules or some outside authorities.

So for those of you who are in corporate see if some of these sound familiar to you because over 150 you get teams start fighting with each other and it starts to become kind of more visible and intense. I was just dealing with this one this morning, duplicate work happens with surprising regularity. So lots of people are trying to solve the same problems, and that's a great thing, it's very positive. But the results are, there's lots of time wasted or even more infighting between teams as everybody's kind of trying to approach these systematic issues. And literally, that happened this morning, it was you know I was like wait a minute I'm working on this, you're working on this too? And we were kind of at the same place, and so that just happens with these communication breakdowns at bigger size. You get a lot of people in the business who just spend time cleaning up other people's messes. So sometimes entire teams are created to solve problems that were created earlier on in the workflow. And this one kind of kills me as a product person, so it means people in the business spend more time fighting internal problems than they do adding value to your users. And just think about that as a moment because I know people here are designers, and they're engineers, and they’re product people. And I know everybody is really driven into creating 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. So you know very typically, kind of 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.

So there are ways of solving it, you know how do you kind of work around this Dunbar number of 150. So there's some structural things that companies have tried, so 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 you know eight or nine people. And that just means you've got smaller teams, you're not managing timetables and communication and you get more time to actually you know create great products and ship them because you're not spending all of your time communicating with each other.

Gore-Tex have about 10,000 employees, but they start splitting the company or sites every time they get to about 150 marks so they start to get 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 at which they're working.

Uber has solved it, in a really interesting way every time they move to a new region they are treated as their own kind of standalone company. So everybody in the new region are doing things like setting prices, and doing the marketing and all decisions happen at this local level. And you know, it means the brand isn't really unified globally but you get rapid growth which is the kind of byproduct of that and it means they can innovate really really quickly.

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 number. So one thing that does bring cohesiveness is having shared values. So 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.

So 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. So at Zip, it's one of the reasons I joined this company is their very kind of values focused, and our first value is being customer first. So that means as a product person everything we do is for the benefit of the user which is this amazing space to be. So one of the things that can really draw all the different teams together when we start to have kind of infighting or we start butting heads, it's bringing it back to the focus on the user. So 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 you know what they're thinking about our marketing. Because 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, I'm not a massive fan of personas, but I think that can be really helpful if you don't have these videos of just bringing your users to life for people in the company that don't have these regular touchpoints. So having this focus on the user is a great way of aligning all of these teams around these common shared goals.

So fail fast is such a silicon valley cliche and I know it's just this sound byte that everybody throws out there. But failure is a really important part about product experimentation. Because 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 I would much rather fail in a week than fail over nine months. And I've done, that I've worked on projects when I've been kind of back in enterprise before my startup days. Where you know you spend months creating this business case and you go through these implementation plans, and you build it and then you launch it out into market and you don't get this product-market fit and there's nothing demotivating as failing slowly. It really kind of sucks the life out of a team so the goal is about you know 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 know you can nurture and water and they will grow. And you want to know the difference between the two of them before you put too much work into it.

So when I started at Zip, I had a hypothesis about the way that I thought we should structure our shop. And you know I came in kind of like bolshie like this is the way it has to be and this is such a great idea. And I'm going to take you through some experimentation methods in a second. But I used some of these, realized within about three weeks you know what I actually made a ton of assumptions going into kind of that idea. Use these methods, I failed really quickly and I'm actually so glad I did because 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 to spend three months building something that probably wasn't going to be successful.

So we really use the lean startup methodology, so it's this cycle of build, measure, learn. And the goal of doing this is to minimize the time that you spend doing this. So really you should be in this build, measure, learn, cycle, every single sprint. And it's really important that we actually publicise our failures here because you want to create an environment that is okay to fail. Because you're not failing this massive project you're just de-risking your assumptions along the way.

So how do we do that? It's all about experimentation and so 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 behaviour before you go in to build. And 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. So if you're in this very heavily ordered audited market, or if you're like 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. So there needs to be rigor when it comes to commercial sensitivities. I've actually made this mistake before, I worked in a healthcare startup and I was like oh it's simple we'll just use these kinds of lean experiments to do this. And 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. And I've just pulled together this Trello board that we could quickly test whether users were going to behave in the way I thought they were going to behave but uncovered this minefield of legality. So healthcare and very regulated industries are very very different so just be quite aware of that.

So you guys have probably seen this page a lot on Facebook, this is fakebook’s way of experimenting and it's a fake door and it's one of my favorite ways to very quickly test intent. So you put up a link to the feature that you're thinking about so 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. So all they do is just track how many people click on that, they then look at their conversion and that gives them kind of an early indication whether people are interested in it or not. And 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 this really sporadically. If you just want to get very quick intention of 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 like 100 experiments at the same time where everybody's just getting 404s all over the place so just use this one really lightly.

This is a more elegant way of doing a fake door, so this was from a startup who were looking to see if they were going to charge for their services. So they kind of had a two-fold thing. They knew that to be able to charge they had to build in a payment gateway, and then 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 you know what let's just see if anyone's even willing to pay for this in the first place. They built in this fake door into the acquisition flow, where it's like you choose your plan, and then when you clicked on one of the plans you actually ended up on the free account anyway. And that gave them this great way of user intent, and what they were willing to pay for without actually having to build that out. And I think with this startup they actually realized people were exiting at this point like they didn't have enough to be able to charge for it, so then that helped them say well we need to build up more features before we can start to charge for this.

And this was another startup that we're trying to test whether they should offer different languages on their website, and again you know adding languages is probably a good couple of months’ work for your engineering team. So first they just put the languages on the website when somebody clicked on it and said hey thanks for voting for this language this is going to be here soon. So again, a great way of really testing intent, and how many people would use this feature if you actually offered it.

So this was one I ran, again 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 what if we build it will they come. So testing how many people are going to click on this, are they interested in it, and when you get to this: ‘thanks for letting us know you're interested in this we'll email when you when this feature is ready.’

So that was fake door one of my favorites, 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. So the 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 you know generally in startups it's a couple of co-founders running around in the background and going ah like we need to plug this into this. So I do a lot of this, you know when you can use the call center to actually kind of mimic this real tech before you go into building it. So my last startup was artificial intelligence for inclusive recruitment and that sounds really great. I'm going to let you guys in on a little secret, I think 80 percent of early-stage startups are concierge. So, 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. Because for us we knew we didn't want to build this until we actually had somebody who was willing to pay for it.

And there's a company in America called Zappos which is a shoe shop that sell fashion. And they had this very kind of risky assumption in the early 2000s that people would buy shoes online. And so they started off as concierge, in that they went to their local shoe shop, it was Tony Shaw was the founder. He took photos of the shoes, he put them on a website and when somebody bought the shoes he would run down to the shoe shop, go buy them there, post them to the user until he had enough validation that you know people are willing to pay for this. So then he kind of built up the warehouses and the supply chains and the logistics and the e-commerce based on that. But it's this great way that if it failed at that, there was kind of no harm to him apart from putting up a Squarespace website.

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

So Superhuman launched I think in late 99. So they were kind of better faster email. And on the basis of this one-page website they had 60,000 people subscribe for thirty dollars a month before they had broken a line of code. So 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 that very much de-risked that's the fact that somebody was willing to put real money down there. So again smoke test is a great way of telling customer intention before you've actually kind of gone out and built out the full experience.

So you know 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 you know kill them.
• 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.
• 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% users who land on this page will click sign up and if they don't you know what it's not worth doing. So again, don't mess with the users, a 404 page is okay.

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. But you can't just run experiments and end up with this amazing product, you need to kind of have the end in mind to start with. And final point yep, don't get sued, really important one.

So another great kind of startup tenant is do things that don't scale and I found kind of being in a larger company, we tend to get really caught up in edge cases, and well what are we going to do when this happens and what are we going to do when we've got 2 million users. And 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 you know in a year when we've got a million users how are we going to like scale up the call center, or what do we do about this edge case. And it can actually stops you from kind of thinking through these great products and understanding if it's a good idea to start with.

So 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. So an example of this, Airbnb when they launched they weren't getting any traction in New York, and their hypothesis was people were taking these photos with their camera phones and it was like early iPhones and the photos looked kind of crappy, so the apartments looked kind of crappy. So they had a hypothesis of what if we have better photos more people are likely to book. So kind of if they were an enterprise rather than a startup they would have been like oh we should train people on 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. And 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.

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

So 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 kind of personal life. But I've had to come to terms with as a product manager, I need to have a really healthy tension between product moving quickly. I need to get out there, get fast results about whether users are going to love the thing that I'm thinking. And then doing things by going through the proper channels. So I didn't run this talk through kind of our marketing and legal team for a reason, because I don't like to ask for things in case they say no. Because 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 kind of go out there on a limb to bypass certain processes sometimes. Because 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 I had 20 percent of people you know do this particular behavior so therefore let's just go down this way you can stop these really circular conversations very quickly. But so, saying you've got to go out on a limb sometimes and have things that aren't necessarily perfect.

So another tenant of startups is you've probably heard Reid Hoffman say if you're not embarrassed by your MVP you've launched too late. And again, you know if you're launching the covid vaccine, please don't do this, like take the time to be scientifically sound. But if you're launching you know, 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. 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 kind of 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 and so it's a great thing to get it out in market and that's the point of launching early is 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. So 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 tend to approach it because they've got a lot more to lose and so the corporate kind of mantra is you've only got one chance to make a first impression. And 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.

So when we say you know just ship, it’s not about shipping out any garbage because the point is getting it to market sooner. And if you're burning through resources without getting any gain or you're alienating your users, or if 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 like 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 1, am I providing value to my user, and two is this my best attempt at what we have access to now, and am I going to learn first from something?

Be really prepared for a lot of battles because again users are very lenient to you and you're a startup they're very forgiving of kind of less than stellar user experiences. But when you're a corporate, you've got a reputation that you've got to uphold. You know you don't want to be running an experiment that goes out to two million people in your base and you know you had completely the wrong assumption about the way they think about your product or the way they're going to act. So we do a lot of feature flagging; feature flaggings are going to be your best friend, but you can have an experiment or you can have this thing that you've shipped really early but only give it to five percent of your users where you have this 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.

So to wrap it up, you are designers, your 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 and 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.

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 you know, 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 to you early intention from a user and helps you learn a little bit more about the way that they're actually going to behave. And don't ask permission, so 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.