How Not to Ship Your Org Chart, with veteran product designer Brad Ellis

Ep 1

Nov 16, 2022 • 58 minutes
Brad Ellis pulls from his experience designing for Square, Lyft, and many other products to share what he’s learned about the incredible value of user testing, scaling product design across a large org, and how to make great experiences instead of shipping your org chart.

Allen Pike: Welcome to It Shipped What Way: where we talk to product leaders about the lessons they’ve learned helping build great products and teams. I’m Allen Pike, our guest today is veteran product designer Brad Ellis, who’s worked at Square, Airbnb, Lyft just to name a few. I always love chatting with him about the joys and pains of product design, so I’m thrilled to welcome Brad.

Brad Ellis: Hi Allen.

Allen Pike: I want to dig into all sorts of fun stuff with you talking about building stuff and all the foibles in doing that, but a nice place to start is always to give people some context on where you’re coming from, what you’ve seen, is the origin story, the origin of Brad Ellis. And as I understand it, your first big gig, not your first gig at all, but your first big gig was at Square, but it wasn’t so big at the time. How big was Square’s product design team when you joined?

Brad Ellis: I was the first designer they hired. They had a designer on the founding team and then I was the first one after that. So I think I got hired and then I started two months later, so by the time I started I was employee 42, the Magic Number.

Allen Pike: Okay. And you were basically the design side, was you and this founder or probably, I would imagine only a percentage of the founder’s time because if you’re a founder you probably have things to do other than-

Brad Ellis: No. So they had two founders and then they had sort of that founding team, that six people or whatever that got it off the ground. And so one of those guys, his name was Robert Anderson and still does some contracting work for them. And he had worked on MobileMe before that, before turning to iCloud. It was only MobileMe for what, a year in there?

Allen Pike: And there was dotmac before that I think.

Brad Ellis: Oh yes. Oh exactly. iTools, all sorts of things.

Allen Pike: Yeah.

Brad Ellis: Yeah, he had worked on that. So he was doing full time and then I was the first designer they hired in to sort of be like, okay, now we got to make a team. And then I was the manager of that team and then helped scale that up to 10 from there before I got out of there.

Allen Pike: Before you got out. That’s a pretty rapid growth if you were there for two or three years and sort of going from, you’re the first hire outside the founding team to running a team of 10 designers.

Brad Ellis: I started at 42 and then it was like a year and a half later, we were at 340. So it took a year. It was an insane amount of growth and just very interesting to be like, every time we were doing … I don’t remember what our cadence was at, this is sort before the agile two week style. I think we were doing four week maybe. But every release you have two or three new people on the build every single time. And so the amount of turmoil, it felt like most of our energy was just sort hugging ourselves together as we move desks and have to reorg constantly because we need to. So it was an interesting time for sure.

Allen Pike: Yeah. People will debate sometimes about what hyper growth is. Is it a hundred percent a year? Is it 50% a year? Is it two 200% a year in terms of team size? And obviously the faster you’re growing, the more growing pains and problems you have. But I would say that growth rate that you’re describing is way beyond any threshold for hyper growth.

Brad Ellis: Absolutely. And also there’s hyper growth in different departments too. So is it that your support team is growing like crazy or is it that your engineering team … where are those people being added? Are you scaling up marketing? And in that time at Square, the COO had a cap on the number of support people because he was like, if I don’t just let this run wild, then we’ll have three floors of support. We have to figure out how we’re going to scale better as our business scales. It can’t be what we’re doing here. But before that, I was up in Seattle, so that was where I grew up, where I got my first start. I worked at the Apple store when I was in college.

Allen Pike: That seems like a part of a lot of people in your generation or our generation’s origin story is the Apple store is a really great first gig for a smart product oriented person that doesn’t yet have the resume that will get them hired on at a Square or something.

Brad Ellis: Yeah. It was I think the fourth year that the Apple stores had been open, so they were still figuring some things out, making some changes. While I was there I did theater presentations and I did one hour trainings with people. That was my gig. I was called a creative, I don’t know if they have different names for them now, but it was super interesting. So I worked there for the Intel transition and then a little bit for the iPhone before I got out of there at the Apple store. And what was very interesting was helping people unbox their first computer and this would be like 2006 and they’re like, what the hell is this thing? What do all these buttons do? So showing them, here’s the paradigms of a computer, here’s the mouse. Oh not that way, actually it’s this way. As they go through that and learning all these pitfalls, what do people need to learn? And so through that hour, I’m sort of making a dynamic lesson plan based on what they’re interested in.

Allen Pike: And what their capabilities are.

Brad Ellis: Absolutely. And adjusting to that because there’s so many ways to do things on a computer. So what are you interested in? Okay. There was one lady I worked with, she was like, I want to really capture my recipes. So I bought a printer and I bought a computer and I’m going to write all my recipes down so they’re nice and legible so I can pass those down. So I was showing her here, here’s text edit, here’s how we format some things. Let’s figure out how your recipe should look and em dashes and all that kind of stuff. And then I got to the end and I was like, and here’s how we save files. I was going to take her into that part of the system. And she’s like, I’m not going to do that. No that’s too much.

Allen Pike: I’m just going to run the computer. It’s just going to run forever.

Brad Ellis: I’m going to print them off and then I’m going to close the document and I’m not going to save. And so, really looked very interesting, she’s like, why would I need to save it? Just very interesting right? But helping people with that, what was interesting was how staggeringly complicated so many things were. Just like, here’s iTunes, let me just point to all the pieces of UI around here for things you want to do. And so the difference then when the iPhone came out and I was doing the same thing, it was so much easier to explain and people got it so much faster just because it didn’t have, I don’t know, all this legacy gruff, you didn’t have to understand as much about how it worked.

Allen Pike: You don’t have to save the file and know where it was being saved and the person who was like, I’m not going to save, you don’t have to have that conversation.

Brad Ellis: Well yeah, they get … too bad, it’s going to save anyways.

Allen Pike: So was that formative then for you to see … go kind of at the beginning of your career, see different loops of what things hung people up, what things that maybe the designers of these products assumed would be intuitive or straightforward and maybe seemed intuitive when it was demod to a bunch of geeks at the Mac World Expo or whatever, but then it hits the real world and then not so much. Did that help inform your thought of thinking about product design?

