The Future of No-Code Platforms for Product Teams

Charles Caldwell, Thomas Shaw, Catherine Cornell at UXDX EMEA. Video: https://youtu.be/0EJMMPuRs5k

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

Introductions

[00:00:00] Catherine: All right, hi Thomas, hi Charles. Thank you so much for joining us.

[00:00:04] Tom: Good to be here.

[00:00:07] Catherine: Nice. I guess we can start. Do you mind introducing yourselves a little bit more and telling us how you interact with no code and low code in your day to day?

[00:00:13] Charles: Tom, why don't you go first? I've got to change my background to catch up with you here, so why don't you go first on introductions.

[00:00:21] Tom: Okay, cool, thanks very much. It's great to be here. My name is Tom Shaw. I've been working in tech for about 20 years now, and in those 20 years I've been building tools for developers and for QA folks. Over the past 20 years there's been this evolution of tools, of who's using them and how they're being used. I work in gaming. I've worked for companies like Activision and Riot Games, and I'm working for Digit Games at the moment. I'm a big fan of what no code does, the fact that it can really democratize the tooling, which is something we haven't really seen in the past. So I'm really big into the future of no code, and I'm really interested to see where it goes.

[00:01:04] Charles: And I'm Charles Caldwell. I lead product at Logi Analytics. I've been banging around in the analytics world for probably about 20 years, with a focus on helping human beings make better decisions using data. Now what I do is deliver a platform that helps product teams get analytic feature sets embedded into their applications, with a focus on making that as low code as possible, of course supported by APIs, so that teams can get it embedded and customized and automated. Analytics specifically is another area where democratization has been an important trend, and we're constantly asking the question: how do we help citizen analysts and citizen developers participate in understanding information, generating insights and taking action on that insight?

Benefits of low code and no code

[00:02:00] Catherine: Okay, so we just touched on the democratization aspect. What are some other benefits, maybe to the business, that using low code and no code can give? Charles, do you want to go first?

[00:02:12] Charles: Yeah, sure, I'll jump in on this. Probably the first thing I'll jump in on is that I'm not big on this big monster we call "the business." We are the business. Find me someone in an organization who is not the business. I think actually that is one of the main values. We now start to bring a set of tooling to those folks that we often call the business, where they can start to communicate in a language that both they understand and we understand. They can get their hands on solutioning in a way that's productive for them in solving problems, but also we technical folks can recognize those solutions as working code, and that is the gold standard in agile development: working code over anything else.

[00:03:02] We can take those, maybe they're prototypes, maybe they're MVPs, there's different models for how we collaborate, but we can take what is basically a first iteration and, as needed, extend and augment it using higher code where needed. For me it's really around collaboration between teams that have very different skill sets and very different sets of expertise, and it does help us gel as the business, the organization, with a common goal.

[00:03:40] Tom: One of the real benefits that we've seen at Digit Games is that no-code solutions also lower the barrier to entry. Whenever we have new folks joining the company, we don't require senior-level engineers to perform tasks such as rolling out the infrastructure or rolling out new game worlds, because we use no-code solutions. From day one we could bring an intern into Digit, and on day one they're going to create new game worlds and they can deploy to production. That barrier to entry that used to be there has just disappeared, because we have these no-code solutions.

Building in a safety net

[00:04:20] Catherine: That's so exciting, the idea that an intern can come in and hit the ground running and deploy into production very quickly. One question I do hear a lot around no code is how do you bring the safety checks that you have in a standard development process, the peer review, QA, into a no-code environment? How do you build in a safety net there? Tom, do you want to go first?

[00:04:49] Tom: Yeah, sure. We build tools that anybody can use, so we build them in layers, like an onion. From day one you can go in and use a handful of tools that we provide, and then, based on the work you need to do, you can drill down and do more complex tasks, riskier tasks, maybe like rolling out to production, for example. We just control that through permissions. The tools themselves are fairly basic, but we decide what can be performed by whom, using role-based access, or having user accounts locked down through GitLab, which is where we drive all our automation through. We build the tools to be as accessible as possible, but then we lock down the access in different ways.

[00:05:32] Charles: Yeah, that integration into the CI/CD process, I think, is really important. Reinventing different processes just because the tool set looks a little bit different is, I think, a mistake some organizations will fall into, versus falling back, as Tom is doing, on best practices. It doesn't matter what the tool set is per se. We know how to deploy code. We know how to manage risk around that. We already have standards for risky changes versus things that are safe, and for how we let different folks play in the sandbox, with code reviews or no-code reviews, UX reviews, acceptance testing.

[00:06:18] The only trick there, and it's really not a trick, we've got frameworks for these too, is helping the participants understand what their responsibilities are and what the expectations are as they're working with the tool sets. And again, bringing them into the team. Like everything else, it becomes a team sport, it becomes collaborative, and those folks generally feel supported, not controlled, when you do it right. It's not a negative, it's a positive. It gives them confidence. They will take more risks, which at the end of the day is what we want all of our teams doing: innovating and taking risks, just the appropriate risks, so that we're getting the right results.

