When the founders of Remix released a side project that unexpectedly went viral, they put their heads together and decided to turn it into a startup. Co-founders Tiffany Chu and Danny Whalen share how they were able to build instantly popular software, the mistakes they made and lessons they learned selling it to the governments who needed it, and how they grew from 4 founders and no customers to a 55-person team serving 275 cities and transit agencies across the world.
What’s up, everybody? This is Courtland from IndieHackers.com and you’re listening to the Indie Hackers Podcast. On this show I talk to the founders of profitable internet businesses and I try to get a sense of what it’s like to be in their shoes and how they got to where they are today.
Today I am talking to the founders of Remix. Tiffany Chu and Danny Whalen, welcome to the show. How’s it going?
Hi, Courtland. Thanks for having us.
Thanks for coming on the show. So Remix is a transit route-planning startup. What exactly does that mean?
Good question. So we work with local governments – cities, counties, municipalities – and we help them take their planning ideas from vision through implementation. And we started in transit, and we’re recently expanding to other forms of transportation as well to help cities plan streets and infrastructure.
Yeah, the typical users of our software work in a municipal transit agency, and the timeline that they’re thinking in is either sort of short range in the next six months or one to five years out, trying to sort of plan the future of transit in their city.
And how long have you guys been doing this so far?
So we started the company back in 2014, and we were all fellows at Code for America, the nonprofit, at the time. And we’ve been going for about three and a half, almost four years.
So there are four of you altogether, including the two of you here. It’s pretty rare that I talk to a company with four cofounders. How did you all meet each other inside of Code for America, and why did you decide to start a transit company, which seems entirely unrelated to what Code for America does?
Well, it’s actually quite aligned. While we were all sitting together as fellows, literally near each other at a table at our desks, and we were actually working on a side project that led to the founding of Remix. And it was originally a way to help citizens of San Francisco suggest better routes to Muni as kind of a grassroots advocacy-type project. And it was fun for us because it had a lot of mapping components and new technologies. And I have an urban-planning background, so that was really exciting.
Yeah, so Code for America partners small groups, or their fellowship partnered small groups with city governments. So Tiffany and I worked with Charlotte, North Carolina; Dan Getelman worked with Long Beach, City of Long Beach; and then Sam was in Atlanta.
So Tiffany, you went to MIT. And I think you were one year behind me. Is that where you got your degree in urban planning?
Yeah, so I was studying architecture. That was my major. And I realized kind of halfway through school that I was interested in design beyond just buildings. And urban planning was always really fascinating to me because it was basically how cities form and how the different communities knit together, which is at a slightly more macro scale than architecture, so I tried to do both.
And what about you, Danny? What was your background like before you started Remix?
Before I started Remix, I was a software developer. I worked at a consultancy and a startup before that. Software was actually a career change for me. In undergrad I studied finance and wanted to work on Wall Street and be a trader and things like that. So yeah, I did a summer internship with a fixed-income hedge fund within Citi Group. And that was the summer of 2007, which was when the subprime mortgage collapse began.
So I just kind of watched these things crumble and decided that was not the path that I wanted to pursue anymore. And I went back to school to study computer engineering.
It’s funny that you stopped in finance because it was sort of this unstable situation where everything was crumbling and you wanted maybe a more stable career as a computer programmer. But here you are now doing a startup, which are well-known for imploding and not working out. But that’s not the case with Remix. You guys are doing well.
I’m not sure if you guys share revenue numbers or any other metrics, but just for some context, can you give listeners an idea of how well Remix is doing today?
Yeah, I can give some context. So we grew from four founders to about 55 people within the last three and a half years or so. And we actually just opened an office in Europe, which is in Amsterdam. And Dan Getelman, one of our cofounders, actually went to lead that office. And in terms of scale, we work with about 275 cities and transit agencies across 10 countries across the world.
Fifty-five; that’s a lot of people. And I think one of the interesting things about starting off with four founders is that you can kind of divvy up responsibilities much earlier than a one- or two-person company, where the founders in those situations really have to wear so many different hats.
How did you guys decide who was going to work on what early on when you first started Remix?
Yeah, we quickly realized that most other startups do not have four founders. And I think we used that to our advantage because we had four quite different skillsets, some overlapping, but enough well-roundedness to get the ball rolling in a lot of different ways.
So Sam Hashemi, who’s our CEO, he actually also comes from a design background and is very strong in product. And he was leading product and all the other things that come along with being a CEO and doing fundraising and et cetera.
And I started leading the more external side of the house, so everything – sales, marketing, success, branding. That type of thing was under my purview.
And then Dan and I work mostly on the engineering side. Sam also was engineering pretty heavily for the first, I don’t know, six months or so of the company. So the first version, he pretty much built the frontend.
And yeah, I think people put a lot of – or they expect that the more founders you have, the more opportunity for conflict there is. And that’s true to some extent. But we had already worked together for a year before we started the company, so we knew each other very well, we knew how to work together, so it was much lower risk.
But there still is unforeseen things, and so you just have to get really good at conflict resolution and you have to make compromises. And I think we’ve just been really good about that. You just build up a lot of trust, and so when one founder sort of takes on some responsibilities, you just trust that they’re going to be able to execute or they’ll ask for help.
Yeah, I think one of the things that would be challenging about having four founders is that from the get-go, you pretty much have the potential for a lot of disagreement. And early on in any startup’s life, even if it’s only just one person, it’s really difficult to make these big decisions about what you’re going to build or going to work on.
I imagine with four people, there’s bound to be some disagreement. So how did you guys sit down initially and decide what you were going to work on, what the product would look like, and what Remix would ultimately become?
Well, we also realized not only being four founders was unique, but having four very product-driven founders is really unique, because Sam and I are both designers, and then Danny and Dan are both engineers.
And we quickly realized that someone needed to talk to customers. And I have a UX design and research background, and I’m also, I guess, the extroverted person on the founding team. So if I were to talk to 10 customers a day, I would not be exhausted and I would want to talk to 10 more. So I naturally really fell into that role.
Yeah. On the topic of what to build, so we had users from the very beginning. We had basically the Oregon Department of Transportation committed to be our first partner in the fall of 2014, and that’s when we incorporated and figured out: What do we need to do to make this business happen?
And so having users from the beginning means that deciding what to build is more of a collaborate process with the users rather than founders sitting in a room dreaming up this vision that is sort of in a bubble.
Yeah, I’ll chime in there. It was much less about how we decide what to build, but how we prioritized all the requests we were already getting from our customers.
So what’s the story behind that? How did you get somebody to buying your product before you even really had a product?
Yeah, that was a funny process. So we were fellows at Code for America, and we had maybe a couple months left in our year-long fellowship. And we had launched this prototype really that was called Transitmix back then. And I think in June of 2014 when we launched the prototype, it somehow went viral and all of these planners around the world saw either press articles or tweets or something about our product. And they immediately started playing with it, using it.
And I think we were coming back from an offsite with no reception in Marin (ph). All of a sudden, we all looked at our phones and we had 250 emails from different planners around the world who had seen our product and wanted to use it and had, basically, 10 paragraphs of features that they wanted to see in it as a next step.
That was the moment, that was the day when we realized something was happening here. And we wanted to figure out why everyone was reaching out and why it went viral, because we didn’t really know. So then what we did was we started doing a round of user research, basically, calling up every single planner, transportation expert in our network, to say, “Hey, what do you think of this, and why is this helpful, and where do you see it going?”
And those conversations actually led to our first few customers. And we basically said, “Hey, we want to work on this full time after our fellowship. And in order for us to do that, we need some dollars. And would you be willing to help us co-create the product with you?”
Danny, how were you feeling when your phones are blowing up and you saw that there’s this huge reaction to this thing that you guys had built?
It was definitely overwhelming. There was just clearly a gap in tooling for transit agencies in this early stage of sort of envisioning what ways to solve specific problems. Also a shout-out to Matthew Barnes at Oregon Department of Transportation. He gave us that initial shot. And it was because he just understood the need for something like this that allowed – for him it was interagency collaboration, because for his state, the DOT there trying to coordinate efforts across agencies. And he sort of saw the potential.
So it was overwhelming and in a good way. And so we just mad the most of it and learned as much as we could. And transit planners are amazing people and they’ll tell you everything they know and all their dreams, and so we just listened.
So this whole story is fascinating to me, because I know a lot of companies that have expert product designers and they do a ton of analysis and they talk to customers. And they sort of intend from the get-go to build something that customers are going to need and use and pay for. And things sometimes still don’t work out.
And yet you guys sort of accidentally, it sounds like, built something that everybody was interested in, so how did you do that? What kind of research did you put into the product, how long did it take you to build it, and why was it that everybody liked it so much?
So initially, we built the product for people like us, who wanted to be more involved in their community and had some opinion on how their city should be planned. So that was the initial user in mind. We literally built something that we thought was fun and was pushing the boundaries of geospatial mapping world for a little bit.
And honestly, I think it was the stars aligned and we hit upon something that was solving a bigger problem that we didn’t quite know existed. And when that trigger happened, we realized it kind of in a little bit of disbelief. And it was only after we did that initial round of user research of understanding how transportation planners approach their job and what projects they work on and what their workflow is like – that was the point when we realized what product/market fit meant, and then strove to basically take advantage of that momentum.
Yeah, so let’s talk about product/market fit here for a second and zoom in on the product. What could people use this early prototype of Remix to do, and how did it work exactly?
The sort of magic moment when you first get to Remix is sketching out a new route from a blank slate. And you have this map of your city in your browser, and with your mouse you just click from point to point. And we’ll find the route along the street and sort of draw that in for you.
Then you can continue drawing and it’ll understand one-way roads and contra-flow bus lanes and just really complex street networks, and easily lay out a route geometry for you. And we’ll also have – sort of automatically link all of your stop infrastructure to the route as you draw.
And so you can go from this blank slate to the structure of a brand-new route in a minute. And that really wasn’t possible before. It was just incredibly tedious to draw out on a map what a route would even look like. And so that was what caught people’s attention at the beginning.
And of course, once you really start getting into the domain, you realize that’s scratching the surface of what a transit planner does. But it was just so painful previously that the world of scenarios that they would explore was much smaller.
So another thing I think is interesting is that even if you build a really great product for a specific group of people, it doesn’t mean it’s easy to get in front of them. Did you guys ever find out how exactly your app went viral among transit planners?
Honestly, I think it was because we were presenting a mid-fellowship update at Code for America about it. And then Code for America tweeted and was like, “Look at this cool thing that the fellows built. Link.” And I think that was the tweet that went viral.
Yeah. That and then it got picked up by Gizmodo.
Yeah, Gizmodo and CityLab and Streetsblog.
Yeah. Oh, CityLab was big, yeah.
Wired picked it up, and it was all under the title of “Design Your Fantasy Transit Network in Your City.”
So it’s kind of like a game and the press is writing about it because it’s actually fun to manipulate these streets and build your own routes.
Tiffany, you go off to start doing customer research and actually talking to people to better understand their problems and how you can solve them. What did everybody else do?
Well, we started building. So we had an initial prototype that we built that was pretty small. There really wasn’t much to it. And it wasn’t designed to have user accounts and orgs (ph) and all these administrative thing that you needed to do if you’re going to actually ship a product.
And so we just started from scratch. And it wasn’t much to throw away, but we had this core idea and this vision. And so it was sort of the four of us working together figuring out what we needed to do. And so we just made a really clear timeline for ODOT of what they wanted, when they wanted it, and then of course, why do you want these things. And then we just went from there.
I think we probably built the first version – it was maybe two-week turnaround or something. It was barebones, but enough for it to be useful for our first customers.
I took some questions from people on the Indie Hackers website. And pretty much everybody wanted to know the same thing, which is what it’s like to have governments as your customers.
This question comes from someone Brian Imperial Bosso (ph), awesome name. He asks, “When you’re first starting to sell to governments early on, what obstacles do you face that you might not face when selling to private companies, and how did you overcome those obstacles?”
So was there anything particularly that was difficult dealing with the Oregon Department of Transportation?
Well, the first thing that we got asked was, “How much is it?” And we looked at each other. We were like, “We don’t know.” And Matthew, who really believed in us from day one – he was like, “Well, I need a price if I’m going to buy it.” And so we asked him, “Well, what do you think it costs or how much (distortion) have?”
So it was a funny back and forth. And he clearly was taking a huge risk on us, and we were definitely showing it. And he basically told us what he could personally, under his departmental budget, he could afford. And we said, “That sounds good, okay.”
And that was our first deal, which taught us a couple things. Number one, I think when somebody in local government believes in you, that’s incredible and you got to jump on it and kind of work with their constraints to be able to just get your foot in the door.
Yeah. The sort of procurement thresholds within government are a major factor, especially when you’re starting. So those procurement thresholds basically specify: “As department head, I have the authority to sign a contract up to x dollars, x plus $1 I need to go to my boss to get signoff.” And so a lot of that initial year of contracting was just like, “Where are your thresholds, how many people do you need to get to sign off on this,” and working with them to find a price.
But of course, it means your prices are everywhere. So you then need to sort of clean that up later and standardize pricing. And that’s a whole process in itself.
How were you guys thinking about financing this whole operation? Because of course, with four people you’re not really short staffed, but you also have much higher funding requirements. Was this first contract enough to pay you guys a salary so you guys could quit?
So we were pretty lucky in that right after our fellowship, we also got accepted into Y Combinator. And so that plus our initial couple contracts was definitely enough to feel secure in jumping and doing this.
Yes. Code for America also made a significant investment in us early on.
Were you guys clear early on in what your vision and what your goals were going to be for this company? Because I can imagine some of you want to do this to try to expand as fast as you possibly can and get as many customers and make as much money as possible, and some of you might be very invested in simply making transit better, and a whole range of different goals in between.
So how did you guys decide, or did you ever at some point sit down and decide, “Why are we doing this and what do we want the outcome to be in the long run?”
For sure. And what we landed on was – and this was probably part of our philosophy very early on as well, is we wanted to focus on local government because we think local government is the only organization, the only type of organization that has to serve everybody. They don’t get to choose who they serve. They can’t just serve the rich people, they can’t just serve the specific people in this neighborhood or that neighborhood or that level of income that they can have.
And what that meant was that there was a pretty clear signal for all the founders that we wanted to focus on social impact in this way. And that could only be achieved by working with the public sector.
So in terms of vision, we actually had to say no to quite a few potential customers early on, especially those types of customers that run their own shuttles or big tech companies who run their own shuttle and they wanted to plot out where all employees lived and use Remix to plan out their route so they could figure out how to make them more efficient. With our vision and our strategy, we ended up graciously saying no to a couple of those companies because it wasn’t aligning with our mission.
Anything that could potentially have distracted us from making better software for government, we were pretty strict about just putting aside. And that’s painful when you’re new and topline revenue is this thing that you’re constantly thinking about and you’re trying to grow fast. But ultimately, it’s healthier long term to have that deep keel that keeps you pointed in the direction that you set out in.
I’m curious about how you guys became the types of people who are able to make decisions like this. Because like you said, that’s a painful decision to make. And I think the intuitive decision is to say yes to Facebook and Amazon and Google and whoever’s willing to pay you to help design their shuttle routes. But obviously, that’s not what you guys did.
How did you guys know that the right thing to do was to have a specific vision and a specific focus? Was it because you guys sat down and reasoned it out, or were you guys reading books on how to start a startup, or the mentors at Y Combinator giving you this advice?
I think what we realized in hindsight was that the four of us – we had already self-selected into this certain kind of mindset because we all quit our other jobs a year earlier to pursue a one-year fellowship at a nonprofit on nonprofit salary.
And so that all meant to all of us that we had a certain level of mission internally that was aligned. And I think Code for America does an amazing job of convening that type of community; people who believe that local government matters and people who believe that delivering public services and social services really matters, and that there’s so many different skillsets that can be contributing to that cause and that mission. And because we had lived and breathed that for a whole year, it was already a part of us.
Yeah. The four of us were very aligned in terms of value from the beginning. And so we knew the direction we wanted to head. I’ll also say that Y Combinator really does do a good job of teaching you how to focus and putting an emphasis on saying no. You’ll get constantly people reaching out wanting to chat or wanting to partner or wanting you to build something for them. And saying no is an important part of staying focused and moving forward as a company. So we tried to get really good at that.
Were there any decisions early on that you guys might have disagreed on among your team, or maybe you guys collectively just weren’t sure the right decision was so you kind of had to guess, or was it all sort of smooth sailing and obvious what direction to go on?
Definitely not smooth sailing. So one of our major mistakes in the beginning, which I still sometimes have nightmares about, is super early on, we signed a customer that was international and really big and really sophisticated and pushed us way farther than we could deliver in our product at the time.
I’ll mention it by name. It’s actually TransLink up in Vancouver who, when I went up to visit them, I was just so enamored with their team and how advanced they were at planning. And I already knew that I wanted Remix to work with them without really considering all of the product implications that working with an international customer with international data and a team of 30 planners who were all super, super savvy. And just did a poor job of matchmaking in terms of type of customer, scale of customer, and where we were as a company and as a product.
So I just remember calling Danny on a Saturday afternoon in the rain. I think I was walking through Golden Gate Park and I had just gotten another angry email from one of our customers up there, and freaking out because we knew we couldn’t deliver it in the timeframe that they had expected. And I think it was nine months later, they churned. They said, “Hey, not working for us.” And we were devastated.
So the story has a happy ending in that, I think it was two and a half years later, we got our shit together and was able to figure out the right infrastructure in the product to be able to handle cities at that scale, transit networks of that complexity, and also made significant headway on being able to import international data, like demographics for Canada and other countries, which is crucial. If you don’t have demographics, then you don’t understand the communities you’re serving as planner. So we recovered from that.
That’s awesome that you guys were able to recover. And I’ve heard this story a lot, actually, of startups sort of punching above their weight class and trying to sell to customers who they’re not quite ready to serve yet. And often it ends pretty disastrously because it’s a big confidence hit when a customer like that churns.
Could you guys elaborate a little bit more about the reasons why you weren’t able to serve TransLink, and maybe share a few words as to how listeners can avoid ending up in the same situation with their companies.
In the case of TransLink, they’re just a very advanced transit agency. And that’s anywhere in the world, they’re extremely advanced. So they have tons of internal tooling and they have a lot of data that they don’t make decisions unless they can prove it’s a good decision with data.
So for us, we needed to play catchup in being able to get to be useful in their decision-making process rather than just sort of solving one particular pain point for them. And so we just didn’t have the feature set and the workflows to become a part of that decision-making process at the time. And that’s mainly just the maturity of the product. We were sort of solving things at the engineering throughput – we just didn’t have the engineering throughput to really move that fast. And we were also learning and their needs were a little bit different than the needs of many of our customers.
So yeah, it took us a while (distortion) a point where we could actually serve their needs.
So startups move fast. You guys are constantly iterating and improving. Any startup is breaking things and launching things, whereas government is notoriously slow and bureaucratic. Do you guys find that having governments as customers has slowed you down or made you more conservative or responsible compared to how a typical startup might be, or has it been pretty similar to the other companies in your Y Combinator batch?
I think we’re pretty different from the other YC companies in our batch. We were the, I think, one of the only ones selling to government; probably one of the first YC companies to sell to government, so there wasn’t a whole portfolio or history of other founders who had done it in a big way before.
So I think what we learned was that we learned to look at other analogous companies that were doing similar-ish things, not exactly the same. But we talked to a lot of founders at edtech companies. So I think education is a pretty similar space to government. There’s a lot of risk aversion, you need to serve a very diverse community of customers, and also moving a little bit slower than the private sector.
I think the way that we benefitted from working with governments was because a lot of cities and municipalities all have planning as a core element – and there are planners who have similar jobs but just in other geographies – the beauty of working with government is that everyone is super willing to share best practices and learnings and like, “Hey, we do this in San Francisco. How do you do it in Pittsburgh, how do you do it in Toronto and Sydney, Australia?” And having a community of customers who are willing and vocal about sharing their learnings from their urban context with each other is something that no other industry has.
Yeah. I think that’s a great summary. I would say that it hasn’t slowed us down, and a lot of that is because governments are more collaborative. They want to include stakeholders in the process, and so they considered us a stakeholder, they considered adjacent agencies, nearby agencies part of this process and were willing to sort of take time to advise us in their problems, where other private enterprise-type customer relationships might not be that open and sharing. So I think in that sense, it helped quite a bit.
One thing that people are very curious about is: What does the process look like of actually getting in the door and selling to government? Is it similar to doing B2B enterprise sales, do you guys have a sales team, or have you had a lot of inbound interest?
So I would say I haven’t really had experience selling other things to other places, so I don’t entirely know. But I’ve heard that it’s similar to selling to large organizations, so just similar to enterprise sales.
The thing that I think makes it a little bit different is the number of RFPs that you might encounter. So obviously, governments have to be responsible public stewards of public money. And so sometimes they have to put out a request for proposal and we have to respond to it. So I would say that’s probably the most unique thing.
Are you waiting for governments to put out a request for proposal, or do you go and convince them to do that?
I think it really depends on what projects are coming up for different cities and agencies. So for example, you hear word on the street, “Xyz city is about to do a big system redesign.” And you hear about it and there’s probably going to be a proposal that comes out for it. So you wait for it and you look out for it.
I’ll also add that, in addition to the RFP-type process – before an RFP comes out, you want them to already know who you are so they have an idea of what the landscape is so they know what they can ask for.
I think oftentimes it’s really hard for governments to just know what kind of technology is out there. So a lot of the ones that are forward-thinking and kind of more progressive and on top of it, if they know what’s out there and have done their research in a holistic way, then they do a much better job of really specifying in the procurement process what they’re looking for; but not features. That’s the worst kind of RFP, if you write an RFP for features. You want to write an RFP for outcomes.
And how do you identify which governments are advanced and forward-thinking? When you talk about TransLink, it sounds like they were just on top of it. They were making data-driven decisions. Is that the norm for governments, or do you find a huge range of readiness and knowledge across different governments?
There’s definitely a range. But most of the time, when an agency is stretched thin, either just limited staffing or something like that, you just get sort of buried in problems. And so the problems that bubble up to the top are the problems that are happening today with buses on the road today. And so these sort of longer-term planning concerns end up getting set aside, and so that’s a contributor that spectrum. But cities know what they want to do, and they want to have access to this data and time to analyze it and support from the mayor’s office to actually execute on it. But it just doesn’t always happen that way.
I would say a really good-fit customer for us is a city that’s growing, because what happens when a city grows either economically or population-wise or density-wise is that they need to serve different needs, and those needs are changing. And in order to adapt quickly, you need to plan for it, and you need to have a faster planning process to be able to accommodate that change and that growth. So any type of changing landscape in a city makes the city a good fit for us.
You guys have learned a lot about selling to governments. For example, what you just mentioned about fast-growing city governments being better customers for Remix than slow-growing or stagnant city governments is a pretty interesting insight.
When exactly did you learn this? And what is the timeline of sort of the major learnings that you’ve had at Remix that have influenced how you’ve built and sold your product?
Maybe one way to think about it is that there’s a spectrum of how much we as a company learn from a particular agency, and that contributes to them being a good for us. So agencies that are growing and constantly changing and have to be nimble, they’re the ones that are sort of pushing us and finding areas where we can’t quite express this thing that they want to do. And so we just end up working really closely with them because of how engaged they are in the process.
Yeah. So as someone who is more customer-facing at the beginning, I can distinctly remember the couple of cities that reached out to us first, like Pierce Transit in Tacoma, Washington; VIA Transit in San Antonio; AC Transit in Oakland; VTA in Santa Clara County.
Those were all cities that had a very forward-thinking, progressive planning department within their transit agency. And they were embracing of approaching old problems in new ways, because their communities were changing really fast and they realized they needed to also plan faster.
And then we realized that as we started to grow and we started reaching out to new agencies – so we had a crazy wave of inbound very early on. But of course, inbounds like that don’t last forever, so we had to balance it out with other techniques. And so when we started going to transit events and conferences and doing outreach, what we noticed was the ones that were not as embracing of our product or who didn’t see the magic right away were the ones who just didn’t plan that often or whose planning projects were so few and far between that it just (inaudible) didn’t make sense for them to invest in a planning platform like ours.
I was also thinking – so we have a team in Europe now and they’re selling sort of Nordics, UK, Spain, and Portugal, I guess among others now. And so that has been a tremendous learning experience over the past nine months or I guess a year now. It’s even simple things like how you frame the problems that your products solve. You have to change the language.
And sometimes the things that they care about or the structure of the stakeholders that sort of form the delivery arm of transit, so it might be a private operator or something like that – those structures are different and it changes who the purchaser is or is there a consultancy involved.
So a lot of times, the learning happens in new markets where we need to shape our process to the structure of the prospects that we’re going after.
Yeah, the culture. It’s actually culturally driven.
Yeah, a lot of it is culture, yeah.
Do you guys ever just say, “No, this is not a customer that we want, it’s too much change”?
Yes. So there are a number of cities across the world where the local government arm is not the one operating transit. It’s a private company or something else. And what we notice is that the needs of the customer are drastically different, in that if you’re not a local governments running the social or the public service of the public transportation, you have different incentives, and you don’t always want to run the transit route to the low-income neighborhood because that’s not very profitable. And so when you’re looking at demographics for where you want to plan, you just don’t consider that part of the population when you’re planning.
And so that’s a very different agenda than what our product promotes. And so we’ve had some mismatches there in terms of product/customer fit that we’ve had to negotiate.
And what about competition? Early on you mentioned that your very first customer asked you, “How much do you want to charge for this?” And you guys didn’t know. And I think for a lot of other companies, you can kind of feel out what a reasonable price is because you usually have competitors who sort of set the limits on how much you can charge.
Do you guys have competition? Do you guys make decisions based on alternatives that these cities are using? Or are you guys sort of the only option doing what you’re doing?
So with competition it’s been interesting, because our first product came out and we basically created a new category. So we had the luxury of being able to name it and price it and position it, and that was an amazing experience. And then when we started expanding our product suite, we noticed that there were a lot of pain points in areas that actually had competition.
So our second product, Remix Scheduling, which we launched in December last year, is helping transit agencies take their vision from planning and turn it into implementation and operations. And that is a pretty well-trodden territory. But there were clearly enough pain points because we heard it from our customers that this was an area that they wanted us to solve.
We literally heard this. Customers would tell us, “What is the next product we should build,” and they said it was scheduling. And that’s an area that we do have competition, so we’ve had to learn a lot about dealing with that for the first time.
And why even create a second product? Why not just take Remix Planning and try to grow that as much as possible? Do you feel you may have been hitting a point of diminishing returns, or is there another good reason to have multiple products?
So our plan has always been to have multiple products. And a big part of that is collaboration between departments is just incredibly important in government, and there are a lot of barriers to being able to do that.
For instance, a large barrier for collaboration between departments – let’s say, for instance, you’re the department that plans and maintains streets or plans the structure of streets and the transit agency. They need to work together because they can make changes that are mutually beneficial.
A good example is in San Francisco, there’s the bus-only lane down Mission Street now. If you rode a bus that went down Mission Street before and after that change, you know that you are getting to work much faster than you were without that bus-only lane. And so that required collaboration between these departments.
Part of the difficulty of that collaboration is (inaudible) is just data challenges. You have sort of separate datasets and you produce data in different formats because you have sort of fragmented tooling within the different departments. But if you have a unified platform where you can work in a domain and then share across that domain with different departments and work together, it makes a huge difference. So I think that’s a core thing that we’re trying to accomplish.
Yeah. I’ll just chime in and say our vision has always been one of really large impact, and transit does not exist in isolation. And so if we were to only stick with one product, we would only make a small amount of impact – impact, but small, restricted to one very specific vertical. And we see a ton of potential and opportunity in expanding to other parts of local government that has similar problems.
Speaking of vision, I think this is one of my favorite things to talk about because a lot of founders, quite frankly, don’t understand, like, “Why have a vision? Doesn’t that constrain what you can do, doesn’t that mean that you’re going to pass up opportunities that might be better for you?”
And I’m curious what you guys think since you started in a place with such a strong vision at the outset. Has that been advantageous to you? And if so, how?
We’ve been talking a lot recently about vision as four cofounders. We even just had a visioning session over dinner last Sunday, so very topical.
What prompted that?
Well, I think part of it is revisioning after we have multiple products.
Yeah. So it was very clear what we did when we had our first and even second product. But now that we’ve expanded to help cities redesign streets, that is a whole other dimension to what we had been calling ourselves for the last three years. And so we needed to articulate what we were trying to do and in a way that was encompassing the culture of the company that we had built as well.
So in terms of vision, we’ve always rallied around this idea of we want to help build more livable cities. And obviously, there’s many ways to do that, so we’re trying to figure out how we want to articulate that specifically right now. And I think everyone at Remix really believes in that mission: livable cities, a place that has connectivity through really strong public transportation, one where you can feel like you belong on the street, you can be a pedestrian, you can be a cyclist, you could be a transit rider and feel like you’re belonging, you’re not subservient to the automobile, and one that’s inclusive, one that allows opportunity to become a thing that is possible within living in a city.
So obviously, a little rough around the edges, but that’s the general direction of the North Star that we’re heading. And it’s gone through a couple of iterations so far. It probably needs 30 more iterations, but it’s definitely been a journey for us to even start to articulate that and bring it to life within our company.
What are some of the things that go into deciding whether or not a particular articulation of your vision is what you want? Obviously, you’re aiming for accuracy, you’re aiming for something that customers will understand. What are you guys taking into account when you’re trying to come up with a vision?
The audience matters, of course. I think part of it is being able to articulate the values of sort of a smaller group of people to that larger group of people and so that people better understand where you’re headed as a company and what you hope to accomplish and how that aligns with the things that they care about.
I would say also we are aiming for a little bit of controversy, because if you set a vision and everyone agrees with it, you’re not actually saying anything. You’re saying the most common denominator of beliefs.
Not the point of setting a vision. So I think especially in this age, where I feel like half of Silicon Valley believes that autonomous vehicles are going to save cities, I think it means a lot of us to stand up for something where you have to make sure that you’re building cities for people and not just for robots.
That makes so much sense. And I think probably the reason why people are so suspicious of visions is that so many companies have this kind of ho-hum, drab, general vision that nobody would disagree with because it’s not actually taking a stand on something.
Is there ever a point where your vision is done? How long do you guys see yourselves working at Remix? And on a personal note, what drives you to keep being founders?
So I think for me, I’ve always wanted to live and work and breathe in a space that’s the Venn diagram of three things: design, cities, and technology. So however you slice and dice it, I want to do all three things at the same time. And as long as Remix is doing that for me, I’m going to be here.
I don’t think this is particularly a vision that has a chance of wrapping up anytime soon. But what keeps me here personally is I’m very interested in fundamental and structural ways to improve how government departments are able to work together and to deliver outcomes. In particular, there are some very large needs around data management and data analysis and just being able to better understand the city with this tooling.
And so I think there’s just a lot there. And while we have built sort of domain-specific tools, there are these cross-functional concerns that we’re sort of uncovering that really need some deep thought behind them and just a lot of design work to be able to solve properly. And so that’s probably one of the most interesting things about our company right now.
And then the other thing that keeps me here is it’s amazing to work with our customers. The relationship we have with our customers, because it’s this very close enterprise-type of relationship is really rewarding. They’re public servants. They appreciate that we care, not just that we sell software to them. And that means a lot to us.
Those are both such great answers. And it’s funny, Tiffany, that you mentioned caring so much about design, because I was browsing your website and the first thing that struck me was this design is so gorgeous. And then I looked at the tool and I was like, “These tools are gorgeous. I want to use this tool.” And I was like, “Who’s responsible for this?” Because you wouldn’t think that a startup selling software to governments would really care that much about design, so it really shows that you guys care.
And to what you said, Danny, I think you’ve heard a lot of founders talk about selling to large customers or enterprise customers, and how you end up having these personal relationships, where your customers are rooting for you as much as you’re rooting for them. And it’s a little bit counterintuitive because most people think that if you start a consumer startup, that’s sort of the end-all be-all of having a great time talking to your customers and everybody understand what you’re doing.
But I’ve found that in reality, developing these really close relationships with a small number of customers makes founders happier, so that’s pretty cool to hear.
I’ll let you guys get out of here. I’ve got more question for each of you: What would be your advice after working on Remix for a brand-new founder who’s considering starting a startup that sells to government?
I would advise them to make sure they’ve solving a very small, focused problem first. I think it’s very easy for someone who’s an outsider to local government to think that they can solve things that have been problems for years in kind of a really non-humble way. And yeah, I would just make sure that you’re solving a clear problem instead of projecting a solution onto something that people have been probably thinking about for centuries.
I would encourage them to consider working for a local government. I think that would be an interesting learning experience, if you wanted to go and sort of discover a set of problems that way.
And the other advice I would have is just to talk to as many people working in government as you can. There is absolutely no shortage of problems where part of the solution is software in government. But keep in mind that in order to solve problems for government with software, you need to also help them solve the people side of it as well. These are large organizations and you just need to have a holistic approach to working with them.
Those are both great answers. Thanks so much to both of you for coming on the show. Can you let listeners know where they can go to find out more to find out more about what you’re up to at Remix and also what’s going on with both of you guys in your persona lives?
Sure. Well, you can find us at Remix.com (inaudible). And if you want to learn more about our newest product, which is around helping cities design better streets for cyclists and for people who walk and people who ride transit and everybody in between, you can go to Remix.com/streets.
And also check out our jobs page. We have a number of roles up there that might be of interest.
All right. Thanks, guys.
If you enjoyed listening to this conversation and you want a really easy way to support the podcast, why don’t you head over to iTunes and leave us a quick rating or even a review? If you’re looking for an easy way to get there, just go to IndieHackers.com/review and that should open up iTunes on your computer. I read pretty much all the reviews that you guys leave over there, and it really helps other people to discover the show, so your support is very much appreciated.
In addition, if you are running your own internet business or if that’s something you hope to do someday, you should join me and a whole bunch of other founders on the IndieHackers.com website. It’s a great place to get feedback on pretty much any problem or question that you might have while running your business.
If you listen to the show, you know that I am a huge proponent of getting help from other founders rather than trying to build your business all by yourself. So you’ll see me on the forum for sure as well as more than a handful of some of the guests that I’ve had on the podcast.
If you’re looking for inspiration, we’ve also got a huge directory full of hundreds of products built by other Indie Hackers, every one of which includes revenue numbers and some of the behind-the-scenes strategies for how they grew their products from nothing.
As always, thanks so much for listening and I’ll see you next time.
Did you know the Indie Hackers podcast has a newsletter?
Sign up to get insights, takeaways, and exclusive content from each new episosde, directly from the host, Courtland Allen.