- Jared Friedman introduces a panel of successful tactical founders in the technology industry.
- The event was originally called CTO Advice but was changed to Tactical Founder Advice.
- The panel received over 150 questions from the Startup School forum.
- Ralph Goody, CTO of Plain Grid, discusses their software for the construction industry and their technology stack.
- Calvin Frenchoen, CTO of Segment, explains their single API for customer data and their tech stack.
- Diana Hu, founder and former CTO of Azure Reality, discusses their augmented reality backend technology and tech stack.
- Lillian, COO of SecondMeasure, explains their analysis of credit card data and their technical organization.
- The panel discusses the challenges and process of building their V1 products.

- The speaker discusses their experience with building prototypes and finding product-market fit.
- They initially focused on creating a prototype that achieved something technically impossible, which impressed their early customers.
- They then pivoted to building a classroom lecture tool, but it failed to gain traction.
- They switched again to creating a tool similar to Mixpanel or Amplitude, but struggled to find users.
- After receiving feedback from Y Combinator's Paul Graham, they decided to launch a new product based on an internal tool they had been using.
- The new product gained traction within a week and helped them find product-market fit.
- Another speaker shares their experience with developing Slam algorithms for AR and finding market fit in gaming.
- They faced challenges in getting the algorithms to work and had to accelerate their roadmap after Apple announced ARKit.
- They successfully launched their product and gained interest from developers, including Niantic, who later acquired them.

- Initially focused on providing investors with an information edge
- Explored ideas such as predictions and customizable data, but found them unsustainable
- Built a self-service platform with guidance for customers to access insights quickly
- Used groovy and the Grails framework for the first application due to experience
- Emphasized the importance of iterating quickly in the early stages
- Balance between engineering best practices and shipping quickly
- Prioritized speed and minimum requirements in the early days
- Implemented unit tests, CI, CD, code reviews, and controls as the company grew
- Segment went through three phases of development: hackathon mode, onboarding engineers, and focusing on end-to-end testing and security
- Importance of getting users and adapting to growth and complexity

- The speaker's company, Segment, initially did not have any users so downtime was not a concern. However, as they gained thousands of customers, they realized the importance of investing in security and scalability.
- PlainGrid, another company mentioned, prioritized security and scalability from day one due to their reliance on their product for construction projects.
- Scaling can be challenging and requires a balance between over-engineering and dealing with scaling issues later on.
- Engineering best practices are important, but there is a trade-off between writing tests and getting the product out the door.
- The speakers discuss their approach to different engineering methodologies such as agile development and test-driven development, with a focus on finding what works best for their teams.
- As companies grow, they need to constantly evolve their processes to adapt to the changing needs of the organization.
- The speakers share how their teams have evolved their processes and introduced documentation, CI/CD, and weekly planning as their teams grew.
- Segment uses the OKR model for goal-setting and execution, allowing individual teams to self-organize and choose their preferred tools and methods.

- The speaker discusses how teams at PlainGrid evaluate their performance against their goals at the end of each quarter.
- They emphasize the importance of regular communication and daily stand-up meetings to address important problems.
- Timeboxing is recommended as a way to manage deadlines and keep projects on track.
- The speaker suggests having weekly one-on-one meetings to connect with team members individually and understand their needs.
- The topic of working with non-technical co-founders is discussed, including the challenges of setting deadlines and managing expectations.
- The panelists share their experiences and strategies for working with non-technical co-founders.
- The topic of structuring early engineering teams is addressed, with a focus on the benefits of hiring full-time employees and the potential drawbacks of outsourcing or contracting work.

- The company initially hired a local team but later started hiring remote engineers for certain tasks.
- Outsourced non-essential tasks such as building 3D models, design, technical documentation, and website development.
- Initially hired full-time employees and only outsourced to AWS for infrastructure.
- Started hiring remote employees who were already collaborating with the company in open source communities.
- Communication and product alignment were challenges when working with remote employees.
- Contractors were hired initially due to financial constraints but required significant management time.
- The company went back and forth on allowing remote work but now hires remote employees for various roles.
- Advice for accelerating the development process includes getting in front of users, iterating and gathering feedback, and building versions to throw away.
- Non-technical founders should communicate with CTOs by involving them in user meetings and discussions to understand the user's perspective.