Designing for personas

[00:07:02] Catherine: Charles, I know that you actually make a low-code, no-code product. When you're actually going in and designing it, how do you think about the roles that are built into your product, where to put caps and limits on certain roles, and where to give more freedom to others?

[00:07:23] Charles: Yeah, for this audience this won't be a surprising answer. It's all about focusing in on personas. Who are these folks, what are their goals, and what skills, capabilities and preferences do they bring to the table for solving those goals? And then how do we give them the most usable experience? It really comes down to having some discipline around saying, "I'm only going to put a certain amount of cognitive load on a given persona, so much complexity," and that generally means cutting off some capability. There's no hard answer here. It really does come down to what this person is trying to accomplish and what's appropriate for their skills and abilities.

[00:08:16] Then you also want to look at the ecosystem. I think the thing to stress here is that low code, no code isn't really just about low code, no code. It's about existing in an overall ecosystem. The snarky thing that I'll say is that somebody who does assembly language thinks C++ is low code, and somebody who does C++ thinks JavaScript is low code. So what is this thing that we call low code, no code? It's just another layer of abstraction. Imagining where the handoffs are between the teams and how the collaboration works is also important, because that's where you say, "I'm not really limiting this person. What I'm doing is deciding what's most appropriate for them, and then where is the handoff to the next persona, and what does that persona look like?" That's where maybe I increase the cognitive load, or change the cognitive load a little bit, or the complexity, or the tasks. That's really how I think about it: one, not in isolation, and two, no surprise, it's all about the persona definition.

Managing risk: the Facebook outage

[00:09:18] Catherine: We actually had a question come in for Tom. The Facebook outage is being blamed on a commit that automatically went through without human oversight. How do you try to mitigate risks like this without having to resort to people needing to be in every server room everywhere all the time?

[00:09:36] Tom: Yeah, that's a really tough question. It's just about having good practices in place. We do use "plots" [?] quite heavily at Digit, and there always is a certain amount of risk. Something can slip through quite easily. It's about trying to reduce that blast radius, so that if a bad change does get out, you know what the blast radius is and you know how to roll back. It just sounds like with the Facebook outage the blast radius was so huge that they hadn't prepared for such a big downtime event. But yeah, just best practices: make sure that the right peer reviews are being done, automated checks are in place, and if you have to have somebody ticking a box at the end of the day for a big change to go through, then that's the way it has to be for some changes, unfortunately.

[00:10:25] Charles: I was going to say, I think balance of risk here is important too. I know Facebook probably lost a billion dollars, but I doubt anybody died because Facebook was out. We all want to be perfect as teams, but it does come down to balance of risk versus innovation, because there is a straight trade-off there. Maybe somebody wants to argue against me, and I'd be interested in that conversation, but there is a straight trade-off between control and innovation and risk-taking. This happened at AWS with the Netflix outage a few years back. It happens. I think the real question is: does the value of the drive to innovation outweigh some of the mistakes and the downtime? Looking at both of those organizations, we'd all have to argue yes. The short-term stock price took a hit, but long term there's no question that the drive to innovation has balanced the risk.

Onboarding and leveling up users

[00:11:28] Catherine: I'd love to jump back to our persona conversation. Something that I'd like to hear from both of you: when you're thinking about your personas, are you baking in an educational journey, of how maybe an intern comes in on day one and has the lowest level of responsibility, and over time levels up within your tool to become a power user? Tom, do you want to take this one first?

[00:11:55] Tom: Oh yeah, sure. Something that we've been using quite heavily is Slack workflows, and these are really powerful. We have non-technical folks at Digit, and they just put together these really powerful workflows. We use that to generate a story or a journey for our new hires whenever they come in. They start up a workflow, it walks them through all the tools, it gives them working examples, and it basically lets them level up their knowledge in the first week at Digit. By the end of the first week they understand why this tool exists, how to use it, and how to use it safely.

[00:12:29] At the end of the day we can also measure the onboarding process. We can see how long it took folks to perform certain tasks within the onboarding, and it's something that we can review at the end of each sprint and ask, can we improve this? Whereas before, the onboarding was fairly ad hoc and different for every team, now that we have it inside a workflow we can track it much better. It's just been awesome. We've got some really good feedback from new hires. They love that they just walk through it like a story or a game or a journey, so we've got some really positive feedback.

[00:13:04] Charles: Yeah. One of the places that I think we can all learn from is games. One of my principles is that, as much as is possible, a tool or a product should teach you how to use it. In some of the most complex games I've played, in the beginning the game looks like it's about gathering rocks, but by the end of it you've got technology trees and civilizations and economies and negotiation. If you can get your product to do that: a very low entry point, very clear what you're supposed to do, revealed complexity, so complexity is not in your face, but as you need the complexity it reveals itself very easily. These are all ways, I think, you can smooth that learning curve or transition.