Brad Ellis: A hundred percent. Very interesting to just work with people and see if something wasn’t going to slide. Sort of see, if they cared about something? How much does this feature matter? I thought that was really interesting and I think it helped a lot then in the design practice of doing user interviews and research. As I said before, I have an hour with these people, I maybe only see them one time. And so it’s like, okay, how can I figure out very quickly what is your goal? Why are we here? How can I help you have a satisfying time? Not just like what am I here to talk about, like a STEM speech? But what’s that interaction between the two of us was very helpful because … and going forward into design, there’s a lot of people you talk to internally that are like, well the goal of this is for them to buy my product. And it’s like, well I can’t tell that to people. People have their own goals and we have to figure out what those are and then map our product to that.

Allen Pike: And if we help them achieve their goals, they’ll buy the product.

Brad Ellis: Absolutely. So some of those sort foundational things were very helpful in terms of research and how to talk to people and how to be comfortable around people explaining things and how to get used to apologizing for technology. And that was a lot of the times when they’re like, well why does it work like that? And you’re like, I’m so sorry, there’s three buttons at the top, one closes, one minimizes, one makes it full screen. Trying to explain and they’re like, why would you have to hold the option button down to do this? You’re like, I don’t know. That’s how they decided to do it.

Allen Pike: Option is the one they chose. It could have been any other button but it was that one.

Brad Ellis: Yeah. That’s just what happened. So actually before that, this is what’s crazy about the modern technology world is in fourth grade is when I started to learn Photoshop because there was an Adobe campus in Seattle and they had classes on Saturdays. And so I started taking classes and I was there every Saturday at the Adobe campus down in Fremont.

Allen Pike: In fourth grade?

Brad Ellis: Fourth grade, fourth, fifth, sixth grade. And then Limewire Kazaa, those stealing things happened. And so boom, got a copy of Photoshop until I could get one in high school, which I got through our photography department through the Gates Foundation, I was able to get a license officially for Photoshop. Anyway, so I’ve been using Photoshop since I was in fourth grade, the whole way through.

Allen Pike: So by the time you get your first big Silicon Valley tech job, you’re designing Square’s logo and you’re like, I’ve been doing this for 15 years. Even though you’re like 20.

Brad Ellis: Exactly. Exactly. And so the first gig I did before I even went down to Square is I was working with Gus Mueller of Acorn and at the time also VoodooPad. And I was doing his tech support, writing documentation for how to do Acorn stuff because I knew all the techniques from Photoshop and I did the VoodooPad icon, it was maybe my first actual paid icon gig. And then from there I went to go work for RogueSheep was the name of the company. It was a bunch of ex Adobe people. And they wrote InDesign, left Adobe and they were mostly making InDesign plugins because InDesign is actually written on its own SDK, which is very funny. So it’s very extensible. If you want to add a column to some panel you can do that, which is incredible. And so we were making custom, what does New York Times need for their development stack, doing sort of bespoke work in that way. So I was working with them and then we had a little bit of an economic downturn. People stopped investing in that way, right as the iPhone SDK came out. And so we took a stab and made an iPhone app called Postage, which won an Apple design award. Do you remember this one Allen? I don’t know if we were hanging out at this time.

Allen Pike: I don’t know if I know. I certainly remember the time. In retrospect, what interesting coincidence that the iPhone SDK came out around the time that that 2008 economic downturn kind of reset a bunch of people’s career paths. And then there was this huge opportunity, which even then seemed huge, but now in retrospect was way bigger than we realized happening at the same time.

Brad Ellis: Yeah, it was weird. It was a gold rush, right? Remember there was talk of trism, making a million dollars a day or flight control or whatever.

Allen Pike: Flight control. Field runners and all those games and also just little utilities and things. Even just whoever had the top search term for flashlight app and stuff like that. Back when a flashlight app was just a white screen.

Brad Ellis: Absolutely. It was a weird time for sure. So yeah, it was in that little span that we made an app. This app, it was essentially Instagram but you emailed the final output to people.

Allen Pike: Which seemed reasonable at the time.

Brad Ellis: It did. And it was actually made before … it’s so funny to think back at that time, we didn’t have an email share sheet so we had to make an email server.

Allen Pike: So it wasn’t even like … because when I hear Instagram but email, it’s like, well that way you don’t have to have a server but you still were running a server and need to do all that.

Brad Ellis: Exactly. Because there was no SMS sheet that you could pop up. I mean there was no share sheet. You could copy things to your clipboard. No, you couldn’t even copy things to your clipboard. It was before the clipboard. Yeah. So we had to do all that shit. So we actually made our own mail server and then we sort of spoofed the from to be from you. And we actually got a call one day because we were doing something we weren’t supposed to. We were looking through your contacts and then we were using a private API to figure out what the phone number was of the phone that you were on. And then we were looking to see who that was and then if they had an email address, then we used that as your from when you sent an email.

Allen Pike: Best customer centric design Brad.

Brad Ellis: Right. But we got a call before that dub dub where we won the ADA and someone at Apple was like, how are you doing this? And we’re like, I don’t know, what do you mean? And they’re like, okay, don’t use private APIs please. And so that was really funny. I mean definitely caught us. But the reason why that app was interesting at the time was that it was like a Wizzywig. So it was a wizard, there was steps, but you were making a little postcard and you were hitting the next button and then it was zooming around on screen and you can two finger pinch and rotate and we had to write all that stuff custom. It was the first app that ever had a white nav bar because I don’t know if you recall, but at the time you could tint the nav bar but the text was always white on top of that.

Allen Pike: Yeah. At that time you had to do it again from scratch to make it white, didn’t you? Or it was another private API?

Brad Ellis: Well yeah, I mean maybe we didn’t get caught on that one.

Allen Pike: Okay.

Brad Ellis: Yeah it was. It was. But very interesting foundational stuff. The UI for it was Instagram knocked it off. So you’ve seen the UI, you’ve done it if you’ve ever posted a photo and there’s a bottom carousel of things you can swipe between … that goes between that. And it was such a different time on the iPhone because no one had ever done a horizontal scrolling thing before. It was a functionality of a scroll view, but everything scrolled vertically just like … it was in the before times. You had a 10 megabyte download limit over cell, just a different time. It’s interesting to think back at that because I don’t know that was 09. But so many things changed after that, that would’ve made that product a more successful product had those changes been around then. But they weren’t, we didn’t have in-app purchases, didn’t have a mail sheet, didn’t have whatever, an ability to add content after the fact. People couldn’t download it over a cell, people couldn’t … whatever, xyz. And so it’s always interesting to see how technology changes in all those different ways.

