Product -> Infra -> Brand

“You’re don’t care about infrastructure enough. We should just work on infra this quarter”

“Let’s ship X, Y, Z. They’ll all be the next biggest thing”

We’ve all heard of statements like the above ones before. How should we prioritize building products vs. focusing on infrastructure? And what’s the point of brand and why does it matter?

In the beginning…

When you are starting out in building a business or product line, infra rarely matters. If you’re building a business from scratch, the least important thing is writing scalable code. My personal opinion is that TDD is useless as hell in the beginning. Who cares about having good code if you can’t even prove product market fit. Coding is one of the many tools used to build a business. If you have a shitty business, then it’s going to die anyway and no one is going to care that you had a million micro services, your DB load was under 10% all the time, or you decided to use protocol buffers over JSON. Same thing with a product line. When you’re first starting out in a product area, build a MVP and try to learn as much as possible. Don’t worry about writing scalable code. I’d be very surprised if the product didn’t change along the way and you are forced to refactor your code. If it didn’t, then either you’re really damn good at predicting what to build, or you’re not taking enough risks in innovation.

To summarize, in the beginning of a product line, focus on learning as much as you can. Learn from your end consumers, experiment, and move as fast as possible. It’s okay to hack things together, and you should build shallow products fast.

At some point…

You’ve gotten some semblance of product market fit. There are people using your product. The product has enough features where there are multiple developers working on it. Certain problems start popping up at this stage. You might experience some of the following:

• Regressions are happening
• It’s becoming a pain to even write a line of code and you have no idea how the other parts of the app work even when you spend time looking into it
• Your customers are leaving because of stability problems
• You’re spending chunks of your time of the week firefighting issues
• Customers are having issues, and you don’t have a good way of reproducing the error

These are signs that you should work on the infrastructure of your product. In most cases, any hour spent on infrastructure will be more valuable than an hour on product. My guess is that an undetermined amount of money is bleeding because of the above problems.

If you make it out of the hump (it’ll take awhile, as you’ll be jostling between product and infrastructure for a long time) and you’ve settled on a common scalable infrastructure, you’re ready for the final phase

Not many make it here…

In my opinion, a true tech company carries a brand with it. Back in the day, people regarded Facebook engineers and Google engineers as top notch. That’s why there were the terms ex-Facebookers, and ex-Googlers. Brand is an abstract concept as it’s very hard to measure. There’s different ways of creating a brand — giving tech talks, blogs, open sourcing, etc. At the end of the day, if you’ve created a positive tech brand, you’ll be able to recruit the top technologists.

I’d like to get DoorDash to be known as a tech company. When I think of awesome mobile companies, I can only think of a few. Square is amazing at Android, and Facebook’s (especially Instagram) iOS expertise is very strong. I love reading ThoughtBot articles. One of the goals I’m very passionate about is getting us to belong in that elite group.

What to work on

We’ve still got a long way to go on the product and infra side, so here’s how I think through what should be worked on. At this point, we should dedicate some time to future projects. 10–20% of our time should be spent on educated guesses of what may potentially be 10x projects. For the other time, we should just take a greedy approach in what we should work on.

At the end of the day, everything is tied to a business metric. Horrible infrastructure and downtime will not allow us to hit our GMV goals. Slow developer productivity leads to less output which in turn would lead to some estimated loss. It’s definitely a little vague, but the sooner you can boil everything down to a number, it becomes very clear what is the next important thing that needs to be worked on.