When I get asked why we make certain product decisions and why our roadmap is prioritized the way it is, my answers often revolve around what I call a ‘luxurious’ position that we (as a product team) are in, because we have a clear and tight focus on our product.
But, what exactly does this mean? What is a tight focus? And why do I call our situation ‘luxurious’? What does that have to do with our decision-making process?
In this blog post, I want to deep dive into how we defined our current focus and built the bridge to what that means for making product decisions at Giant Swarm.
Early on at Giant Swarm, we were the typical tech startup. We had funding, a cool team, and cool tech (Docker and back then fleet — Kubernetes had just been announced at that point) as the basis of our product. And just like many other startups, we wanted to offer this product to everyone.
Our mission was and still is to be ‘developer-focused’. Therefore, it was natural to think you could find developers everywhere, from the single developer working on a side project, to the small-team early-stage startup, over SMEs, all the way to the global enterprise.
We were even decently successful with this, in that we could show customer success on all of these levels, and developers really liked our product. We even had customers who chose our product over Kubernetes.
However, to cut this history lesson short, we ran into a wall. And the wall didn’t budge. We had to budge, that is we had to pivot.
So, the whole team sat together and thought about how we can turn this around. We had to (re)focus, or as Steve Jobs put it, we had to start saying no.
"People think focus means saying yes to the thing you've got to focus on. But that's not what it means at all. It means saying no to the hundred other good ideas that there are." — Steve Jobs
The two main areas we identified were our technology as well as our target customers. The product focus came as a result of the two.
Remember, we were building our own container orchestration system and that was our ‘baby’. Nevertheless, Kubernetes was almost 1.0 and had gained quite a lot of community traction. We were also seeing our friends (CoreOS, Weaveworks, and Calico) moving to Kubernetes.
Furthermore, our small team alone could not possibly build all the features customers needed. Can you imagine 10 engineers competing against the Kubernetes community?
So after evaluating different options, we decided to — as they say — ‘throw away our baby’ and rebuild our product around Kubernetes.
Luckily, we already knew a lot about the community. And the technology and principles behind Kubernetes were quite aligned with our own. We could push out a hybrid (Kubernetes on fleet) version of our product in a reasonable time with existing and early new customers. But with the goal of completely switching to "Kubernetes in Kubernetes" as soon as possible, because once we made the decision to go with Kubernetes, we also said we want to be as native as possible — saying no to the IKEA effect.
"Innovation is saying no to 1000 things." — Steve Jobs
This part was much harder.
How can you say no to people wanting to give you money? And how can you decide whose money you take and whose you leave behind?
We started doing a lot of legwork, i.e. we went and talked to a lot of companies. We even did a few consulting gigs to better understand the problems these companies encountered. And in doing so, we realized a few things.
First, we learned that what we had built at Giant Swarm for ourselves in terms of multi-tenancy (as in multi-cluster), was quite well suited for the bigger enterprises who always have a multi-tenancy need of their own.
We also realized that use cases are often size-specific and not industry-specific. Sure, the end-user use cases are often vastly different, but the needs towards the infrastructure and Kubernetes or say an Ingress Controller can be similar. For example, you might think that an international IoT management platform and a global high-traffic e-commerce website have nothing in common. However, when you look at the requirements, you might realize they both need to be run in globally distributed regions, close to the end-users, and the global distribution means that they have varying peak demand times over the course of what counts as daytime in each region. In the end, the stack on top and configuration of the infrastructure is what changes. And we learned early on that while we want to give the utmost freedom in using the stack and config you need in your organization, customers still do want the guidance of an experienced partner who has an opinion without being strictly opinionated.
TL;DR: We decided to focus on big enterprises first as we realized that those customers were our best fit because they experience bigger pains and thus are motivated to change early.
Henning, our CEO, often used to say that it’s a bit like the Tesla approach. You start with the ‘high-end’ customers first, and then through constant improvements on the product with these customers, the benefits can trickle down to the wider audience of smaller customers.
The new customer focus helped us make product decisions for a focused set of users. With big enterprises as our focus, their needs constantly guide our decisions. That also means we can defocus the use cases of the masses. We can also more easily say no to features and we can focus our UX on the specific needs we see. It also means that we can build features that are useful right now in a meaningful way and aren’t shiny ‘bling-bling’ features that cater to hyped topics just for the sake of ticking off a checklist.
As mentioned earlier, Giant Swarm’s product was built with hard multi-tenancy from day 1. We always had an internal requirement to strongly isolate tenants, as in the beginning, those tenants were actually different customers of ours. Now, with the new customer focus, this meant that we were running the same platform, but privately for a single customer and their internal multi-tenancy needs. And with the almost nonexistent state of native in-cluster isolation (no RBAC, no PSPs, etc.) of early days that meant multi-cluster was a must! And still today, with our customer base, there’s no single enterprise we see that could run without multiple clusters.
In fact, 30-60 (or even more) clusters are not an uncommon sight. That, in turn, means that Giant Swarm is a multi-cluster first product. Product decisions are made under the assumption that our customers run fleets of clusters.
For example, when we thought about adding more managed apps (roughly two years ago) we didn't want that to just be a one-click install web UI like an app store.
The goal was to enable users to manage stacks of apps on fleets of clusters. Think:
➡️ All our dev clusters have a basic observability stack with base config.
➡️ All our prod clusters have a full observability stack with HA config.
And then think:
➡️ I wanna spawn a new dev cluster for my colleagues in Spain.
➡️ There's a new team and until they learn the ropes they're getting their own dev and staging and it’s already set up similar to our shared dev and staging clusters.
The other side of a tight product focus — especially with one based on big enterprises — is that at least for a considerable while, you will be working with a ‘small N’, i.e. the number of customers will be small.
That means that you are blocked from making a lot of significant data-based decisions. And you will risk building complex customizations and even forks of your product just to make a big customer happy. It’s not easy to say no to a company that pays 10% or more of your payroll. We learned over time to make much more nuanced decisions. They are more qualitative and guided not only by current and potential customers’ needs — not always equal requests! But also by what we see in the wider end-user and upstream community as well as by what our own thoughts about developments of the ecosystem and market are.
And customers also learned that they don’t want to run a fork of your product because they don’t want to end up waiting longer to get each feature you’ve built and have some features not even work for them at all. You want to run a single product for all customers! And customers appreciate that because they benefit from the synergies of all the fixes you make for every single customer across the field.
A common misconception is that if you want to operate your product and offer it to customers fully managed, then it has to be a SaaS. However, based on our focus on large enterprises, we decided to run our product privately in each of the cloud accounts and/or data centers of our customers. It’s still a single product and we had to work on getting continuous delivery working behind firewalls and VPNs, but there’s no shared infrastructure between customers. Each installation is autonomous, independent, and updated automatically.
Last but not least, from the get-go we’ve aimed to establish actual partnerships with our customers. Especially our first customers who helped us sharpen our product in a lot of places. Our relationship with our customers is always built on trust. Despite their size, our customers always accept us being quite cutting edge. They are open and eager to learn and adapt, and in some cases, they even encourage us to be more daring.
Take security as an example. This is a big topic for enterprises. You’ll usually have a full department just for that topic and another one next to it for compliance. For us, that meant it didn’t stop at multi-cluster isolation. We had to lock down access with RBAC and PSP when they just came out in alpha. We went through benchmarks and checklists and even had external pen testers involved. This striving for more security continued and still continues so that our clusters come tightly locked down by default. So locked down in fact, that when we were testing additional security products with a customer last year, some of them were not even starting up because they had never run in such locked-down environments before.
I want to end this blog post with a heartfelt thank you to all our customers. Thank you so much for the trust you put in us and the learnings we make together every day. I feel privileged to call you partners and even some of you, friends.
We empower platform teams to provide internal developer platforms that fuel innovation and fast-paced growth.
GET IN TOUCH
General: hello@giantswarm.io
CERTIFIED SERVICE PROVIDER
No Comments Yet
Let us know what you think