Allen Pike: One of the fundamental things that comes up when we’re talking about product, either maybe if you’re talking about founding or joining an early stage team or you’re talking about the really big ambitious efforts that maybe Apple or Meta or whatever are taking on is, when is too early and when is too late for something like this? Basically this part were you’re saying like … it sounds like it was a little bit too early or maybe it was just sort of the right time, but it’s slightly off from maybe what Instagram did, but around the same era and people discussing the same thing about VR or AR or whatever, it’s like, oh okay, are they too early or are they just early enough that they’re going to be in the right place to capitalize it? Do you have a sense that there’s anything you can do to try to time that or you just try to make a really great thing and then hopefully it’s early enough but not too early.

Brad Ellis: I don’t know. Yeah, I was thinking about this the other day because when there was the compact and the Palm Pilot, all those earlier things before the phone, there was some great software for those. People were trying to write software for it.

Allen Pike: I built Palm Pilot apps, it was one of my first jobs.

Brad Ellis: You did do that. Okay. I figured.

Allen Pike: Black and white.

Brad Ellis: But that success, anyone who did have success in that industry that didn’t ladder into success on the phone. All the Windows mobile devs that didn’t ladder into success later with other things. I don’t know, I mean do you have an opinion about … all those things were very early, but I don’t think that helped anyone at all.

Allen Pike: It didn’t help the platform people. So if you’re Microsoft and you were doing the pre iPhone stuff, obviously the iPhone stuff wiped them away. I mean I’m biased maybe on this perspective, but I feel like my time, it was formative also early, just like some of the stories you’re telling, but my time working on how do I make something easy to use on a tiny screen even though it was black and white. So it was even more constraints than the iPhone had, was helpful for me thinking about how do you build a great product on a slightly larger, slightly more detailed but still simplified screen when the iPhone came out. But that’s more about skill transfer of an individual, rather than if you build a whole organization who’s … And as far as I know that there’s like a 99% death rate of the companies that were built around Palm Pilot products making the transition. The company that I worked at did end up doing that iOS app but they didn’t flourish with it. Obviously the skills of building a code warrior C++ Palm Pilot app didn’t transfer into the next generation in the same way.

Brad Ellis: Yeah, so to answer your question is where are we? Maybe we’re still in that 2004 kind of place where all these devices we have around now are the compacts and the Palm Pilots of the world and we’re still waiting on what is this next ladder step?

Allen Pike: I hope so. I hope that there’s a next ladder step that’s just going to blow things away and open it all up again. Ben Thompson argues maybe no, maybe we’re at the end of those big sweeping changes that sweep away all the incumbents, but it’s so much more fun when that happens.

Brad Ellis: Yeah, we’ll see. It’s still annoying to wear an Oculus. We’ll see if the new one is better.

Allen Pike: Everyone has their own thing and maybe some people feel like, oh, crypto is the thing that’s going to change everything or whatever the particular technology. But I have a bit of a soft spot for the VR AR in terms of optimism that, I mean I don’t know whether it’s going to be in two years, but in 10 years I’m pretty optimistic about, that it’s going to make a big impact. I don’t know if any company other than the multi-billionaire companies that are already working on it have much opportunity to be the hardware vendors. But the idea of building really compelling experiences they interact with and can enhance your day to day life in user centric, people centric ways, that’s exciting to me.

Brad Ellis: Absolutely. I think what’s interesting, the part that gets me excited in the time you’re talking about working on Palm Pilot stuff and the early iPhone, we got to be inventors because no one had figured out the best way to have a spreadsheet on a Palm Pilot yet. And you get to figure that out. And we’re doing that right now with some of the VR stuff. It’s like, what’s the best way to edit a text document? What’s the best way to edit a spreadsheet in VR? What’s the best way to look at a spreadsheet?

Allen Pike: What’s the best way to move around in space? What’s the best way to point at things?

Brad Ellis: We’re still figuring all those things out. And so it’s very exciting. I haven’t dived all the way into it because it’s like the barrier to entry’s a little too high. It’s like I can’t just bust open whatever Figma and try to make an AR experience. It’s a little bit of a harder nut to crack.

Allen Pike: And that’s one of the things that makes it an interesting space for me is that because there’s that higher barrier to entry, there’s probably some opportunities that are just sitting there so to speak, that we don’t have 100,000 people all simultaneously exploring product solutions to things. We have maybe thousands of people, especially when you think about non-game things. So the challenge is that of course that if you’re going to go in and dig in to do that, you pretty much need a company around it that has some business case or pitch. And probably then investor money as you’re committing down a path of uncertainty, which it has pros and cons of going and making a pitch of okay, we’re going to be excel for VR or whatever it is. And if the hardware isn’t there yet, it can sometimes be a difficult pitch. But it’s interesting potential work for sure.

Brad Ellis: Maybe Meta will save us all and just make the future.

Allen Pike: Maybe. I mean they’re certainly going to try. So the title of the show is, it Shipped that way. Not everybody will have a story that they can share of something that shipped maybe in a surprising or unfortunate way. But do you have an it shipped that way story that you can tell that maybe you learned something from or observed other people learning things?

Brad Ellis: I definitely do, but I want to rewind for a second on it shipped that way. I think there’s a few different tracks and ideas about what does it mean to ship at all. And so you have an opinion about this, there’s an agile approach, there’s that big quarters, so the Apple OS, I don’t know what they’re doing, they have the one main ship a year.

Allen Pike: The big yearly and then now they’re starting to kind of get a little bit more iterative where their biggest ship is once a year. But then if something is maybe threatening to risk the release then they’ll push it and have some iterative updates through the fall.

Brad Ellis: Absolutely. And Adobe moved to this model as well. And I think it’s interesting now when they talk about all their product announcements at Adobe MAX, which is coming up soon, I think. That they will announce features that came out four or five months ago like they just are coming out right now because no one knew. And they’ll announce features that are coming out today and they’ll announce features that are going to come out in the next five months. So you sort of announce the whole year in this one moment. So we can have a big marketing push but then actually when the feature comes out it’s a little bit looser.

Allen Pike: It kind of seems like the best of both worlds to me as a person who’s worked on product on huge deadlines that were unnecessarily complicated.