- Jared Friedman introduces a panel of successful tactical founders in the technology industry.
- The panel received over 150 questions from the Startup School forum.
- Panelists discuss their experiences with building V1 products and finding product-market fit.
- The importance of iterating quickly and balancing engineering best practices is emphasized.
- Companies need to constantly evolve their processes as they grow.
- The OKR model is used for goal-setting and execution in some companies.
- Regular communication, daily stand-up meetings, and timeboxing are recommended for managing projects.
- Strategies for working with non-technical co-founders and structuring early engineering teams are discussed.
- Hiring full-time employees and outsourcing non-essential tasks are considered.
- Remote work can be challenging but is increasingly embraced.
- Advice for accelerating the development process includes gathering user feedback and involving CTOs in user meetings.

YC Partner Jared Friedman joins founders Lillian Chou (COO, Second Measure), Diana Hu (CTO, Escher Reality), Calvin French-Owen (CTO, Segment) and Ralph Gootee (CTO, PlanGrid), to talk about what can go right and wrong building technology.

Learn more at https://www.startupschool.org/

I would like to introduce Jared Friedman, my partner, and his esteemed panel, who he will introduce to talk about technology.

Okay, well, I am super lucky to have a very esteemed group of guests with me here today.

Everyone on this panel is a tactical founder of a really successful company.

Everyone here has built a really cool company and a really amazing technology organization.

We changed the name of the event for today.

It was originally called CTO Advice and on the advice of Lillian, thank you so much, we have changed it to Tactical Founder Advice, which I think is a better description.

And I'd also like to thank everyone on the Startup School forum who wrote in with questions for the panel.

We posted a few weeks ago and solicited questions.

So thank you, everyone, who wrote in with those questions.

We're going to do our best to cover as many of them as we can.

And then at the end, we'll open it up to the in-person audience for some questions as well.

Could we start by having everyone introduce themselves and tell us about your company and about your technology, like what's your tech stack, what's some of the interesting technology that you build, how does your technology organization look like today?

Plain Grid, we're 350 people based out of Mission, San Francisco.

We write beautiful, easy-to-use software for the 17 trillion dollar construction industry.

So what that looks like to you, the analogy I often use is more like GitHub for construction.

If you have changes, that means there's issues that are happening.

And then we build collaboration tools on top of that, too, as well as a lot of other tools for the construction industry that go into some deep jargon.

We used to be based on a variety of other things.

We had to move everything into AWS over time on our back end, mostly Python on the back end, though we've got some Go and other things.

And then 1 of our challenges is we actually write native for every platform.

So we've got iOS, Swift, Objective-C, Android, all Java and Kotlin, Web React, and then Windows.

We have a full Windows app as well, which is .NET.

I'm Calvin Frenchoen, CTO and co-founder of Segment.

Segment is a single API to collect, organize, and adapt all of your customer data into hundreds of downstream tools you might be using.

Whether that's an analytics tool like Google Analytics or Mixpanel, maybe a customer success tool like GainSight, maybe an email tool like Customer.io, Segment helps you collect data from where it lives and get it where it needs to be.

In terms of the company overall we're a little over 300 people right now.

We have our headquarters in San Francisco but we also have offices in Vancouver, New York, and Dublin.

And the engineering product and design team which is kind of how we build product here at Segment, is a little over 80 or 90 right now.

In terms of our tech stack, we're also built entirely atop AWS.

In terms of how we run our infrastructure, we run on top of ECS, Amazon's container service, and pretty much all of our different services are containerized.

Today we're running about 300 different microservices, which are kind of piping together various Kafka topics, and reading and writing, transforming this data, getting it to where it needs to go.

And our back end is primarily written in Go.

I was the founder and CTO for Azure Reality.

And we're building the back end for augmented reality.

And I say I was because my company just got acquired by Niantic, the makers of Pokemon Go.

So what we were building at Azure, and now we actually continue doing it in Niantic, is building this backend technology for augmented reality to enable developers to build AR experiences as easy as possible.

So we handle all the complexity with the computer vision algorithms, with all the interaction with the back-end, all the hard parts of getting things to render, so that developers could build easy AR apps in minutes.

And we provide a lot of advanced AR features, like multiplayer, persistence, and cross-platform, so that it's easy for developers to just develop in, let's say, on Unity, and it just works.

So in terms of tech stack, it has been a bit of an adventure.

Back at Escher, we had a service that was hosted in AWS, but that didn't matter too much because we had everything in Docker containers.

Now, Niantic is a heavy user of Google Cloud, so we moved everything to Google Cloud.

But we have a lot of the bulk of the code is actually, for us, native means more C++, literally, because it's a lot more efficient for us to write the code and a lot of the algorithms once, and then cross-compile it across all the architectures for Android or iOS, and even the backend, so that we run some of the CV algorithms, we could prototype it in the phone, and then we could easily move them into the server because our server is actually also written in C++.

We got started back in 2015 and we're based in San Mateo.

What we do is we analyze credit card data.