[00:13:56] And by the way, to Tom's point, it's not just the product. Things like Slack and other tooling that helps guide people, documentation, that counts. You don't necessarily have to do it all in the tool. But yeah, that is absolutely a concern: you want to smooth onboarding, especially where your product is going out to someone you can't reach out and touch and talk to. It's great for internal efficiency on the team, but also if that product is going out into a deployed mode and you can't necessarily be with that person, it becomes even more important.

Tools for UI prototypes

[00:14:35] Catherine: We had a question come in from Benjamin. He would like to know, what's an example of a no-code platform that most product or engineering teams can use for something like UI prototypes? Are there platforms that we need to purchase, or can we build them ourselves? I can actually give a little insight into this one first, if you guys don't mind. Stash has a homegrown tool that we use for this. We do have some of our web engineers using "Storyboard" [?], but most of the time we use a homegrown tool, on the product side, and then also for our compliance team. Stash is in the fintech space, highly regulated, and our compliance team is a key member of our build process, so they're able to go in and look at things like copy and designs and make sure that we're following the letter of the law.

[00:15:33] Tom: Cool. I don't really have any examples, but typically what I would do is take one day out of my week and call it an evaluation day. I just go into Google and google all the low-code platforms, sign up for a bunch, and within a day I can probably evaluate maybe a dozen. Pick out the really good ones, put together a one-pager and send it around. There are new platforms and new tools coming online every day, so if you do a really quick evaluation, just to narrow them down to the areas and requirements that you have, then from there you can share it around the team and get wider feedback.

[00:16:10] Charles: Yeah, I also think it's important to think about what your goal is, because there are low-code, no-code tools that are very focused on market validation. "I've got an amazing idea, it's the best idea ever." No, it's not. So how quickly can we figure out the "no, it's not," and how do we iterate it? There's a whole set of tools that are for folks who are more on the UX research side or the product management side, to do validation. There's a whole other set of tools that are about how I enable my interns, or my business folks, to participate in a development process that's for production. And as Tom points out, the landscape is really changing all the time. I'd get clear on what problem you're solving with the tool. Don't try to solve all the problems at once. And then hit G2, hit the web, go see what's out there.

Empowering non-technical employees

[00:17:07] Catherine: All right, jumping back in. How can companies that deploy low-code products help empower their non-technical employees, specifically the ones with the business context, to adopt and master no-code, low-code tools? Maybe it's not a new employee, it's someone that's been there for a while. I'm going to continue to pick on compliance. You have a compliance officer, and you've developed something that can help them not have to do stuff as manually. How can you onboard them onto a new tool if they're an embedded employee?

[00:17:44] Charles: Yeah, I would start by finding your champions. Just to give an analogy, maybe it'll work for people: in the analytics space, I always look for the person who's already found pivot tables. Or if you've found the VLOOKUP function, I know I've got you. I can make an analyst out of you. You've got to find those people, and if you can find one or two, that's usually enough. You get them through the learning curve, you get them producing, get some wins. We human beings are social creatures, and that's real: people need to see that somebody's been successful. Then they can help you onboard others, they can support others. You're going to get a ton of value just out of enabling them, because they do have business context and you've been able to ramp them on the tools. There's a lot more there, but that would be my main advice: find your one or two that have a high chance of success, and really invest in partnering with them.

[00:18:52] Tom: Oh yeah, I totally agree. If you can find advocates within the organization, maybe run some workshops to help them get up to speed, show them how it works, show them how they can create new workflows and share them with other teams, and use those folks to spread the knowledge through your organization.

[00:19:11] Something else that we tried: we looked at who was going to be using the end tooling, and instead of bringing them towards the tooling, we tried to move the tooling closer to them. Product managers, for example, spend a lot of their day in spreadsheets and in Jira, so we tried to bring the tooling into their area. We set it up so we could run our tools from a Google Sheet, for example, so they do their spreadsheet work and then just run our tools directly from there, or they can trigger tools using the Jira API. We try to move the tools closer to the end user, and that worked quite well.

[00:19:49] Catherine: Nice, listening to your end user. I love it.

Iterating on tools once they're in place

[00:19:55] Catherine: Tom, you mentioned before, you touched on this process, and I'd love to hear more about it: reviewing the tools you have and seeing where you can iterate and improve on them. It sounded like you were doing it on a sprintly basis.