Brad Ellis: And I’ve worked some places where one of the things that we’ve quote unquote shipped that changes everything is we’ve just dropped support for an older platform. Okay, we just dropped support for iOS 13. Oh my god. And it’s like now even though we’re on iOS whatever, 15, 16, it makes me … I got like, let’s go back and let’s watch the WWDC from iOS 14. Let’s figure out all this cool shit we get to actually use now because there’s a bunch of things we weren’t able to do because we still had to support 13. And so you sort of have to go back in time to be like, now we get to use whatever. We get to use Grand Central Dispatch. We get to use collection views. What? Yeah. Because we weren’t able to use that before. So anyways, something’s interesting in there. The people that ship a lot, I have found there to be a reduction in rigor around shipping, I will say. So if you are on this every two week thing, there’s a lot of people I have interacted with who are like, it’s fine if it’s shipped that way. We’ll just come back later and fix it Brad. We don’t.

Allen Pike: And that every two weeks it goes beyond that where there’s some large organizations with consumer facing products, often ones that are a little bit lower stakes where they’re shipping multiple times a day and there’s things just rolling out to production all the time and they have a whole bunch of monitoring that sort of undeploys it if the metrics starts to go sideways based on those things going out and there’s no idea of a version of the product, it’s just a continual rolling thing with a whole bunch of feature flags rolling out and then a whole bunch of feature flags getting turned on for 1% or 0.01%, 1%, 10% of the people, the culture, assuming it’s a low stakes enough company like maybe a payments company wouldn’t do this. But somewhere like Facebook where, how bad is it if you don’t see the thumbs up button rendered quite correctly on this post, that that process of oh let’s just ship it and then if we unship it a few hours later or we refine it tomorrow, then it’s probably fine.

Brad Ellis: Absolutely. I think I heard someone say one time, the sun never sets on Google’s shipping schedule. They’re always shipping around the world. Absolutely. And the AB test part is another thing with did it ship? Did it ship? If it shipped to 1% of people, did it? Can I tweet about it? And I have worked … I mean especially in … It’s so hard because there’s technology things and the sort of technology things that are social and that has been my least favorite thing with AB testing and shipping is like, we’re on a Zoom call and I’m like, oh I have this new button and other people are like, I don’t have the button. And now we’re on the same phone call with the same app running and we have different features and it’s been a weird time and I don’t like that.

Allen Pike: Yeah. Any social feature … a lot of people learn this the hard way in this sort of big boom of everyone trying to make a social network. That happened a few years ago, it’s now thankfully settled down a bit. But shipping anything social is just way harder than shipping most other categories of things. It’s lower stakes in the way that you can be constantly shipping things and whatever, but because the way that users perceive the thing and interact with one another around the thing is very difficult to predict and difficult to measure for some of the reasons that you mentioned among others. It’s just really hard.

Brad Ellis: Absolutely. Do you know what the Winchester Mystery house is?

Allen Pike: I do. But you can tell the story if you-

Brad Ellis: I mean no, just real briefly that there’s this house down in South Bay I think it is, here in California. It was always under construction and also no project was sort of ever done. Or if it was done then we’d just start a new one.

Allen Pike: I think I know where this is going. Yes.

Brad Ellis: Yeah. You know where this is going Allen.

Allen Pike: Yeah. It was somebody who had become obsessed with building and building and building the home and maybe they were not well, but they had the money to make it continuously being changed and modified but never to any grand final design of any coherence.

Brad Ellis: Yeah. And so I had a VP of design one time come to me and say, Brad, why did this ship this way? What happened? And I was like, you don’t understand, this is the Winchester Mystery house. It ships because it’s Wednesday, not because it’s done. And that is a tough part. I think there’s a big cultural mismatch around when is it time to ship, when is it done? And nothing is ever done. But it does feel like in the world there are a lot more things that are less done being shipped than maybe there once was because of the internet.

Allen Pike: That definitely seems true.

Brad Ellis: Absolutely. And so it sounds like, I mean did you ever do box software?

Allen Pike: Yeah, I worked for example on iWork when I was at Apple and it needed to go on a CD in a box and there was a date that we all knew if this commit was not made by this day, it wasn’t going in the box, it would be on the shelves in the Apple store.

Brad Ellis: Absolutely. And so sort of the barrier for like, well it just shipped that way, it’s got to be higher, the quality bar has got to be way higher because we cannot come back later and patch this. It’s so expensive.

Allen Pike: But it is also incredibly expensive to all the process that we had and the more waterfall … and of course nobody would call it waterfall because it’s known to be the bad way. But one of the waterfall style mentality around the cutoff dates and the way the QA worked and the way that things got implemented in that cycle was all driven by that it has to hit this bar on this day to be in a box. Which like you say, it resulted in higher quality on that day, but it also resulted in a whole bunch of trade offs, a whole bunch of things. Prices were paid in order to achieve that.

Brad Ellis: Absolutely. So there’s, it shipped this way, why did it ship this way? And then there’s the other part of that which is like, crap, it shipped this way and how are we going to fix it? Sort of like, how do you go around the other direction? And so I think the most popular phrase ever is like, oh, you shipped your org chart. You hear that all the time, right? And so it’s okay. It’s one thing to ship your org chart and then now it’s another thing to be like, okay, now that we have shipped our org chart, now what do we do about that? And it’s harder to put that genie back in the bottle.

Allen Pike: Oh yeah, yeah. I mean Microsoft was I think the first company that started to become infamous for its org chart being visible in its software. But for more complicated companies, that happens more and more. Do you have a sense of that, and maybe this is a little bit beyond, I’m not sure how involved you’ve been in organizational design, but for founders and leaders that people are leading product orgs and tech companies in general, how you design your org chart is super complicated, extremely important question. Do you have a sense … do you think of when those questions come up that you should be designing the org chart partially to work with the product consequences that it’ll have in mind? Or is it more design the org track that makes sense for running an effective organization and then make sure your product orgs can not let the shape of the org chart mean that okay, we have two tabs and the tabs are effectively this team and that team.

Brad Ellis: Well first off Allen, let me just tell you, no one knows what they’re doing. Nobody knows. Like nobody. I’ve talked to all them. I think you and I have been doing it longer for a lot of the people that are out here tasked with making that decision and they don’t know. What I have noticed that I think we don’t give enough respect to is that every problem space is different and then requires a different thing. So even though we’re all under this bucket of technology, I’m a technology company, it’s like if you are a healthcare company or you’re a FinTech company or you’re a game company or you are a ride share company, all those things are fundamentally different in how you must organize the company. And so it’s tough to just be like, well, a tech company must have a combined DevOps team and you must have this kind of design team. It’s not clear enough because there’s so many different problems. And the other big one that I’ve noticed people run into is how big is the problem space that you’re working on? You have a product company, I’ll use Apple as an example, only in that they have a bunch of different services to work on. So you have sticky notes app and the text edit app and pages and numbers and-

