Dogfooding Without a Stomach: An Enterprise IT Story
4 minutes reading time
Jake Golden
Product Engineer
Dogfooding isn't so simple when you can't become a user of your own product. Jake explains how we survive without eating at Conduct.
We software engineers are a particular bunch, particularly when it comes to nutrition. Some of us swear by Huel. Others, David bars. At the Conduct office, we go through upwards of 10kg of Skyr yogurt per week.
But there’s one culinary point where all of the top AI startups agree: you have to eat your own dog food!
Historical aside: Why do you call it that?
Who knows? You’re talking to the people who name pieces of software things like SimpleBeanFactoryAwareAspectInstanceFactory and core infrastructure after dolls. Some people claim it’s because dogs will eat their own…, well… anything. Wikipedia claims it literally comes from dog food CEOs eating their own product. Let’s go with that.
You are what you eat
The wisdom of dogfooding is glaringly obvious: the more you use your own product, the better you’ll understand it and the faster you’ll find ways to improve it. So, of course, everyone should do it, right?
At Conduct, though, it’s not so simple. We don’t use SAP under the hood to run operations at Conduct, we don’t build our app in SAPUI5, and we don’t store our source code in a database. It’s just not as simple as coming into work, loading up Conduct, and seeing what happens.
(We should note also that we don’t usually have the advantage that B2C product teams have of being able to run into users outside of work and get their feedback. I say usually because, believe it or not, it has happened.)
So, how do we still move at the pace of a cutting-edge AI startup?
[Warning: Excessive metaphor incoming.]
Ultimately, in the absence of being able to eat our own dogfood, the best thing we can do is watch a lot of other dogs eat! Do different dogs have different preferences? Do different packs? Does the same dog eat the same food every day? How do the dogs split up the food?
Why eat software when there are delicious treats at Conduct HQ?
Our customers know the product they want, we just need to build it
[Editor’s note: to spare readers, we’ve de-metaphor-ed the rest of this post.]
At Conduct, our goal is to revolutionize the way the entire enterprise IT function operates in the age of AI. But what does that actually mean?
It turns out it is a lot more complicated than just pointing a coding model at some ABAP. It’s about figuring out how to accelerate organizations of up to 50,000 people in everything they do. There’s coding, to be sure, but we’ve found that only accounts for about 15% of the time — the rest is running workshops, designing processes, understanding requirements, negotiating constraints, writing documentation, testing code, and much more.
Luckily for us, we have access to the experts: our customers. They know what “good” looks like, they know where their systems currently break down, and they know what would really save them time, effort, and stress.
I’m not the Forward Deployed Engineer, I’m the engineer who deployed forward
This is where you might expect me to begin talking about our Forward-Deployed Engineer model. The FDE approach is nearly as popular in tech blogs as dogfooding (I’ll spare you the links). But that’s not quite actually what we do at Conduct.
If you’re a Product Engineer a Conduct, your responsibilities will still look a lot like an FDE’s: you build the product, and you do it directly with our customers. In Teams chats. In WhatsApp. In weekly checkins. In live demos. In person at conferences. In person at their offices. In person at our offices.
The difference is: in an FDE motion, customer work is project-scoped, and it might take 3 or 4 projects for the common pattern to emerge, at which point it can be abstracted into the platform and used for the next projects; at Conduct, there is no project — we build the platform directly and share features across all customers at the same time.
Why does this work? We’ve found that the use-cases for our platform are extremely uniform across customers; it’s not uncommon to pull up your local dev environment in a sales call just to show a bit of what you’re working on after realizing it is exactly what this new customer wants, too. It may be because so much of SAP is already shared across customers, it may be because over time, customers have converged on very similar best-practice operating models, or it may be sheer coincidence, but the upshot is that we get our product into more hands a bit quicker than we might otherwise.
If you look at it from one angle, it’s a distributed platform team. From another angle, it’s FDEs with no abstraction cost.
We might even call it “FDE Lite”. Bon appétit! [Editor’s note: Sorry.]