[00:20:08] Tom: Yeah, we use sprints. We tried to standardize the look and feel of all our tools. If you're using a tool, we've standardized how you get support for the tool, we've standardized how you request new features, how you request fixes. So there's very low mental load to actually working with these tools. It doesn't matter if you're using a tool to work with production, or to work with staging or dev, it all has the same look and feel. Again, we try to reduce the barrier to entry for usage of the tools, but also, if you want to extend the tools or work with us, we've made that as easy as possible too. The developers really love the fact that they can just bring us a new feature request and we can act on it quite quickly.

[00:20:53] Catherine: Yes. Charles, any insight on bettering tools once they're in place?

[00:21:00] Charles: Yeah, it's one of my pet peeves: don't willy-nilly introduce new concepts. Cognitive load. Look and feel is not just about look and feel. It's also about, have I invented whole new concepts here? As much as you can keep the concepts and affordances smooth across contexts, you're going to get more adoption, and it's going to be easier to adapt fast. That's a mistake that I see teams making: they've got a new problem to solve, and they're not reusing perfectly good, already existing concepts that their users have already learned and loved, and that's going to slow the teams down in adopting those new features.

Downsides and risks

[00:21:49] Catherine: We've heard a lot of benefits. I would love to spend the last few minutes we have together discussing maybe the downsides, or some risks we haven't mentioned yet. Charles, do you want to start?

[00:22:01] Charles: Well, I think what folks tend to be worried about is "I'm going to take down Facebook," and I think that's for real. Those risks are real. I think you can definitely work with those risks and mitigate them. One of the key challenges here is you also have to be good at people. As we're pushing tools out to folks who are not used to the tools, and not used to the disciplines associated with the tools, as Tom has said several times in this conversation, you've got to meet them where they're at. Can the interface be in Slack? Can the interface be in Google Sheets? Can I reduce how much of the concept they need to know, so that they can be effective? How much do I adapt to them? Where we don't do that, we're actually making their lives worse and our lives worse, versus making it better.

[00:23:07] Any time we say, "Hey, the tool's the solution," we just need to be careful about that. There's a lot of benefits to low code, no code, and in the rush, that is a place where I see folks sometimes falling down. They say, "Hey, the tool is the solution," and they're not helping the teams onboard, and that's holding them up.

[00:23:32] Tom: I think also having a bit of discipline in place, and some guardrails early on, is quite useful. You get a bit of an adrenaline rush after you've automated your first workflow. If you're new to it, you might create one workflow and it's perfect, so you create another 500. It can proliferate very, very quickly. So it's about putting some guardrails in place, letting folks know, "This is really cool, but this is what it's actually doing in the background. Maybe it's hitting a certain API. If you run this too much, you're going to DDoS your own services." You don't have to go into too much detail, but just let them know what it's using under the hood, so they don't go and abuse it by accident. That's one of the biggest risks I see: folks accidentally taking their own services offline because they're just hammering an API endpoint.

[00:24:20] Catherine: Yeah, you've got to remember to wear your helmet.

What democratization will make possible

[00:24:25] Catherine: We have another question that came in: what do we think will be made available by the democratization of previously hidden things?

[00:24:34] Charles: Well, this is what's cool: who knows? And seriously, I'm not being flippant. If you'd told me that the main competitor to Hollywood and CBS would be a bunch of teenagers we've never met, with their iPhones, who would have ever imagined that? That's called YouTube, TikTok. That is the reality we live in today, and these kinds of technologies really do have amazing transformational power that we can't even anticipate. That is why I think this push, enabling this push, and this idea that there's not "the business." We shouldn't see it that way. We are a team collaborating to try to innovate.

[00:25:17] I tend towards taking risks. Facebook going down for a day is awesome. People have learned some stuff, let me tell you, and we're all going to benefit from the stuff that they've learned, and it really didn't hurt anybody that much, I suspect. If it did, we should take that seriously. But I think this concept of low code, no code, and enabling more people to participate in innovation, especially people who've got the context of interesting problems to solve... It's just hard to know what value will be created. But as a humanist and a technologist, I believe that there absolutely is value there that we just don't anticipate.

[00:26:00] Tom: I think from an organizational perspective, organizations that rely heavily on senior engineers and senior developers, that's going to change a lot in the next decade. It's probably changing already. Teams that have the right tools, accessible tools that increase velocity, will just outmaneuver teams that have senior folks. You could have a team of five interns with the right tools that could be outperforming a team of senior engineers on high-paid salaries. That's where I see no code going. I think we're going to empower a much more junior workforce, and a lot of innovation is going to come in through that. It's going to be very exciting. It's good from a senior perspective as well, because folks need to really up their game and be on top of where they are.

[00:26:48] Charles: Well, they want to focus on more interesting tasks too. There's a lot that, as a senior developer, you don't want to be doing. It's not worth your time.

[00:26:57] Tom: Yeah, exactly. It's pretty exciting. The next five, ten years, it's going to be a real game changer.

[00:27:05] Catherine: Great. We are at the end. Charles, Tom, thank you so much for joining us today.