Allen Pike: The two most popular apps.

Brad Ellis: Right. I know, yeah. Rattling them off here. So you have all these different places to worry about that may require a different structure than a company that only has one app. And so I think my favorite example recently, and I recommend everyone go just take a peek at this, is the logged out Airbnb website. Which just has … they’ve redesigned it in the last year or two. It’s just very focused and it’s very clear and because it’s one product, it feels like one team made it. It has a clarity of thought that it is communicating about what the product is that feels like they didn’t ship their org chart or it feels like a team of 12 very skilled people made it.

Allen Pike: So just for people who don’t quickly pull it up. I’ve loaded it here and I see I’m in a product experience, it’s not a splash page where it’s like, click here for businesses, click here for hosts, but click here for whatever. And the stereotypical big … if you go to a really large company often, you see basically the org chart on a page and then you navigate to … they ask you to figure out what category of thing that you are. Are you a business under 50 employees or whatever? Instead, what this Airbnb logged out experience is, is a list of different categories of Airbnbs that you might want along on the top. And then for me, a grid of beautiful Airbnbs that are appealing and like a day’s trip away from where I am today. And it’s really compelling. It’s like I’ve gone into the product, I immediately understand what this thing is, rather than a splash page with cartoon people looking at me.

Brad Ellis: Exactly. And if you tap on the hamburger icon up to the right, look at how short that menu is.

Allen Pike: Oh man, that must have been a huge debate to make. There’s five items, login, sign up, host your home, hosting experience, help. And that’s it.

Brad Ellis: That’s it. That’s it.

Allen Pike: And there’s 40 more things, I’m sure that they could … it’s a big enough company, there’s so many other things someone’s like, well we need to have this or we should have this and can we have this in there?

Brad Ellis: That’s right. And this changes if you log in, if you’re a host, if you’re a guest. Once it knows more about you then more buttons start to come up. There’s ways to get deeper into the site, but I don’t know, are you shocked when you look at that like, oh my gosh, how did an organization of … I don’t know how big the company is now, 5,000 people, how were they able to across all those teams come to this clear of a thought about what they do and not ship their org chart. They didn’t let a thousand flowers bloom. It’s just so focused that it’s beautiful in this interesting way.

Allen Pike: Yeah, interesting that you mentioned … I mean I am very impressed and my instinct, which maybe it shows maybe some of my biases is that they have one or a small group of strongly respected and good at communicating product leaders that have driven this and have used some political capital in the company and made sure that happened. Which at the top, if not like the CEO level rather than what you tend to … the stereotype is you grow to a certain size that you end up having someone who’s not really in tuned to the product at the top layer or two and they’re more sort of MBA style, not … Of course there’s some very competent and successful product thinkers that have MBAs by someone whose primary way of looking at the world is the MBA style of, okay, well I have this org chart and I’m going to let the people in the org chart do the things that they do and I’m not going to go in and tell everybody, all right, this is the main core thing of the product and everyone needs to fall in line behind it. That’s my instinct. I don’t know if you have any-

Brad Ellis: No. You nailed it. And so the CEO of Airbnb went to the Rhode Island School of Design RISD. And so here he is going to come with a design expertise. Exactly to your point. And then I’ll compare that with, I worked for Target for a while and-

Allen Pike: So the CEO at Target, not a designer?

Brad Ellis: Not a designer. They are a Fortune five company or whatever. They’re real big up there. And they’re a large organization so their CEO operates more like a venture capitalist than he does that kind of thing. So we had a disagreement. So the org that I was working through laddered up through the chief product officer to the CEO and I had a disagreement with the marketing team and they laddered up through the CMO to different people, couldn’t come to an agreement because the CEO wasn’t going to be the judge to break that tie right in the middle. He’s just like-

Allen Pike: Because who were they to make that decision? They’re not the expert on that.

Brad Ellis: I’m just here to fund you guys. Yeah.

Allen Pike: Yeah.

Brad Ellis: I can stop funding you. Right. So it’s just a totally different way of looking at it. And the thing we were arguing about was at the time there was two different logins. So if you used one of the apps that the marketing team made, they had one login and if you used an app that the product team made target.com, they had a different login.

Allen Pike: I would be so mad.

Brad Ellis: It’s a very fundamental, obviously you shouldn’t have two different logins for Target properties, right? Obviously.

Allen Pike: Oh man, my bones hurt just even hearing the idea of having to try to convince someone that that was bad and should not be. Oh man.

Brad Ellis: Exactly. And so on the product side, we felt like that should be our job is to maintain your identity. On the marketing side, they’re like, yeah, but we have way more users and we’re getting users faster. But the reason why they had more users and they were getting users faster, is that they spend money. So they were spending whatever 30 … I don’t know what the number was, 30 bucks a pop on a head and we’re relying on organic growth. And so what is the number, what is it worth? How much did it cost us to get there? Whatever. Just some other people needed to make this decision. What ended up happening, what ended up breaking the tie was Travis Kalanick got kicked out of Uber and the CMO of Target went to Uber to replace him. And was promptly … he only lasted a few months in the job before the current CEO of Uber came back in. But in that sort of power vacuum, it was like, great, okay, now marketing, you don’t have this anymore. This one guy who was preventing it, that roadblock moved away. And so because of an org change, then the product changes as a result.

Allen Pike: Yeah. Which happened to have a good effect in that case, which is that, okay, now there’s this sanity and that if you’re logging into Target, you don’t have to know which org you’re logging into, the product org or the marketing org. But it could have gone the other way. If the folks championing on your side happened to change orgs, then maybe the marketing side would’ve won the day. And then however many years later there still would be two logins and there would be maybe a whole paragraph saying, if you have a login at targetmarketing.com or whatever, marketing.target.com, then click here.

Brad Ellis: Oh my gosh. Exactly. Exactly. So I do have a war story slightly, just an interesting one about shipping, it shipped that way. Which is there was a … at Lyft when I started there, someone who was a designer before me was like, Hey, I was working on this project, I updated how the cars look top down in the map view. I have new assets, he was a 3D designer, he’s like, I don’t know how to do this. So here’s the files, can you make them into assets? And so first, second week on the job, I made those into assets. They shipped in the app four and a half years later. And you’d think an asset swap, how hard could that be?

Allen Pike: Seems really easy. Hardly an inconvenience.