So basically we take billions of credit card transactions and try to build a daily view into public and private company performance.

We analyze these billions of transactions automatically every day, adjust them, clean them, enrich, normalize them, and then service that in a front-end application for our clients, which include VC firms, hedge funds, and big brands like Blue Apron or Spotify to check trends, do any sort of competitive intelligence or customer intelligence.

So we actually don't have a CTO, so that's a fun fact about us.

And that's why I am here on the panel today.

And myself and my co-founder are actually both technical, so that's been pretty fortunate.

We don't have to deal with as many of the challenges around starting with non-technical founders.

So I mentioned that our team is about 50 people, primarily technical, so our technical organization is about 30 people, and that's actually split evenly between data scientists and engineers.

And that's probably something that makes us unique, is that our core product is actually the data itself.

So our data scientists and engineers have to collaborate super closely on a day-to-day basis.

Probably 1 of the things that has technically been interesting is a lot of our users want to explore and dive deep into our data.

Building a front-end that allows that flexibility of exploration while still creating a good user experience basically requires us to figure out how to rapidly query data and run really complex queries on our back end.

You asked about TechStack, we're also primarily on AWS.

So for our pipeline, we leverage services like Lambda and Spark.

And then for our front end, we're React-based and leverage columnar data stores on the backend to service queries, so think Redshift.

It's so cool the diversity of different kinds of technology organizations and products that are here today.

Okay, so most of the companies in startup school are really early.

So I want to take everyone here back to their V1, the very first version before you'd actually ship anything.

Tell us the story of how you built your V1.

Who built it, how did you built it, how long did it take you to build it, and what things went wrong in the process?

I've actually got my CEO and co-founder over there watching me right now.

Tracy told me about her idea of putting blueprints on an iPad.

This was in 2011, right at the launch of the iPad.

I can put blueprints on iPads like a PDF.

So I was attempting to impress her really quickly by putting blueprints on an iPad.

And it turns out there was actually some hardcore challenges with putting these giant images on a really low Computer availability on the iPad.

So basically these are 20,000 pixel images and they would just crash or Overrun the video memory and they're in PDF which is a kind of painful format to deal with So the first prototype sucked is really slow and that actually told me that there's something real meaty here there's something that's actually a challenge and it took me about a month to write the second prototype based off some my background actually I used to work at Pixar so I had some graphics experience there didn't use any proprietary stuff but use some off-the-shelf computer graphics knowledge to write the first Blueprint viewer that ever ran on mobile.

So that was our first prototype back then.

And I think the best thing I remember back on it is the only thing we really focused on, the first prototype, was what was technically impossible.

There was no way you could load Blueprints onto an iPad at the time, and that was our prototype, which meant that all the data got there by side loading, which meant there was no web interface.

And the little crappy web interface we had had a delete button right next to a publish button that was not a pixel apart and there was no confirmation on the delete button.

So we actually as a team we managed everything on the back and we kind of like behind the curtains loaded all the documents for our first 30 or 40 customers but they all they saw was the the prototype that was fast and did what they thought it would.

They never saw the man behind the curtain, so to speak.

So that's a little story of our first prototype.

I'll share a little bit of a story of our V1, and then maybe our V1 next.

I think for those of you who have seen the Startup School talk where my co-founder Peter talks about finding product market fit, he goes into the story in way more detail than I could today, but I can share a little bit of our journey.

So when we first started we were in the YC 2011 class, which sounds like a dinosaur now in terms of YC years.

But at the time, we were actually building something completely different from segment today.

We were building this classroom lecture tool which would help professors get feedback about what their students were thinking in the middle of class.

We were students at the time, we figured, hey, this seems like a great idea.

Professors will sometimes go on for 5 minutes and they'll lose the entire class and the class gets confused and just waste everyone's time.

We built it out over the course of the summer and we deployed it back in Boston in the fall and the whole thing just kind of crashed and burned.

Students would go to Facebook, YouTube, Wikipedia, like in retrospect all the things that you would assume college students would do if they have a laptop in front of them in a lecture, but we didn't quite see it that way.

So we started looking around for a new idea because we've just raised a seed round and we say, okay, what are the problems that we have with this college lecture tool?

And 1 of them was that we couldn't answer questions about how people were using our tool.

We couldn't tell you how College students at Harvard were using the tool differently than students at MIT.

Or we couldn't tell you how anthropology classes used it differently than biology classes.

And so we switched again to something which also we don't do today.

But effectively it was a competitor to Mixpanel or Amplitude.

It was this tool that would allow you to cluster your users by different rules and break them up into segments, which is where the name came from.

And from there, you could then reach out to them or figure out what your most engaged users were doing.

