Aug 24, 2024
Hi Folks, Will Butler here, CEO of doFlo. As my team and I begin to grapple with the thousand and one challenges of launching doFlo’s private Beta this coming September, I decided to sit down with Lloyd Waldo, our new head of Marketing, and talk about what we’re doing, firstly as a technology company, but also as a team dedicated to shaping the future of automation in the 21st century.
Lloyd was kind enough to heavily edit the transcript of our discussion, to give our potential customers, partners, and investors an idea of what this company is trying to achieve, and how we’re going about it.
So, what follows is an in-depth discussion of doFlo and the trends in technology and business that are shaping the future of no-code automation. Lloyd has helpfully cut out the 20 pages in which we discussed Black Mirror and other tv favorites. If you like that kind of thing, maybe we’ll do a podcast 😀
Sign Up For the doFlo Private Beta
The “Ahah” Moments Behind doFlo
The classic startup error: you try to be efficient.
Lloyd: Okay, so I'll just cut all that out of the transcript; that will be easy. so let's start with a softball…
Will: Go.
Lloyd: How did you come up with the idea for doFlo? And let's be even more specific and say at what point did you have a moment… where you said, “I have to start a company that does this.”
Will: There are two moments, so I’ll talk about those: the first was while [doFlo Co-Founder] Thomas and I were working with you on Steel Mountain about seven years ago. That was our cyber-security startup that attended StartupYard Accelerator when you were working there. Thanks, by the way! We wouldn’t be here without you guys.
Lloyd: No Comment. You did all the real work.
Will: Haha, but it was an incredible experience. We worked on Steel Mountain, developing a hardware gateway for home internet connectivity. We used sophisticated Ai to protect your home network from intrusion and cyber attacks. It was a hardware startup, and we learned very thoroughly and painfully how difficult a hardware startup really is. Avast acquired us, and we stayed on to work as a product team for over five years.
Lloyd: Perhaps not what you had in mind.
Will: I’m glad it happened. We were acquired and got to work with a world-class cybersecurity firm, and the experience taught us a lot. It taught us the difference between a global enterprise and a startup.
We had already noticed while we tried to scale up Steel Mountain that starting a company involves creating and managing accounts on so many platforms and with so many services. We were used to working as a small team, so our instinct was always to try to do everything ourselves. That was the first moment for us when we realized that we were wanting to spend a lot of time trying to make these processes work efficiently. We wanted two things: control and flexibility. And control is difficult to maintain when you’ve got so many balls in the air. So we seemed to spend all our time trying to systematize everything. That’s the classic startup error: you try to be efficient but you end up being slow and inflexible because of that. You have to do things inefficiently or else you aren’t flexible enough. Does that make sense?
Lloyd: Yeah, I always told you guys: “Hire more people, don’t try to scale everything at once.”
Will: Yes! But hiring people is scary, mate. That’s a lot of responsibility. We weren’t ready for that yet. So we did the classic tech-industry cliche, and we tried to automate everything ourselves…
Lloyd: Yep
Will: I think from the outside, it’s sometimes hard to understand why companies don’t automate so many tasks, or why startups have to hire so many people so quickly. One of the reasons is simply that one person cannot keep all the balls in the air. You bring in new people just to make sure you didn't miss anything.
Lloyd: But more people means more points of contact. Less efficiency.
Will: Yeah, the classic catch-22 situation. What I know now is that there wasn’t a service out there like doFlo. There wasn’t a way for a small organization to build complex and robust processes, and then grow that operation to a larger scale without losing that flexibility and speed that you have with a small team. There were some services like that, but they weren’t as flexible as we needed, and they lacked a lot of integrations we were looking for at the time.
Lloyd: Did you have a conversation where you said we should be doing this instead?
Will: It was too big a problem, and we were focused on our own company. We just gave up on the idea that we could scale everything we were doing and still do everything we wanted. It wasn’t gonna happen. Then we got acquired into an organization where that kind of deep work on processes is possible.
At Avast, we were able to work with a large-scale organization and seek a lot more effective automation solutions. But again, there are challenges to that in a large organization. Visibility into what is automated and how. Analytics and live monitoring of all your automations is very hard. We knew we hadn't cracked the code yet.
So at small and large companies, there are just a lot of labor-intensive tasks that don’t bring a lot of meaning. They don’t help you as an organization to do your work better. They sap your time and energy. That’s why customer care teams are still huge at technology companies, even when, in reality, so much of what they’re doing is just point-and-click stuff. Organizations would love to be able to integrate, say, connectivity to every API their service connects to, and then match every user with the connectivity status of every service, and then see instantly why a particular customer is having trouble with something. But nothing like that exists. And as the work of SaaS companies becomes more complex and your services touch more and more other services, this problem multiplies.
Lloyd: So it’s really about the analytics and monitoring.
Will: That’s a huge part of it. When you design an integration or connect to another service, you want to be able to say, “ok, this will just work, and I can now forget all about it and do something else that brings value to the customer or the company.” But you can’t do that. You then have to deal with that service every time it fails for whatever reason. There is no place where you can see all these services and integrations, and see what is working and what isn’t.
Almost every single mentor at StartupYard told us: “Get a personal assistant, a customer care lead, and a sales lead.” I didn’t think that those should be the first people who you hire, because you’re a product company. And you have to hire 3 people immediately that don’t work on your product? It seemed crazy to me. But they were right. You can’t get anywhere without those people because their work will consume so much time and take so much attention away from building and improving your product.
So doFlo is trying to do that. We’re trying to provide a way for a tiny organization like we were, to scale to a big organization, and keep them focused on the valuable tasks they have while keeping insight into what they’ve done so far and managing all the services and tasks they have running at once. I like to think of it like a “work os.” You can build your company through doFlo: you can use it to build a complex organization using automation at every level.
Lloyd: Do you want to eliminate those jobs with doFlo?
Will: Absolutely not. We learned by trying to work without assistants, salespeople, and customer care. You still need the people, but instead of having them spend most of their time on repetitive, mind-numbing tasks, you need them to do meaningful work: improve your product, improve services. You want them building, not fighting fires. I want to have an assistant that feels empowered to create their own automation and manage their own workflows. I want salespeople who feel creative, and willing to take a risk and try a new approach, or look at new markets. Let them automate what they do, as they go, so they can feel in control of their work, and take ownership of what they do.
With doFlo, that’s what we want to promote: the idea that every worker is a builder. Every employee is part of the creative process. Because what we also learned at Avast is that the people who aren’t “builders” actually understand the customers and the organizations in ways that we builders don’t. They know more about what people want, and what they need from us. That’s super valuable. Even somebody like a PA: they understand what makes the person they’re assisting happier and more productive, don’t they? So shouldn’t a PA have a way of automating tasks to improve the quality of life for their boss? And shouldn’t their boss also take the time to think: “Hmm, how can I make my employees’ lives better? How can I do that at scale?”
Lloyd: Now you’re not really talking about technology, but about people.
Will: Yes, because people make organizations. And happy people make better organizations. And drudgery makes people miserable. So eliminate the drudgery, and you have a better company. Not necessarily a smaller company, because this is not about eliminating human beings. It’s about empowering each human being to own their own responsibilities. So they feel they’re building something sustainable they can be proud to call their own.
When organizations grow, a lot of the things we need just get dropped. Right now doFlo is just a handful of people. I can do a lot of the personal and professional things that I want to do with everyone around me. But as the organization grows, a lot of that communication and information exchange gets lost or gets harder. I want to develop automation solutions that allow human beings to talk to each other. To spend time with each other, instead of spending all their time fighting fires. I want something where I can say: “please figure out a way for us to do XYZ,” involving half a dozen areas of the business, and the person can come back and say: “yep, that’s done now, and here’s the process.” Good. Next idea. Next way for us to improve, you know?
Lloyd: I always feel like I get hired, and I’m a “universal API.” I’m somebody who is very often doing things that could be automated. They aren't because if someone did that, nobody would be on top of it if anything breaks or changes.
Will: Exactly! You might find ways of being more efficient, but they don’t spread to the organization. They’re all siloed and separate, and nobody can see them or understand them but you. doFlo will allow organizations to work together in a very flat structure: we all use a single “work os,” which shows all the processes and tasks we all do, but also allows most of that stuff to run without any intervention. It only becomes necessary to intervene when the system doesn’t work, or when an issue we haven’t seen yet pops up.
Lloyd: Many “productivity tools,” like Slack or Google Drive, have specific advantages, but don’t connect to each other easily, or comprehensively.
Will: That’s right. There are many, many efficient ways of doing things, but they don’t all connect. We want to connect everything we do to this. doFlo wants you to always to spend your time building great services for people, and not just repeating the same work over and over.
Comparing doFlo with Zapier and Make
I want to build things, and I want people around me to be free to build things too.
Lloyd: So let’s talk about those services. There are companies like Make, Zapier, or even IFTTT. Those are “integration and automation” companies. What’s limiting about what they do?
Will: At Avast, we used those products. They’re great at certain things, but there are two big problems:
First, there is always a problem in that they will do 80% of what you need. Maybe Services A, B, and C are available, but Service D isn’t, and that’s critical to the whole thing. So you do that one manually, or you have to cobble together some kind of automation for Service D. It takes a lot of time, and it’s not 100%.
The other problem is reliability and robustness. They might connect Service A to Service B, and then service B to Service C. But what happens when Service B stops working? The whole process then breaks down, and you have to bounce around and figure out what changed. What stopped working? So you’re spending a lot of time solving problems that bring your organization zero value. It’s just work. And I hate “just work.” I want to build things, and I want people around me to be free to build things too.
Lloyd: It’s a big ask: to be able to 100% automate a task and have it be reliable.
Will: So we started with something simple. Thomas and I own an online MMORPG we started over a decade ago, and most of the business is automated. We aren't involved day to day. We decided to move all our automations over to our own new platform. That means everything from the server status, the online stores, the website, the discord, the budget, the EVERYTHING. We wanted to move it all into one place where we could see and manage everything, and have it all connect. No more spreadsheets. No more huge Slack discussions where we forget half of what we did in the past. All on one platform and all automatic.
In that process, we validated that we could automate everything with doFlo. And when we found that out, well, we just had to do it, didn’t we?
Lloyd: So everything in that company runs in one place?
Will: Essentially, yeah. Of course, we still have tasks we don’t automate because communication, building, and discussing ideas is not an automatic process. But when we make something new: when we make a decision about how something should work, we can automate that decision and execute it everywhere. Then we know that the task is being taken care of. We can see that every automation we have running is working as intended. If it isn’t, then we can fix it in one place.
Lloyd: Why do you think nobody was doing this already? It seems obvious when you describe it.
Will: A big part of it was the technology approach we used. We decided to build natively on event streaming technology. That has allowed us to rethink how an end-to-end integration can be run. Unlike Zapier or Make, we’re not focusing on getting two end-points to connect. We’re not starting with Service A to Service B, and Service B to Service C. Our solution “sees” the whole picture. That’s how we get reliability at scale.
Lloyd: Talk me through that. What is Event Streaming Technology?
Will: it's essentially a means of tracking data, along a workflow from, let's say, node to node between different applications.
This doesn't only give us a greater level of granularity in control but allows us to work with asynchronous signals rather than synchronous signals. It also enables us to report on the state of the data integration is receiving at any point. So instead of seeing two end-points and either “red” or “green,” you actually get to see: “ok, yes, data is flowing from Node A to Node B, then Node C is working with this data and returning it to Node A.” That is a live process, as opposed to a “pass/fail” status.
The implication is that doflo can also provide the user with visibility of how that data looks at any point in that workflow. That means analytics that isn’t just focused on uptime or speed, but performance of every part of the process. It translates to giving users visibility of how their workflow is performing. So if they have any issues, if something's not working, they can see exactly what’s happening.
And not only that. doFlo can also give you this kind of heat map: this bird's eye view of what that workflow is doing, where perhaps there are bottlenecks when human intervention is required. This allows users to make informed decisions as to how to improve workflows because they see them as a big-picture process. Because doFlo works asynchronously, a person can see how it performs and improve it without starting over from the beginning. With conventional automation, you are limited to a kind of procedural approach: “This happens, then this happens.” It’s linear.
With doFlo, you can have parallel tasks happening simultaneously in a single workflow, so you’re not necessarily limited to having every service involved working at the same tempo. After all, some processes must happen, say, once every 2 or 3 seconds. Others need only happen once a minute or once an hour. If your automation is linear, then it is naturally always going to be limited by the speed at which any service involved can update, limiting your real-time view of what’s working.
The Problem with Linear Automation
To visually design a process so that every step in it will be both independent and monitorable.
Also with doFlo, you can have subroutines that activate only under certain conditions. Therefore a flow can be made much more efficient, as not every routine has to happen in the same order every time. Some flows only activate in case of a failure condition.
Lloyd: What kind of automations really suffer from this linearity problem doFlo is solving?
Will: Take identity verification. Let’s say I need to verify a user’s identity, like for a financial product. I need to take the user’s information, and then I need to approach a whole slew of different services that will run various checks for me in order to go down a checklist of proving the person is who they say they are. Right now, in order to do this in a reliable way, I need first to collect all that data from the user, and then I need to have an internal system that splits that information apart and then approaches every service involved separately, waiting for each of them to finish, and then my system needs to wait until every step is complete.
With ID verification, there’s a credit service, there’s a photo verification service, there’s a location service, and there’s an IP tracking system. There are a dozen different SaaS products involved and they all have different demands. If even one of those stops working, you’re over at the beginning again.
And what happens when one of those checks doesn’t go through? For whatever reason? The whole verification process fails. I have to go back to the user and get them to do it all again, and maybe that involves a bunch of steps they’d rather not have to repeat. With our system, you don’t have to rely on this “pass/fail” outcome. You can see what step in the process doesn’t work, and then change that one step. Not start all over.
Now, that’s not impossible for companies to do, and the best ones do accomplish this kind of ease of use, but they do so at tremendous internal costs. What seems like an easy process is actually hell to design. You have to develop that whole process to make it efficient and easy for the user to handle. With us, that process can be designed and implemented in one place. You don’t need to adapt what you’re doing to what the APIs that you’re dealing with can handle. Instead, your process design is the coding in doFlo. It all happens in one place.
This is why there are a ton of processes that users hate to go through because we are trained to know that there’s always some hiccup in the process. Then you’re constantly involving customer care or even developers to fix things. All the time. And you can’t move on to getting high-value tasks done. You’re stuck troubleshooting a zillion processes.
These services are now moving to text-based design of these processes, to make it easier for their clients to design sequential processes. But that isn’t going to be a huge help for reliability. If you design processes natively as sequential, then they will be constantly at risk of one of the steps being interrupted. The way doFlo is doing it, you will be able to visually design a process so that every step in it will be both independent and monitorable. You will be able to design a “flo” that will still work even if one of the individual pieces in the puzzle doesn’t work.
Design = Process
You can't have both a no-code environment and a truly robust automation environment without a powerful set of design tools.
Lloyd: So doFlo is making the visual design of a process synonymous with the process itself.
Will: Exactly. Most complex processes have a lot of branching condition statements: loops, essentially. If you build a process in a linear way, then it is vulnerable to any changes in that process. But if you design it as a flow where you can see what the status of your data actually is, then it’s very robust against changes in the requirements for data, or the requirements of all the different APIs involved. With doFlo it can be redesigned without anything breaking.
Lloyd: Why is industry standard notation important?
Will: We're talking here about Lucid Charts’ Miro. That’s the gold standard for how to design a process visually, and it was important for us to be able to offer a visual design aesthetic that mirrors what a UX designer would actually be comfortable with so that they don’t have to translate a fully realized design into somebody else’s design language.
All of those tools are very familiar to the user. At Avast, If I were proposing any new process to my bosses, I would always use Miro and I would annotate them with open text. At doFlo we want to make it so that presenting the solution is the same process as the solution itself. If you can design it, you can make it. Simple as.
Lloyd: Why doesn’t Make or Zapier do this?
Will: I honestly don't know. I suppose that they’re targeting people who aren’t in product management. doFlo is approaching it assuming that good process design needs to be the same as good product management. So we want to help our customers become better process designers. In order to do that, they should learn the tools that make good process design. And while they’re doing that, doFlo can turn those good designs into robust, working processes.
Lloyd: So you are probably going to be asking your users to learn a bit more about process design.
Will: Yeah, no doubt. What they learn about process design using us will translate into a lot of saved work. Once those processes have been designed properly, they’ll continue working and will be easy to change. doFlo’s not promising a “low code” environment. It’s a “no code” environment. But in order to do “no code,” you have to have more robust design elements to make up for that. Instead of having a dumbed-down visual design environment that compensates for the lack of flexibility by making the user know some code, doflo offers something that requires zero code, but does require the user to get to know some design principles that are critical to making a good process.
It’s the difference between a good visual website designer and a bog-standard WordPress build. One way or another, you have to know either how to code it, or how to design it well. You have to know one of those.
You will never have both a no-code environment and a truly robust automation environment. Not without a powerful set of design tools. That’s… a contradiction. It will never happen because, one way or another, any automation you design has to contain that information. We choose to make it so you can input all the design information into the system without using code. But in order to do that, it’s going to require that you have some powerful design tools.
Lloyd: Now that makes more sense to me. As a communication designer, I want my design tools to show me exactly what the user will see. I don’t want to edit HTML when I’m thinking about how something is going to look.
Will: That's what it's like [with Make or Zapier]. It doesn't look like a no-code experience. It looks like a low-code experience. It's still while it is a flowchart, there are a lot of controls on the screen. There are a lot of controls that you need to delve into. And it still seems complicated. It doesn't seem like the familiar way that we're used to building processes, and that's what doFlo’s striving to do. We’re striving to build, Basically, a Lucid Charts-esque process builder. It has to have a hell of a lot of power under the hood through automation.
Lloyd: Steve Jobs used to say you have to start with the user experience and work backward to the technology.
Will: That's exactly right. doFlo is starting with a fully-fledged process design tool… but we are building, underneath that, a powerful automation engine.
Lloyd: So why do you think nobody's done it?
Will: Make has come close. They’ve been moving in this direction, but we’re starting where I think the technology allows us to be. We aren’t hampered by supporting an existing user base right now. We can be where the technology is today. And where it is today allows for a truly no-code experience. It’s ready for that. ChatGPT has made it so that we can fully access the power of any API integration using plain text. You just describe what you want it to do, and we can use our engine to integrate it. Therefore we can move forward with the confidence that a fully design-focused system will be powerful enough.
On ChatGPT and Generalized AI
The little “wow” things that you find in UX/UI design, product copy, or visual design. Those are human things, and they need a human touch.
Lloyd: And maybe this is something you can also address: with these truly no-code products, it seems as if the trend is such that generalized models like ChatGPT are starting to become the norm. Does it concern you that this technology will leapfrog what you’re doing, and be able to design automations without even a visual design process?
Will: It's not a fear for doFlo. I think we're talking about technology, not a product. ChatGPT doesn’t “do” anything if you see what I mean. It doesn’t have the capacity to learn, or to evolve, as many people probably expect it should. That’s in the nature of the “pre-trained” models. They don’t learn. They don’t build on experience. When you are building a product like this, you want it to get better over time. You want people to be able to design processes, share and copy. More people benefit that way. That still takes human brains and problem-solving.
ChatGPT or other pre-trained models will be a big help to us because they will be able to execute many simple functions by understanding complex requests. There are many ways you can incorporate a pre-trained LLM (Large Language Model) into doFlo: either as a part of the design process or even as one of the inputs and outputs that automation will use. ChatGPT can be an interface for customers, or it can be a helper for people using doFlo.
Lloyd: So you're not afraid that in a year from now, there will be a company that comes out, and they are the “no-code development platform,” and you just describe what you want. And it doesn't matter if it's an automation, a website, or a product. You know what I mean?
Will: I do, but I absolutely don’t see that in our future. And the reason is maybe not what you think. It’s not that technology won’t be able to do some of those things somehow. The reason will be that the creative, iterative process of designing systems and workflows is something humans do. That's what it means to be creative. The best aspects of an idea are things that come out of the process of designing them. The little “wow” things that you find in UX/UI design, product copy, or visual design. Those are human things, and they need a human touch. A pre-trained model will be fine just copying what’s there, but it will never do anything “new.” That’s not in its nature. doFlo is offering a way to do something genuinely new.
Lloyd: Talk about that, because I think a lot of people have the wrong idea about what ChatGPT and other LLMs really mean and what they will be capable of
Will: Well, on the one hand, I would not want to underestimate what ChatGPT could be capable of, or how useful it can be for doFlo. But on the other, it’s important to understand the boundaries. It’s chat. It’s a model which is trained on millions of samples of writing, and it uses complex probability models to project what the correct or wished-for answer is. But in that are inherent limitations. One of those is that it’s pre-trained, meaning the model you’re interacting with never learns from you. It just does what it does. If it gives you a bad answer, it can’t analyze and correct itself. It can’t retract bad answers if you will.
ChatGPT is also not inherently… “human.” I don’t know how else to put it. Being trained on millions of texts is important to generate a probabilistic model for text generation… but that does not make it a great literary voice. It makes it what it sounds like an amalgam of many influences. It’s useful, but it’s not a paradigm-shifting technology, yet. It could be. But not yet.
We’ve done a lot of experiments with ChatGPT, trying to figure out how it can help us create integrations, and there are some promising results. But there are clear bounds to what’s possible. Let ChatGPT interpret simple instructions. Let it summarize or do research for you into texts and other sources. And letit even give you a summary update on how all your automations are functioning. That’s what it’s good for. We want our customers to use it to its full potential, but integrate it in such a way that it enhances human activities. It will not replace people. That’s my take on it.
Lloyd: Do you think people are over-promising or will over-rely on ChatGPT?
Will: Oh yes. They already are. People really do think these algorithms are smart because they sound like a person. But they just sound like one. I’ll tell you this: I don’t know anyone working on the science of LLMs that believes General Intelligence is anywhere in the near future. I don’t think people at the cutting edge of this technology believe that’s possible right now. Many think it never will be.
LLMs right now are just baby steps toward something like that. But people think they’re infallible already; that’s how people are. LLMs have biases because they’re trained on texts reflecting our biases. They make mistakes because humans make mistakes. They don’t know right from wrong in any real sense. So people will abuse them, but eventually, we will begin to see that really it’s just an extension of this incredibly complicated digital world. Humans did all that, and ChatGPT is just the latest manifestation of what you can do with a fully digital world. Nothing it does is revelatory because it’s all based on things we do as people.
Ultimately it's just human beings who can't seem to do anything without exploiting people like folks getting paid a few dollars a day to moderate ChatGTP outputs. That's people doing that abuse. It's not the technology.
Lloyd: How will you fight that tendency to over-rely on AI or automation? You seem in a perfect position to feed into it.
Will: Yeah, we are. And so the way we incorporate AI into the platform has to be conscientious, and careful. We can’t just slap ChatGPT into the product and call it automation. A big issue in building anything -a company or an automation- and one we must be careful to address, is availability bias. That’s the tendency to make decisions based on the data or tools you have in hand, rather than a more complete, holistic understanding of the issues you’re dealing with. That can come in a few forms: of course, ChatGPT can suffer from availability bias, because maybe the training data is more abundant in one area of information than another.
Another way to suffer from availability bias is in product design: you move towards doing things that will provide you with the most data. I mean, in the tech business, people even make that into a kind of virtue: “do things you can measure,” they say. That’s good, but it also biases us toward doing things that generate data. When we have people building automations on our platform, I want them to be able to balance between all the options they have available to them and be able to think “blue sky” thoughts that don’t have any precedent or existing infrastructure. I want our platform to be ultimately a creative one, and to do that, you need to avoid this bias towards the available.