Brad Ellis: Right? But the first roadblock was, okay, I don’t want to build the assets that way. I’m like, okay. So I looked, give me exactly what the assets are, I’ll make them the exact same size, we’ll do an asset swap, it’s going to be great. Hit that up. And then the next problem we hit was that the assets in app were cached and there was no expiration on the cache. So if you had the app already, then it would just never change. And so then all of a sudden this little project that seemed like an asset swap, now all of a sudden it got sort of tied … and I didn’t care that much. It’s not like I was pushing to get these assets in.

Allen Pike: No, it sounds like you were working full time for four years.

Brad Ellis: No, I’m not working full time for four and a half years on these assets. So now all of a sudden this asset swap sort of Jira task or whatever sort of gets embedded inside this larger one, which is a caching issue.

Allen Pike: Right. Changed caching, which is famously easy problem for software engineers, caching and naming things.

Brad Ellis: A very easy… Exactly. And so then it gets put in a roadmap, but then that team gets reallocated to this and then it moves over here and then that team gets disbanded. And so this little task just sort of stayed in that Jira and then moved around for just an insane amount of time before it actually ended up happening. So it happened before I started there. I worked there for about four years and it didn’t ship until after I left, was the full span of that insanity for what should be an asset swap. And so it’s organizational … I mean, obviously there’s an easy way to change it, which is just to give it a new URL and then you don’t have to worry about that, whatever. There’s other ways around it, that weren’t taken. It didn’t matter that much, otherwise I would’ve made people do it. But it was interesting to me how hard is it to do a simple thing? And sometimes as a designer, some of the things that I want changed can be like, I need that background color changed, that status bar is the wrong gray. These are really minor changes. And in larger organizations the way that they want it to work is like, well, I file a Jira and then we go to sprint planning and then we advocate for our bug and then it doesn’t go above the line and then we do it again the next week and we keep sort of arguing and if we keep caring then we’ll keep arguing and then eventually it’ll make it above the line. And if you stop caring, well then it didn’t really matter. That’s sort of the thought. But it’s frustrating for me because I just want to change it and I feel like it should be easier. And I think my biggest frustration with where we are today with tools for iOS and Android development is that it’s too difficult for me to do it. Either it’s a company policy that I’m not allowed to have code editing access, which is true at a lot of places. Or it’s just that the tools are too hard to communicate, too hard to get into actual code. And it feels like there should be an Apple app and an android dev app that is designed for designers to make the app look better. And so I don’t have to file a bug because the color’s off by one hex value. I should just be able to change that when I see it. Or I was working on a project and we had written it in … its a website in React and there was a typo on it and it was like a four day change to fix the typo because it was a React app and we had to do a bunch of bullshit. And it’s like, it’s a website, we should just be able to change it so easily. And so I think it’s interesting how your dev stack and the requirements of that will sort inhibit you from even doing things easily is something that is interesting to me.

Allen Pike: Yeah, you hit on a couple of really interesting things. One is this sort of axiom, which you don’t hear discussed as much in smaller companies at least. But as companies grow, you start to hit on it, which is that the more people need to be involved and have sign off and have process in order to make an improvement, the fewer improvements you’re going to end up getting in terms of quantity. And so there’s a whole bunch of things you can do to try to improve that. And maybe you’ll touch … we’ve already touched on some of the organizational things that you can use to hinder and or maybe potentially help if you design them well. But in terms of the tooling, you mentioned the idea of Apple having an app that you can create those things and Apple does have tools in Xcode and things like that. If you do everything in the pure Apple way that they advise, you can go in and you can change a color value and it’ll get propagated across the whole app. But the challenge in large organizations, certainly at the scale of something like a Lyft or Airbnb or something like that, is that typically those apps both have existed since before Apple provided that tool. And they are in a large design system that has an entire team in charge of the design system that is in charge of specifying down the hex value that then gets ingested into some system that goes into somewhere that goes into somewhere because they want to have some coherence and consistency across their entire design system, which in theory would allow a change to happen and propagate through everything to change one hex value. But then when you’re at the paper cut level where you’re, Okay, I am feeling this tiny pain on this one screen, on this toolbar, and the problem is that this hex value isn’t correct, then those sort of design systems, which in theory allow change to be easier and faster can sometimes make it more difficult for an individual change to get implemented because then sometimes the Jira ticket turns into this big Katamari of a whole bunch of unrelated things. So I think that the tooling thing, you can’t just blame on Apple because they’ve done some to their part. But I think it’s something that there needs to be … or I’m curious about your thought on this, but it seems to me is something that should be an organizational priority for product orgs to be investing a certain percentage of their time into tooling that helps the people that are finding these small product improvements that are worth making to be able to make those with fewer organizational hurdles and fewer people that need to get involved and fewer people’s Jira tickets need to be … or fewer meetings need to happen in order to make improvements, assuming that they actually are in fact improvements.

Brad Ellis: A hundred percent. So here I am talking to an engineer, I have made sort of that my life’s work, I’m a designer, I’m not an engineer, but having a really, really good relationship with engineers, talking about every problem that’s coming up. If I get of a top down directive that I now have to communicate to the engineer and they’re like, that’s dumb. I try to make sure that I can explain it really well, that I listen to their feedback because I’m the messenger and they are having feedback about how dumb that feature is that they’re being asked to build and making sure that I keep that relationship really tight because the easiest way to change that status bar color is just to be like, Hey Allen, can you just change that real fast for me right now? Is, I mean far and away the best way to get anything done. The time that it takes you to do something may have just been like you would’ve been staring off into space anyways. I mean there is a lot of flex time.

Allen Pike: You’re waiting for your next meeting or whatever.

Brad Ellis: Exactly. There is flex time in the day. And so if you get excited about something like, Dude, let’s stay 30 minutes late today and let’s get a Lottie animation in so this thing does a cool animation. And if you can get the dev you’re working on excited about that, then it feels like that’s actually, I think the best way to make good product is to do that in a smaller way. Let the people above you be like, well, it’s only a 5% allocation toward bug fixes and dark mode things this month. You know what I mean? Like, that’s cool, that’s cool. You keep having fun talking about that. And then now that we’re down here, we’re going to make some great software.

Allen Pike: If you get excited about something as a great maximum. And I think that scales too, you’re talking about it on that one level of if you can get that good relationship with people that are your diads or your pairs to be actually implementing thing or on the other side designing the thing, then that’s super helpful. But if you can get excited about something as a group at any scale, that seems to be when the really great stuff happens.

Brad Ellis: Yes. Now I want to take a brief just to mention is the Mythical Man month. Do you know that parable?