And so we built out that system for about 15 months.

The whole time we were doing revs on the backend infrastructure, we were building it out, and we were trying to get users, and no 1 wanted our tool.

And so we arrive 15 months later, we actually move back to the Bay Area after living in Boston for a year we go and talk to PG and we tell him about kind of our whole saga that's been running for the past year and a half and he listens to our story and he listens to everything that we've done.

And when we're finished, he just sort of pauses, I think it was maybe 400 feet out there, walking around the roundabout, and he says, wow, so you just burned half a million dollars, and you're still at square 1.

He said, well, on the plus side, you still have some runway left, so try again.

And at the time, we had this internal tool that we had been using as kind of a growth hack to get ourselves more users.

And the whole idea was that you would use the same API to send us data as you would send to Mixpanel, KISSmetrics, Google Analytics, all these other tools.

And people actually liked that single API and they were contributing to this open source library on GitHub and starring it and using it.

And so my co-founder Ian said, hey, why don't we turn this into a product?

Why don't we launch this and see what happens?

And my co-founder Peter said, oh, that's the worst idea I've ever heard, it will never work, he's CEO now, but he's seen the light.

And so he said, okay, I've gotta figure out a way that we can test this idea incredibly quickly.

So we cleaned up the library and we launched it on Hacker News, and to our surprise, it actually got about 1,000 stars that first day on GitHub.

And so our real V1 was that first week taking that library, and we basically just had a landing page up which said hey if you're interested in a hosted version of this leave your email and about 500 people left their email and we built out that v1 over about a week where just everyone was in mad hackathon mode and building out the product which we launched a week later and so today I think there's actually no parts of that product which still live on today but it was enough to get us kind of the seed of product market fit and then start getting us a user base.

So our story is definitely more than 1 week.

So me and my co-founder have been thinking of building different things, and 1 of the technology trends that we really saw was, it comes from a robotics background with a lot of experience with SLAM.

SLAM is this algorithm called Simultaneous Localization and Mapping, and it's 1 of the core algorithms that run today in AR, which helps tell where your camera position is while you also build this map of the world.

So what happened is there's this category of algorithms that have been used mostly for robotics.

Now, AR had been kind of tried and many times, but never really been picked up.

There's AR with markers and that never really took off.

And then we thought about why don't we bring these algorithms and run them on the phones.

And we got to the point where we thought we could do it because the computation at that point with phones, for example, for iPhone 7, has the same computation actually as a MacBook Pro from 2013.

So that's, if you think about that, that's kind of amazing in terms of all the trends with Moore's law and some of the ones with power efficiency and compute.

So we were, at that time I was actually still working and I was leading a data science team back then and say, okay, I'll do it because I was thinking of doing some transition.

And I was working part-time with another engineer on this, 1 of the engineers that we kind of got excited to work with us.

So we struggled a lot to try to get a version working.

The first 1 was very duct tape and it wasn't very encouraging.

It was only working at 5 frames per second, which is terrible because if you want a good AR experience, the whole thing is that you need it to render nicely and be at least 30 frames per second.

So that was very discouraging in a sense, and then because it was all kind of put together, this and then we started kind of really removing all the research code out.

And then it started working and seeing a lot of promise and it was running then at at least 30 frames per second.

Note that when we were working on this, it was at least about a year and a half before ARKit had launched.

So we were both more from the technology side, so we didn't know the product market fit, or where to go with this.

So the exercise we did is actually we went in and interviewed a bunch of people that we thought would use it, and we found a really good fit with gaming.

So we decided to focus on that, and that was our YC application.

And the thing that really took us, and this took off, and this is actually, I guess a good story too, is the first day of YC, Apple announced ARKit, which is basically what we had built.

And that was sort of a moment of truth for us.

It's sort of this really moment where you are looking at yourself and it's really go flight or fight.

So we decided, why not, let's just take on Apple.

So we decided to just double down and we had this idea that the start wasn't just on the device, which we had all our demos and technology was just working on the phone.

We didn't have anything on the back end yet.

So back in YC, we got it working with a back end and also with Android and basically accelerating the roadmap that we thought it was about a year, shrink it and got it done in 3 months.

And that was the thing that once we put it out there and let people sign up if they were interested, we got about a thousand developers signed up in about a week.

So they find, okay, I think we found something.

And then after that, we got a lot of interest.

And among those, Niantic was 1 and the story is we got acquired later.

So how long was it from the time that you started working on the like original Slam algorithms until you had a working product in users' hands?

It was probably about a year of part-time.

And even by the time it was part-time, it wasn't really working, so it went full-time.

I took another 6 months of just me and another engineer to do it.

