I think it's a gradient, depending on the team. And what we're seeing most at Webflow is that for developers — even though conceptually a lot of people think we're trying to work developers out of a job, right. But really, what's happening is we're trying to automate the things that are most prone for automation — so for developers they’re elated because they get to work on the hard stuff on the really interesting problems now.
For designers it makes them the heroes. It’s a superpower, right? Because they're doing the work of two people now. And they're feeling more creative!
For PMs they get to move faster as well. They can validate ideas sooner. They can vapor test things faster. They can rely on their designers and the research phase, a lot more as opposed to the waiting that happens with the classic waterfall where you design something and then you have to wait for dev to go implement it, or you have to prototype it in code and then somehow present it to users.
A lot of times it starts from the operation side of the house. It's these folks that, maybe they have a bunch of engineers that are hired, but those engineers are often deployed against the primary product that they're building. It's like “Hey, our job is to build this world class x. And that x is really what we want to be spending all of our time on.” However, to run the business, we need all these other things. We need a CRM. We need an invoicing tool. We need email marketing. We need project management. We need all these other things, and our engineers are not often helping make that stuff work better together.
Engineers are focused on the really hard problem of actually delivering a product to the end customers. And so that running of the business side of things often is where the operations folks start to come in and deploy a no code stack and make things more efficient, make it where every salesperson is a little better at their job, make it so that this thing that used to take all day or all week happens instantly.
UX designers have the biggest opportunity, because they are able to bridge this gap of: I designed it, but now you have to go send someone else to build it or send this design to someone else to build it. They're able to close that loop and almost start more comprehensive design businesses or design practices by having access to these no code tools. There's so much similarity between how a no code software tool works and how design software tools work that I find the designers pick it up really fast.
For the developers, I think it’s a great thing for them. They won’t be wasting their time on projects that don’t work. People should have more conviction around the thing they're trying to build before they speak to the developer. Also 25% of our community are developers who see no-code as a way to quickly launch & validate their own ideas.
For designers, they can actually build things rather than just saying how it should look. They don’t have to convince developers to build things anymore.
For developers, I believe it's going to allow them to focus on building core technology that moves the needle and kind of freeing themselves. A lot of times when I was an engineer, I would want to create products or I knew the business owner would have to come back. So in order to do that, developers have to think through problems as much bigger or on a greater scale with better granularity. I believe it will make the software that they create much better.
For designers, I believe it's going to allow designers to focus more on the content itself versus the aesthetics and layout. So instead of trying to figure out how to mix and match puzzle pieces, I'm more interested in now as a designer on creating what the actual puzzle looks like versus trying to make it all fit together within that platform constraints.
I believe project managers and product owners are always the person juggling priorities, figuring out how to allocate resources to have as much of the core platforms done in a no-code way that will allow them to focus on prioritizing features and builds that help move top line and bottom line, not just kind of the, “Hey, we got to stay afloat type of initiatives.”
I think that the thing that I've always talked about with developers is that developers really like building functionality that's reusable, and general purpose, and can be used for a lot of different things. So most developers that I know who are really skilled, they would prefer to write a general purpose component that can be reused somewhere, or an open source library or something like that, as opposed to writing this one off thing that will only ever be used here once. I think really leveraging developer skill sets to build reusable functionality that can then plug in and be applied on top of something like Adalo, that provides the baseline standard functionality, is really the best of both worlds.
For designers, there's going to be somewhat of a shift where the lines are blurring between what the initial design phases — like the design phase all the way through the prototype, all the way through the development with developers, to production. If what I was describing with the components really becomes a reality, then design systems combined with no-code tools will mean that designers can actually build the product to a basic extent, and then plug in the things developers are building.
For PMs, they’ll no longer have to ask permission, they can just go build something themselves and then say, hey, designer help me fix this thing. Rather than having to go through the traditional channel of — I want to build a product, I need to get a designer on board, get a developer on board, get my boss to authorize this project. They can just go build it themselves in a weekend and then show it. That's gonna totally transform how fast organizations can move because often one of the things that slows people down most is just dependencies within an organization and resource availability.
I know a lot of people in these roles might start by asking: "Am I going to lose my job because of these platforms". I don't think so — no-code platforms are coming about because there's such a shortage of software engineers and designers and product managers — and everyone wants to build. I dont think these roles will go away — I think people in these roles will always be necessary to build something truly great, but they may not be needed to build something basic. The future of no code is empowering developers and designers to focus on the things they're good at and not worry about the things that are not worth their time.
Further — what you actually get with the no-code world is true collaboration, allowing teams to skip so much of the "queuing up of work" work — and just do the work themselves directly. In most software companies, 98% of the people in the organization are just queuing up work for engineers to complete. For example, if you're doing design work, you end up creating stories and specs, and it just goes into a tracker for an engineer to implement. That's so inefficient — why not just implement the design changes yourself? True collaboration means building together. I think no-code and low-code tools enable all of us to actually work together.
In terms of developers, I think about this as expediting everything and no-code, in a lot of ways, is the bootstrap of trying to get something done. It doesn't necessarily mean that it's going to be your final product that you're doing. But it's going to be so much freaking faster to get that structure out there that you're going to be able to play more, do more, and maybe try that thing that would have otherwise taken a really long time to learn.
With designers, I think that no-code has been an incredibly empowering movement for them. Where like, for instance, myself, I come from a design background and I loved being able to make these like beautifully comprehensive designs on my computer, but they didn't breathe. There's something a little bit special about seeing how those movements, how the actual interactions play, and it kind of sucks sometimes to have this thing and not be able to fully communicate it or be kind of left behind when you're trying to get that to come to life. So I think no-code tools have really made designers supercharged when it comes to being able to animate a lot of the stuff that they're doing, make them live, create websites, web apps, marketplaces; there are so many things they've done.
With PMs, or non-technical members on teams, it has totally opened up not only in more ways for them to be able to bring MVPs to life, get their hands dirty on things, but also build empathy towards other people on their team. I personally find that by diving into no-code tools, I've actually learned more about the logic and expectations and complexities behind what I'm asking for, which has made me, I believe, more empathetic as a leader but also in terms how I manage or expect what can be accomplished in the scope.
The PM that obviously needs something from the dev or the designer might be able to check off a number of the to-dos on their own. Any of the folks that aren't technically supposed to be doing those changes could be doing those changes.
[Ben] I think this really depends on the leadership from space to space. I think there are a lot of developers who see the advantage there. [I’ll hear things like] “I just want you to know, I found Webflow, and oh my gosh, like what it's done for me, instead of having to spend all this time working on micro interactions, I can actually jump back to what's happening on the back end and spend more time there.”
It's the same for designers and PMs too. For a designer to not just show you a Figma or Sketch mockup, but to actually show you, ‘look at what this micro interaction looks like,’ or ‘look how this flows,’ like, you can actually click through this app and go through the whole app flow. I just think it is going to help people all around developers, designers, PMs, I think it plays a really big role. I can already see it doing that. And I think it's only going to continue to do those sorts of things.