Allen Pike: Oh yeah. Famous that adding more people can make it slower rather than making it faster.

Brad Ellis: Dude, totally. And so one thing when we were talking about Airbnb where I was like, look at this clarity of thought. That’s what I was saying, it looks so … everyone was on the same page when they were working on this. That’s how it feels. Part of the Mythical Man month is they broke out an equation, which is like, everyone has to talk to each other. And so the more people you add, the harder it is to have a shared understanding of what we’re doing here. And I think that is sort of the biggest problem that I’ve seen and I don’t know how to solve it and I’m not here to. I know that there’s some people who are like … that understand that problem and so because of that, they limit their team to 12 people or they limit their team to … right? You have that, how many people work for you?

Allen Pike: Yeah, we’re 16 right now, but we’re not working all 16 people all on the same product. When we’re doing, we’re often working and building out products where we maybe four people building that thing and every single person knows everything about the product and they all know each other. And there’s very little of this web of communication that you’re talking about across that product.

Brad Ellis: Absolutely. And a lot of it comes from a lack of organization. And I think there’s even a lack of desire to even organize in the … I call it the Bay Area process for product development, which is like, let’s just get some smart people and throw them in a room and they’ll figure it out. And that works to a certain extent, but if you have 5,000 quote unquote smart people in a room, they’re just going to come out with a different idea for which direction to row. So I think that’s just an interesting problem. I heard a fun one the other day, which was, A people hire B people and B people hire C people. But the thing they don’t mention is how many people they hire. They hire so many C people.

Allen Pike: It’s a lot easier to hire a whole bunch of people if you have a lower bar. I’d never really thought about that, but that … you’ve talked to really talented people, often one of the things they’ll complain about is that they interviewed so many people and they’re having trouble hiring their open recs to … they have headcount that they can fill, but they’re struggling to fill it. And then sometimes you talk to other people and they’re like, Yeah, I just hired 20 people this week and I don’t know, everyone seemed good to me.

Brad Ellis: The way you go. Yeah. I work with some people that only work with contractors and so their company is only two or three people, because then everyone else is at whatever, a team of six in Russia that are doing their development or whatever they’re using for the different parts of their labor. But the thing that I love, why I enjoy working for them sometimes is that because they sort of choose to work with contractors, they have to be so organized with what they’re doing and they really spend a lot of time being like, okay, we need to figure out what we think ahead of time. And then we hire people and then they execute on that instead of being like, yeah, can you guys just, I don’t know, make an app or something. It’s just a difficult thing to do. And so I feel like I’ve worked in a lot of orgs where we’ve sort of scaled so big that it’s difficult to keep everyone on the same page or nay impossible. I’m not sure. When I was at Square, the way that we tried to help that, and I think it was helpful was there was an all hands company meeting every Friday for two hours. I mean it was a lot of people, I got it down to an hour when I was there. But it’s, here’s everything that we shipped, here’s all these things that we’re thinking about. And there was a dedicated time for the CEO to talk every week, a dedicated time for the COO to talk every week about numbers and where the company is. Now here we can all be on the same page. And so that was of the intent of that meeting and I think that that was helpful for sure.

Allen Pike: We do that at 16, well, not two hours, we do half an hour, but every Friday give an update, here’s the interesting things. Give a bit of chance of team bonding, which obviously 5,000 people on a call doesn’t get team bonding, but having a heartbeat of communication and alignment. They famously say one of the most difficult things, if not the most difficult thing of running a large org is keeping everyone pulling in the same direction, not figuring out which direction to pull in, which is also hard. But even just getting everyone to pull in any given direction, they’re just more or less the same as one or the other.

Brad Ellis: Absolutely. And I hate to say the word politics of it, but the amount of people who are like, Yeah, that person’s telling you to do this, but they don’t know what they’re talking about. Listen to me and you should pull this direction. There’s just a lot of that and it’s natural and it’s difficult and I don’t know if there’s a way to solve that. I think it’s just you sort of get tired of it and then you decide to go work for a smaller company is how it-

Allen Pike: There’s ways to disincentivize it and there’s ways to incentivize it. I think that’s a little bit out of the scope of the show, but I think that to what degree companies and leaders work on disincentivizing or just avoiding incentivizing that kind of politics, also tends to correlate with good product outcomes in my observation obviously.

Brad Ellis: Yeah. The other thing is it feels like you can just sort of smell that a company’s org chart is to let a thousand flowers bloom. And I’m trying to think of a good example. I think maybe a good example is the Disneyland website. Where you’re like, okay, what do they need to do? I don’t know. Pop that one up, Allen.

Allen Pike: I got to bring it up here. Let’s see what we got.

Brad Ellis: Yeah, bring it up. Bring it up.

Allen Pike: I also … Okay, first before anything, the URL is disneyland.disney.go.com. They still haven’t given up on go.com.

Brad Ellis: There you go. Yeah. Right. Okay. We’re starting off with, there is a lack of clarity.

Allen Pike: There is a lot going on. I’ve got a giant video. One of the biggest buttons on the thing is play full video, learn more holidays. And then there’s a relatively way more complicated than the Airbnb control that did the same thing. Airbnb had a very nice compact control for saying, get started to find your trip. But the Disneyland one is much more complicated. And then a whole bunch of other things, places to stay, things to do, Magic Key, which I go to Disneyland from time to time and it’s great, but I don’t know what that means. And bunch of other stuff all around. A link to say visitdisney.com is the very top left thing because I’m going to go to Disneyland website in order to then go to the general Disney website. Talk about org chart.

Brad Ellis: Yes. So much more confusing things. And actually you mentioned the Magic Key thing where it’s like what are these words that we’re making our customers need to understand in order to use our product? And so at Airbnb it’s like, okay, it’s a listing or a house or a trip. The words are carefully thought through, but I think they’re actually a lot more easy to understand. I don’t know, everyone has their own words. So right now Disney Land, they’ve just gone into confusing town. So you mentioned the Magic Key. There’s actually four different … what the Magic Key is is a annual pass or it’s a membership.

Allen Pike: Oh I didn’t realize, if I hover on these things, the Parks & tickets, Places to Stay, Things to Do, they explode out giant like 2001 era dropdown menus with dozens of things in each menu.