And then during the summer at YC, we hired 2 more engineers, and that's when we were able to really accelerate and get it working well.

So for us, our V1 probably took, assuming full time, 2 or 3 months to build.

And I actually would say that most of that time was just figuring out what our product was gonna be.

We knew that the problem that we were working on was gonna be really interesting.

Initially, we were focused on investors, basically trying to get them an information edge on sort of any investment decisions that they're making, whether that be hedge funds focused on public markets or VCs focused on private markets.

We were like, hey, do these investors want predictions?

Do they just want to know how this company, public company's quarterly sales are gonna hit.

That didn't really seem like a really sort of sustainable business model.

It's like, okay, maybe these investors really, really want to go deep and they just want to cut data any way they want.

So we put something together really quickly, put that in front of some of our friends who are investors and found out very quickly through some light user testing that that was way too overwhelming.

So what we ultimately landed on is we needed to build our own self-service platform where we can apply our opinions around how our customers should be viewing this data and getting quick access to insights.

So once we figured that part out, it was actually pretty quick.

So my co-founder focused on building the analytics product piece, so the front end application.

And I'd say, and together we kind of focused, together we built sort of the data pipeline and sort of the transformations on the data.

But I think some important choices that we made early on is, and maybe some that you guys are facing right now, is what technology do you want to use?

Ultimately, we decided to build our first application in groovy using the Grails framework, which is very not shiny, not that many people are doing that but that was actually the code that we had the most experience in.

So my co-founder Mike had built large production scale system servicing hundreds of thousands of concurrent users and pretty much within a week had built the bones of the application.

And kind of like some of these other stories here, like none of us sounds like are running our V1 anymore.

So it's more important in the early days to be able to iterate quickly.

And usually that comes from using the technology that you know the best, and building things in a modular way such that once you actually find that product market fit and know what your audience needs, then you can focus on that area and actually select the technologies that are best fit for that problem.

Okay, so I'm gonna go next to the very top voted question from the Startup School Forum, which is about the trade-off between engineering best practices, like good test coverage and security and scalability and redundancy versus writing code as quickly as possible and shipping something.

So can everyone talk about how you made that trade-off for your V1 and then how it's evolved since then and sort of like the timetable of its evolution as your company grew and those things became presumably more important.

And just to mix it up, let's try flipping the order and we'll start with Lillian this time.

Nobody's gonna pay you for having excellent test coverage.

So, in the early days, you definitely want sort of the minimum, like what you need, right?

So assess the risk to your business around sort of security and not having things working.

And obviously you want whatever you build to run every day.

You don't want to be fixing it, breaking all the time and not actually building.

And I do believe that initially it's more important to have that speed of development and incorporate, constantly testing and incorporating the learnings into your product than it is to have like the most robust, the most scalable product.

You're trying to find something that people will pay you money for or solves a real problem and that takes time and a lot of iteration.

That has definitely evolved since we got started.

Once you find product market fit, a lot of these problems change.

You know, your system gets more complex, your team grows, you have a lot more people contributing code, a lot more ways for your systems to break, a lot more users who are relying on your product.

So for us, the way that manifested itself is, yeah, we started writing unit tests to verify, each engineer would be verifying that their code works.

Then we introduced CI and CD to make sure that that code would work with the whole system.

Our director of engineering, who leads our engineering organization, started developing and formalizing our best practices around code reviews, testing, et cetera, and defining those processes, and then finally building some more controls directly into our system to make it harder to break things.

And specifically, like, what was the rough timeline for those things?

Are we talking about 2 months after launch, 2 years after launch?

So I'd say most of that stuff I was just talking about happened probably in the last year to year and a half.

And the main reasons for that again were the growth and the complexity of our systems and our technical staff tripled in the last year.

So just that alone introduces a lot more need for process.

In our case, It was always about trying to get to MVP that was reasonably working well.

And all that was definitely duct tape code.

It's just practice I'd put together and barely working as much as possible.

So we were there even when we did the kind of private launch in a sense, when we did the private beta and got customers to kind of sign up.

And we were actually had a private beta that we had some number of game developers working with us.

The only time we started actually having all the best practices is actually once we joined Niantic, because now we have to integrate into the games which Pokemon Go has hundreds of millions of users, so we're burying ourselves to get a lot of the, we pretty much rewrote the whole code base.

To bear up to that, expect that number of users.

Cool, I think for us at Segment, there are kind of 3 distinct phases of our development.

I'd say the first 1 was when we were in full hackathon mode, right, where we definitely didn't have any tests, no CI.

See all Y Combinator transcripts on Youtube

Startup Technology - Technical Founder Advice