What's up, everybody? This is Cortland from
EndyHackers.com, and you're listening to the Endy Hackers podcast. On this show,
I talked to the founders of profitable internet businesses, and I tried 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 Whelan, welcome to the show. How's
it going? Hey, hey, Cortland. Hi, Cortland. 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 users, typical users of our software work in a municipal
transit agency. And the timeline that they're thinking in is either short range in the next
six months or one to five years out, trying to 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 all together, including the two of you here. It's pretty rare that I
talked to a company with four co-founders. 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. Well, 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 Gettleman 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 was 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
like a fixed income hedge fund within Citigroup. And that was the summer of 2007, which is when
the subprime mortgage collapse began. So I watched these things crumble and decided that was not
the path that I wanted to pursue anymore. And I went back to 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 Gettleman, one of our co-founders actually went to leave
that office. And in terms of scale, we work with about 275 cities and transit agencies across 10
countries around the world. 55, 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, you know, 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 others started to not have
four founders. And I think we use that to our advantage because we had four quite different
skill sets, some overlapping, but enough well roundedness to get the ball rolling and in a lot
of different ways. So Sam, 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 etc. And I started leading the more external side of
the house. So everything, sales, marketing, success, branding, that type of thing was under my
my purview. And then Dan and I work mostly on the engineering side. Sam also was engineering. Oh,
yeah, pretty heavily for the first, I don't know, six months or so the company. So you know, the
first version, he pretty much built the front end. That's true. 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 gonna be able to execute or they'll ask for help.
Yeah, I think one of the things that will 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
startups 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 you're 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're
going to work on what the product would look like? And what remix would ultimately become?
Well, we also realize not only being for 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 talking 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, to 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 fall of 2014. And
that's when we incorporated and figured out, you know, 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
collaborative process with the users rather than founders sitting in a room dreaming up this vision
that has sort of been a bubble.
Yeah, I'll chime in there was much less about how we decided 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 commit to buying your product
before you even really had a product?
Yeah, that was a funny process. So we were founder, I mean, we were fellows at Code for America.
And we have maybe a couple months left in our year long fellowship. And we had launched this
prototype, really, that was called transit mix, 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 off site with no reception
in Marin. 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 a 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 are 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.
You know, also a shout out to Matthew Barnes at Oregon Department of Transportation, who was sort
of, 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, you know, for his state
DOT, they're 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 made 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? I mean, 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.
And so that was the initial user in mind. And 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 players 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 can 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, you know, understand one way roads and contraflow
bus lanes and just like really complex street networks and easily layout route geometry for
you. And we'll also have like 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 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, you know, 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. Otherwise,
it was 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 like 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 build, link. And I think
that was the tweet that went viral. Yeah, that and then it got picked up by Gizmodo. Yeah, like
Gizmodo and City Lab. Yeah, City Lab was big. Wired picked it up. And it was all under the
title of designer fantasy transit network. Okay, 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 then 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,
was like, there really wasn't much to it. And it wasn't designed to have user accounts and orgs
and all these administrative things that you need to do if you're gonna actually ship a product.
And so we just started from scratch. And it wasn't much to throw away. But we had this,
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, like, why do you want these things? And then we just,
we just went from there, I think we probably built the first version, it was maybe two week,
two week turnaround or something, bare bones, but enough for it to be useful for our first customers.
I took some questions from people on the anti 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 named Brian Imperial Basso 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, you know, 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 money do you have? So this is like 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 his what he could he personally, you know, 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 can I have the authority to sign a contract up to x dollars, x plus $1,
I need to go to my boss to get sign off. 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, you know, 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 standardized pricing. That's the whole process
in itself. How are you guys thinking about financing this whole operation? Because,
of course, with four people, you're not really short staffed, but you also, you know, have a much
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 of contracts was definitely enough to feel
secure in jumping and in doing this. Yes. Code for America also made a significant investment
in us early on. Were you guys clear early on and 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, you know, very invested and 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,
okay, 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
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, you know, level of income that they can
have. And what that meant was that there was a pretty, 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, you know, those types of customers that have their, that run their
own shuttles or, you know, big tech companies run their own shuttles and they wanted to, you know,
plot out where all their employees lived and use remix to plan out their routes so they could
figure out how to make them more efficient. And we ended up with our vision and our strategy,
we ended up, you know, 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, you know, just putting aside.
And that's painful when you're new and top line revenue is this thing that you're constantly
thinking about and, you know, you're trying to grow fast. But ultimately, it's healthier long-term
to have that deep keel that keeps you pointed in, 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, it'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 were 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 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 skill sets 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. So 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 what the right decision was
so you had to guess? Or was it all smooth sailing and obvious what direction to go in?
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 on 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 from 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 turned. They said,
hey, it's 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 of 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, you don't understand the communities you're serving
as a planner. So we recovered from that.
That's awesome that you guys are able to recover. And I've heard the story a lot,
actually, of startups sort of punching above their weight class and trying to sell to customers
that 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 catch up 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're 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, a point where we could actually
serve their needs.
So startups move fast. I mean, 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 only
one selling the government, probably one of the first YC companies to sell the 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 ed tech 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. And we also, I think the way that we benefited 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 another geographies. The beauty of working with
government is that everyone's 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 we're willing to 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 have heard that is similar to selling to large
organizations. So just, you know, 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 a proposal, and we have to respond to it. So I would say that's
probably the most unique thing.
Are you like waiting for governments to put out a request for a 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 know, 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 tech process, like 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, you know, 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 like features.
That's like 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?
Like when you talk about TransLink, it sounds like they were just on top of it.
You know, they were making data-driven decisions. Is that the norm for governments?
Or do you find like 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 do limited staffing or something like that, they can sort of, 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 to that spectrum.
But there's, cities know that they need, they 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 in 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 fit for us. So the 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 Tacoma, 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 like 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 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
just honestly 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 to sort of Nordics,
UK, Spain, and Portugal, among others now. And so what that was like, 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 product solved. 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 like...
Yeah, a lot of these cultures.
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 that where the public,
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 government 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
when you're looking at demographics for where you want to plan, you just don't consider that
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. 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 of last year is helping
transit agencies take their vision from planning and turn it into implementation and operations.
And that is a pretty well-taught in 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 the 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, 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, some of it is just data challenges. You have sort of separate data sets
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. But you know, 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 have 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, you know, 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 for you?
And if so, how?
We've been talking a lot recently about vision as for co-founders, we even actually just had a
visioning session over dinner last Sunday. So very topical.
What prompted that?
Well, I think part of it is like, like, revisioning after we have multiple products.
Yeah. So it was very clear what we did when we had our first and even second product and 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.
Got it.
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 know, you can
be a pedestrian, you could be a cyclist, you could be a transit rider and feel like you belong and
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 the 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, probably needs like 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? I mean, is it obviously you're aiming for accuracy,
you're aiming for something that customers will understand? I mean, what are you guys
taking into account when you're trying to come up with a vision?
Yeah, 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 better so that people
better understand what where you're headed as a company and what 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 belief,
right? 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 for us to stand up for something where, you know,
you have to make sure that you're building cities for people and not for 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, you know, 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? You know, how long do you guys
see yourselves working at remakes? And on a personal note, like what drives you to keep
being founders? So I think for me, I've always wanted to live and work and breathe in this space
as the intersection, 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 it's a, this is particularly a vision that
has a chance of wrapping up anytime soon. But yeah, 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,
like 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 like, 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 it 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
I'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 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 understands what you're doing.
But I 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 one 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're solving a very small, focused problem first.
I think it's very easy for someone who is an outsider to a 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 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 about what you're up to at Remix
and also what's going on with both you guys and your personal lives?
Sure. Well, you can find us at remix.com.
Excited to say that. And we 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 slash 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.
Thanks, Berlin.
Thanks, Berlin.
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 ndhackers.com slash 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 ndhackers.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 found in 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.