Brad Ellis: Oh my gosh. It’s just so much to read. So of the Magic Keys then, which is the annual pass, then there’s four of them and they are called the Believe Key, the Enchant Key, the Imagine Key and the Inspire Key. Now what do those mean? I don’t know. Which one’s the best? And now you got to go read up and it’s like what’s the amount of stuff that you need to learn? And if you’re looking at this page, it’s like, oh my god, what is a Genie Plus pass and how does that affect my Lightning Lane, park hopper Magic ticket thing? There’s so much you need to grok.So once they introduced all these new terms, I hadn’t gone and it was close to the pandemic and I went and I was like, there’s so many new terms that I’m literally just going to today while I’m at this park, just let those all wash over me and try to understand what all the words are. And it sort of took me a day to be like, okay, well the Genie Plus gets you Lightning Lanes except for these four rides which require an additional fee. But you can only get two of those per park per day, one per ride. Trying to understand the way that the system works and it’s difficult. And I like that because that’s what I do for a living. But it’s too much to put on people.

Allen Pike: Yeah. I mean you can see how it evolved over time. Someone’s given a goal which is extract as much money for a guest as possible. And then when you are looking at the status quo, how do you do that without adding more moving parts?

Brad Ellis: Yes. I think one of the hardest things for everyone to deal with is we look at our product for, it’s where I work and I get my paycheck and I’m there for 40 hours a week and I’m staring at the screens. And so I think you can sort of trick yourself into thinking that everyone else is doing that too. And actually when you look at your usage patterns, how many times are people going to be using this in a month? Four times for a total of three minutes. Now given that time and that they have a task to accomplish, how much are they able to learn in that span? This sort of cuts both ways because on one hand you have things like an e-commerce website. So I get an ad from Instagram to buy some sunglasses. I’m only ever going to be on that website one time, so please don’t call your cart something weird because I’m only going to be here one time.

Allen Pike: It’s true. Add these glasses to your journey.

Brad Ellis: Exactly. And so for those things, I can’t learn anything. And there’s another side of it where it’s like, okay, it’s Microsoft Word. I’m going to be in here for the next 40 years. Then I do have the ability to learn things and maybe I don’t today know exactly track changes works, but I can learn how it works and that learning will be useful to me. And so it’s okay to learn and there’s sort just the spectrum in between, which is how much is it okay to teach my users? When is it the right time for them to learn about this? And maybe your app. So at Lyft, it’s hard to learn or Uber, those two things, it’s hard to learn anything because when you’re using the app, you need to use it now. It’s not-

Allen Pike: Yeah. You’re in a time pressured situation a hundred percent of the time, otherwise the app’s not open.

Brad Ellis: Exactly. And so please don’t make me teach things. And one of the rants that I go on all the time that I compare between is there’s a difference between a tool and an experience at these different ends and everyone’s sort of in between. But if you think about it on one side, a tool is like it’s a flashlight and it turns on. And so that’s what we’re making and we need some batteries and whatever, and we have a set of requirements to make this tool. On the other side of that you have the concept of illumination. This is what our product is about, is about illuminating a room, not about you need a flashlight. And so, okay, because that’s our company’s goal so we’re going to make floor lamps and table lamps and things that glow and diffusion lenses and different ways of dialing, whatever, because your mission is much bigger. And I think a lot of the VC, larger companies, et cetera, I think they push people toward that other end of it, which is solve a really big problem with your product.

Allen Pike: Yeah. You have to get our billion dollars return.

Brad Ellis: Exactly. And so that’s sort this tension that I’ve seen from people. People that are like, I just want to make a tool. I just want to go to airbnb.com and I want to click a listing and I just want to get a god damn house and another people who are trying to push you more toward the, it’s about an experience and just give me loose dates and let’s do a lot of reading. So there’s just a push and pull between those two different things. And I’ve seen a lot of people get into fights about that. Like, what are we here for? Is it just a tool? Just show them the buttons and let them figure it out? Or should it be a really guided wizard where you’re clicking one button per screen and it’s taking you down a tree?

Allen Pike: And that seems to bring us really perfectly I feel full circle to your original story at the beginning of the episode about being in front of users. Using something from the first time is often I feel, and tell me how you feel about this can be an antidote for that thinking that you can throw a hundred things at them. If you’re five steps removed from the people that have actually done any user research or actually seen people use the product, it’s easier to delude yourself into thinking that someone wants a 10 minute wizard. But if maybe that’s the antidote to some of that thinking is, okay, your punishment for proposing this extremely complicated org chart as a screen is that you need to do five user researching interviews and see people encounter this for the first time.

Brad Ellis: Yes. Or we’re going to go to some timeshare style thing and I need you to present to a room of 30 people how all of the Magic Key systems work.

Allen Pike: Yeah. And we’ve determined that they have an attention span of nine minutes for this, so you have nine minutes.

Brad Ellis: You have nine minutes, and then you’re not going to talk to them after it. You just present it, and then when they leave, I’m going to take a quiz, I’m going to see if they understood what you were talking about in that amount of time.

Allen Pike: And that’s your quarterly KPI.

Brad Ellis: That is how I wish. Yeah, because design stuff, I’m a low level … whatever. Design often gets pegged at this is low level, like what color is the button? But it happens all the way through the stack of what is the API that you’re designing, what comes back in that request? What is the service we’re designing? How complicated is it? How easy is it. There’s sort of all these different levels of it. And it feels like sometimes people are poorly designing at that higher level thinking that they’re not designers. And that’s the part that bugs me the most. And it’s been true forever. You read a book, they were written in the fifties and they’re complaining about the same things just with industrial design and making belts. These problems are sort of eternal, sadly.

Allen Pike: Yeah. Well if we’re lucky, then we’ll see examples like Airbnb where design thinking from the top leads to businesses succeeding. And then if it really does have the impact that both of us think that it does, the evolutionary pressure would lead to more success for those products. And the ones that just chip their chart into a giant basket of random junk on the homepage will have evolutionary pressure to stop doing that. And over time, hopefully as an industry, we will at least get somewhat better at trying to advocate for that user centric kind of way of thinking.

Brad Ellis: That’s the hope. Hopefully we can get there.

Allen Pike: Well our guest today has been Brad Ellis. Thank you so much for joining me and excited to see what you build next. We should have you back at some point because I feel like there’s a whole bunch of threads that we could pull on and dig into more.

Brad Ellis: 100%. Thanks so much, Allen. You have a great rest of your day.

Allen Pike: Yeah, you too.

Brad Ellis: I’ll talk to you later.

Allen Pike: It shipped that way is brought to you by Steamclock Software. If you’re a growing business, your customers need a really nice mobile app. Get in touch with Steamclock.

Read More