Why I Joined Upbound

Hi, my name is Oren Teich. I'm joining Upbound as our Chief Product Officer (CPO). I've been working in this space one way or another for a long time. For 4 years I ran product management for all developer products at Google Cloud, where I created Cloud Run and oversaw 35 other products. I founded a real-time note taking app for nerds this youtube demo acquired by Google. Before that I joined Heroku as the 9th employee and first product hire. We did $1,100 revenue in the first month I joined. I wound up running all of Heroku post Salesforce acquisition, leaving at 130 people and >$3M/month revenue. I've worked at Sun (twice), embedded Linux companies, and dang… this list is making me feel old.

Upbound is a unique opportunity and company. I'm incredibly excited to be joining. Upbound stands out for 3 big reasons to me:

• Market opportunity
• Riding a huge wave
• Proxy model

Market Opportunity

As much as I loved Heroku, an unhealthy amount, PaaS products keep hitting the same issue. "If you can't run everything you won't run anything." Standalone PaaS always struggle because of what they can't do. Even though they might solve 100% of a customers’ problems today, there's always a theoretical future situation where the PaaS might not have coverage. Real or not, those edge cases require that customers have a reasonable escape valve. For a true stand-alone platform like Heroku, this meant that jumping to AWS was the only option. Once you've started moving one piece to AWS, why not move everything? Having one thing on AWS requires you to understand the hard parts—IAM, VPC, etc. The actual service itself is usually pretty easy.

Cloud providers are a bit better positioned—Lambda or Cloud Run can solve specific problems, come integrated with the platform concepts like identity, and can offer reasonable off-ramps such as migrating the workload to a GKE cluster. But they still have a flavor of this problem. Lots of customers still want something different from what a more managed offering has, and an 'all or nothing' product often means nothing.

Companies have been trying to build their own internal development platforms for decades. Cloud Foundry was explicitly created in 2011 to enable companies to build their own 'internal Heroku'. BEA in the 90's. What's different now?

Cloud is everywhere, K8S has become a universal runtime (for better or worse), and declarative configuration/reconciliation is a really different model. That all leads into the next reason why I joined Upbound.

Riding a Huge Wave

No company stands alone. Despite not surfing, I think about companies in a surfing analogy—you need a great rider, with a good surfboard, and you need the right waves. Cloud + K8S is the wave we're riding. And it's a big one. The explosion of innovation in every area, from policy management, sidecars, GitOps, etc means a huge opportunity to help wrangle the mess.

We also need to go where the money is. Developers are kingmakers, but they aren't moneymakers. Getting a company to spend $250K/year (or $2.5M/year) isn't a choice an individual developer makes. K8S and its ecosystem is flourishing partially because it plays to company org dynamics. It recognizes that these decisions are complicated ones and empowers the complicated needs organizations have.

Unbounded complexity leads to exhaustion and failure over time. A standard model for dealing with overly complicated systems is:

Proxy Model

There are only a few models for making money. You can 'put an API on it', and you end up with Stripe or Twilio. You can 'make it mobile' or 'make it cloud', and end up with Salesforce and enterprise SaaS , while my favorite model is 'put a proxy on it'. When you have technically complicated problems, putting a proxy in front of that complexity unlocks entirely new modes of operation and use cases. See Cloudflare, or Tailscale, and now Upbound.

At Heroku it became a running joke that almost anytime we had an insurmountable problem, the answer wound up being a proxy. How do we collect logs from distributed dynos? A proxy. How do we deal with postgres failover? A proxy. How do we horizontally scale apps? A proxy.

Upbound is positioned to redefine how platform teams build their offerings by creating a new abstraction layer. We can help these teams hide the complexity where possible, build their own new things that aren’t possible today without Upbound, and enable the complicated challenges enterprise companies face without compromising the experience individuals value in getting real work done.

Thank You

Upbound is perfectly positioned on all 3 of these fronts. We have a huge market opportunity, a huge wave, and we're doing it in a way technically that I love. Combine that with amazing OSS traction and  great team—it's a job I am immensely excited about and grateful for.