Owen McGab Enaohwo is the CEO and Co-Founder of SweetProcess, a business process management software that helps management teams and employees easily document procedures, implement processes, and manage tasks.
Chad talks with Owen about taking specific root issues and building software around them, overcoming resistance to the core idea of documenting processes, and the importance of having the freedom and ability to be empowered to make changes to organizational documents that outline how you do your work.
- SweetProcess
- Follow SweetProcess on Twitter, Facebook, or LinkedIn.
- 52 Sample Standard Operating Procedure Templates
- Follow Owen on Twitter or LinkedIn.
- Follow thoughtbot on Twitter or LinkedIn.
Become a Sponsor of Giant Robots!
Transcript:
CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel and with me today is Owen McGab Enaohwo, the CEO and Co-Founder of SweetProcess, a business process management software that helps management teams as well as employees easily document procedures, implement processes, and manage tasks. Owen, thank you so much for joining me.
OWEN: Thanks for having me. I really appreciate you inviting me as a guest on here.
CHAD: I could only return the favor as I recently went on one of the podcasts that you run over at the SweetProcess. I'm happy to have you on the show.
OWEN: Great, great.
CHAD: Let's dive in a little bit to SweetProcess. You know, it's a tool for documenting process. And I'm curious what led you to founding SweetProcess and creating this product?
OWEN: That's a great question. So what happened was SweetProcess was actually founded in, I think, the fourth quarter of 2013. And before then, I had an agency where I would provide entrepreneurs in the U.S., so small to medium-sized business owners, with back-office support, basically, people in the Philippines doing back-office support for them here in the U.S.
And so people had read these books that were very popular at that time, The 4-Hour Workweek, or the World Is Flat. And then suddenly they realize that being able to hire people abroad and outsource work was not limited to only the larger companies like the telecoms and all that that would go and hire like 150 or more people in these countries working at their phone support 24/7 and all that. So these books exposed small business owners to the idea that even they themselves can do it on a smaller scale and outsource a lot of their work. And so that's what I was doing.
But the issues that I ran into was that first of all; they were coming to me with this idea that the moment they hire that immediately the person will hit the ground running and start doing the work magically, not realizing that for that to happen, there needs to have been documentation in place. Because first of all, the person you're hiring is in a different country, different culture and all that. There's that that you have going against you.
But then also, they're not even with you physically where you can say you can teach them by talking to them while they're next to you. So they're in a whole different location. So the more clear your instructions are in terms of having standard operating procedures in front of them, the more easier and quickly they're going to deliver the results you want, and so that was the first thing.
The second thing was they were very busy wearing so many hats. They didn't have time to document these procedures that we needed to do the work for them. So we came up with this strategy where we would meet with our clients at the time online on Zoom, not Zoom; Zoom wasn't the thing at the time. It was...what was it called? Skype.
CHAD: Skype.
OWEN: Yeah. So we would meet with them online, and we'd have recorded sessions with them where they would walk us through what they were doing then record those conversations. And then, someone else on my team would take this conversation and document standard operating procedure step by step from what they told us.
Now, on the backend, the issue we had was to do this documentation and have tools in place so that people can actually have one place where they could go and find all these documents for our clients. It was either we were using enterprise-level tools that were first of all hard to use for my team talk less of the clients. So these tools were not even built for small to medium-sized businesses. Or we were basically hacking to get a bunch of free tools to achieve that purpose of documentation and having one place where people can go find stuff.
So in the back of my mind, I was like, man, there has to be a better tool that does this. And so fast forward, I was invited as a guest on to Mixergy. It's another very popular podcast for tech startups. I don't know if you know of him. His name is Andrew Warner. And so, he has two versions of the podcast. The first version is the one where people go in there and talk about the biography of their business or themselves and how they were able to build a tech startup that sold for millions or whatever.
And then the other version of the podcast was one that was behind a paid subscription where people come on; they're experts, come on there and talk about specific topics like very concrete-sized topics that people are paying him to learn from. So people could come on here to learn about sales, marketing. In my case, I was brought on there to teach the listeners how they can basically document procedures and processes so that you can hand over work and no longer be the bottleneck in their business.
Lo and behold, my co-founder, Jervis, who is a programmer and now my co-founder and CTO for SweetProcess, listened to that course that I did for Mixergy. He reached out to me and said he has an idea he is working on similar to what I was talking about, the whole way of simplifying documentation. And he just had some questions about this idea he had in his head. And being the kind of person I am, open to conversation, I said, "Okay. Let's go ahead. Let's meet."
So we had a conversation. And after our conversation, I was like, "Dude; I'm running into the same issue that you're talking about right now because we do this for our customers. We do the documentation for them. But the tools are not the way they should be. Instead of me just giving you ideas on how to do that, and then you go from here, would you be interested if we go ahead and work together and build this software together and build this as a company together?" And he was excited. He was like, "Okay, let's do it."
And then I said, "Okay, instead of jumping ahead to build the software, one of the things I want to do is avoid a situation where the software ends up being hard to use and feature-bloated like the other software that we are running into right now. Why don't we spend some time having conversations with potential customers to totally understand this problem of documenting procedures and having one place where employees can go to find stuff and how employees can collaborate together to improve stuff?"
So I wanted to really understand the problem by talking to people. So we spent like about a month or so. I spoke to more than 30 different people running different companies just to get the ideas of the problems they were having with this very specific topic. And we came back, we analyzed all the conversations, and we were able to put down a list of root-specific problems that people were having.
Because people will suggest features of what they want, but if you drill down and ask them deeper and deeper like, "Why this?" You know, just going into the problem they have and try to get to the root why behind it, then you will end up having a situation where you find a bunch of specific things that are similar between all the different people you spoke to, but they are not saying the same features.
So we took those specific root issues that we were coming across, and we were able to now go ahead and build our software based on that as opposed to launching a software where at the time with a lot of competitors has not as much features as they had. But we focused on simplicity. We focused on solving the root issues and getting rid of a lot of the complex stuff.
Like, for instance, some of the software were focused on having some kind of feature and technology sets where it was focused on the business consultant or the expert person on the company who's going to come and document stuff. But we said, "No, the owners of the business don't care about that. It's really more about how does this help them. They don't care about the terminologies and all that." So we got rid of all the bloat and all the stuff and just focused on simplicity based on having these conversations that we had with the people that I spoke of earlier and also based on my own experience using these harder-to-use software.
CHAD: Well, I really appreciate and commend that because it's a common pitfall. I'm a big believer in building software for yourself that you really understand and a product that you yourself are going to use. But some founders, when faced with that, they'll be like, "Well, I don't need to talk to anybody. I'm the customer. I know everything that is needed. And let's just do what I know we need to do." So to be in a position where you were able to take a step back from that and talk to some other people and make sure you were on the right track, that's really great.
OWEN: And besides the fact of talking to people to help us streamline and simplify the software, another thing we did was open my eyes to the idea that this problem we're solving basically run across multiple different verticals or industries besides the industry I was in. The industry I was in was basically the outsourcing industry, trying to help people outsource their back-office support.
But I realized that the problem was even people that actually want to use the software for documenting didn't really care so much about outsourcing work. It was more about employees they have internally being able to do work predictably and at the scale they wanted it, delivering results that they wanted, and hence they needed that documentation. So without having these conversations, you don't get to see these things that you didn't know going in.
CHAD: Actually, that touches on one of the things I was wondering about, which is the market for your product is essentially every company in the entire world. [laughter] So, with such a huge potential market, are there things you've identified as who your ideal customers are or what kinds of customers come to SweetProcess on their own, what stage they're at, those kinds of things?
OWEN: Great question. So what we've realized is from the customers who stay 24 months or more with us typically are the much larger companies that have over 20 employees based on the data we have. So what we found is the smaller companies, we encourage them to use SweetProcess because we always want people to start early in the process of documenting procedures.
But what you realize is that these smaller companies...let me backtrack. So the software solves that problem of having documentation in place and collaborating together to improve these documents over time. And that's really because they are trying to make sure that from a production standpoint of delivering the results to their customers, they have all these instructions. And so their employees can carry out those tasks that they cannot automate. Those tasks that need to be done by human beings, employees can carry it out predictably. Now, that's them trying to deliver output to their customers.
When a company is less than five employees or even less than ten employees, they don't have so much issues or worries with production. Their main biggest issue is how to get customers, how to get sales in the first place. So their focus initially is more on okay; let me figure out a system for sales. Let me figure out a system for marketing and all that.
But on the other hand, when you already have 20 or more employees, to a large extent, you have figured out your sales pipeline, your marketing pipeline, and all that. And now you really want to make sure that the people you've hired can hit the ground running and do work predictably and deliver the results you want. So that's why it makes sense that these companies that have more employees tend to be the ones that have the need for the software, for what we do.
CHAD: Who ends up often finding and championing SweetProcess within an organization? Is it typically someone in a leadership position like a CEO?
OWEN: Great question. So it breaks down based on the size of the company. And now I'm giving you all the juice because my competitors are listening to this now.
CHAD: [laughs]
OWEN: But anyway, it is based on the size of the company. It's like if it's between 20 or let's say between 10 to 20-30 employees, most likely it's the CEO who has this pressure that, hey, I need to make sure that employees can go to one single place and find step by step instructions on how to do their work. I need to make sure the onboarding can be done faster. I need to make sure that if anybody leaves this company, we're not scrambling to figure out how work is done. So they start looking for a tool like SweetProcess.
Now, beyond that, let's say 30 to maybe 100 employees, it's now like the CEO, not the CEO but the Chief Operating Officer, someone who the CEO has hired onboard as the person in charge of operations at the company. Now, once we get beyond that 100 to, let's say, 1,000 employee kind of thing, we're now looking at someone that is a level below the COO, the Chief Operating Officer, and those usually are the operations manager.
So that's how it works; it's based on the size of the companies. It's either the CEO that's reaching out to us or the Chief Operating Officer or someone who's an operations manager at the larger companies looking to...and especially with the operations manager thing, it's usually they're trying to bring in SweetProcess to start in their department or whatever and then usually to scale-out besides their department to other parts of the company.
CHAD: How do you reach those people?
OWEN: So you mentioned something that the fact that the problem we solve cuts across the board, different verticals. It's not industry-specific. So that's a good and bad problem to have. Because if you're only selling to a specific industry, all you got to do is basically be everywhere anyone who is in that industry is at, all the podcasts, all the trades, and everything, just basically be there, and that's it.
But because the software we sell cuts across different industries, it's kind of harder to do that. So what we decided to do is focus more on creating content around the problem itself so that when people are looking for how to solve their problem, they're able to find us regardless of the industry they are in.
Mid-Roll Ad:
I wanted to tell you all about something I've been working on quietly for the past year or so, and that's AgencyU. AgencyU is a membership-based program where I work one-on-one with a small group of agency founders and leaders toward their business goals.
We do one-on-one coaching sessions and also monthly group meetings. We start with goal setting, advice, and problem-solving based on my experiences over the last 18 years of running thoughtbot. As we progress as a group, we all get to know each other more. And many of the AgencyU members are now working on client projects together and even referring work to each other.
Whether you're struggling to grow an agency, taking it to the next level and having growing pains, or a solo founder who just needs someone to talk to, in my 18 years of leading and growing thoughtbot, I've seen and learned from a lot of different situations, and I'd be happy to work with you. Learn more and sign up today at thoughtbot.com/agencyu. That's A-G-E-N-C-Y, the letter U.
CHAD: Do you find that there's resistance to the core idea of documenting process?
OWEN: Oh yes. There's resistance in different levels. Sometimes people think it has to be, you know, robotic, and sometimes they think it has to be complicated. Then it's also "I don't have time to handle the documentation." I hope that I also get to share some cheat codes on how to actually do that on this podcast. I don't want to leave the listeners just hearing about the history of the company but also giving them in case they're in that stage in their company how to go about it.
CHAD: Well, that's exactly what I was going to ask you about, so yes.
OWEN: Good, good. So, first of all, if you think about it, you only need to document procedures only at a time when you're trying to document how a task that you do on a repetitive basis, recurring basis. Because if a task is a one-time thing that you're never going to do ever again, well, there's really no need to document it. So we're now left with only recurring tasks. Now, people might just want to get excited and start documenting just because it's based on a recurring task. But I say, no, hold your brakes.
First of all, let's have this conversation with the employees and managers or whatever and say, "I know we've been doing this over and over again. But is this task necessary?" Because it might just be tribal knowledge thing where we've always done this, so let's keep doing it. No. But if you have that critical conversation and say, "Okay, is this very thing that we've always done, is it necessary or not?" If the answer is not necessary, okay, simply and quickly eliminate it. There's no need to start documenting how that task is done. If it's not necessarily, eliminate it.
If it's a situation where you already have procedures or processes in place, and they are already existing, and you're trying to come into a software like SweetProcess, even before you start importing those documents, I want you to take a look at those documents and say, "Are these things documenting tasks that are even necessary in the first place?" And if they are not, eliminate them.
So now, let's say we are at the point where you've eliminated stuff that is not necessary. The recurring task left you have no choice, but you need to do them. Now let's break those two tasks into two categories. The first category is revenue-generating tasks, basically, tasks that bring in money to the company. And the other one is, you know, they're not necessarily revenue-generating, but they're necessary and more of the operation side of things. You need to do them. They don't bring in revenues, per se, but you need to do them to produce whatever stuff that you've promised the customer.
So people might be excited to want to jump in and start documenting the tasks that bring in revenue. But I say don't do that because if you start that and you document those tasks that bring in revenue, you're also going to be tempted to say, "Okay, let me go find employees or new employees or sales whatever to come and start doing those activities that bring in revenue that I just documented." Now you're going to get more people or more customers coming into the chaos that is already in there because there are a lot of bottlenecks.
So I say focus on these bottleneck tasks first. Find the biggest bottleneck that takes the most of your time. Start from there first. And then, once you've documented how that task is done, you find the next biggest bottleneck, you document that, and you move to the next one. Before you know, you've eventually documented all the big bottlenecks in your day and the time of your manager and all that stuff. And you guys are now freeing up time to focus on these nice income-generating activities.
So the next question is okay; I've figured out a big bottleneck task to focus on. How do I document it? Does it have to be an encyclopedia? The answer is no. I want you to do one thing, install that mindset of continuous improvement in your mind, install that mindset of continuous improvement in the mindset of your managers as well as your ground-level employees. Once you have that mindset in place, it basically gives you the permission to say, "Okay, we're going to start from version 1.0 today, which is going to be rudimentary and not have that much in there." But we're telling ourselves since this is continuous improvement, it's going to keep improving as we go.
So the first thing you do is document what I call a minimum viable procedure, which is just a fancy way of saying a procedure that has the title of the procedure and the title of each of the steps. That's the first thing. And the best time to even do such a thing is while you're doing the task itself because at that point, it's highest and best in your memory so it's easy to just, you know, whether you're using a tool like SweetProcess or using whatever tool, that's the best time to actually document that minimum viable procedure. So title of the procedure, title of each of the steps. And that's it.
What do you do next? How do you get more details filled in? First of all, I don't want you to think it's only you that will be responsible for filling in the details. It needs to be a collaborative thing. So get your employees involved, anybody who you've trained verbally on the task before on how to do it. It could be a manager or some ground-level employee who you've trained verbally on how to do the task. Say, "Okay, I just documented this procedure. Here are the steps for the procedure. You've already done the task before. Come and collaborate with me to fill out the details."
So now the employee goes in there and starts step number one, starts entering the details in there. And also, let them know that the details they're going to each step doesn't have to be 100% perfect. It just needs to be enough instructions in there, be it text, be it screenshots, or whatever, that at least someone else can take these details that they've put in there and at least get started. Again, the goal is not to be 100% perfect with the end results of each procedure. At least if someone can take a procedure and get 60% of the way towards the output, that's a good place to be so because, again, we've installed that mindset of continuous improvement.
Besides collaborating together to fill out the details of the document, how do you then continuously improve the document? This is the cheat code there for this one now is anytime an employee is carrying out a task, you need to make sure that they are also looking at that procedure that you guys have built together because a lot of the insight that comes around improving a document comes when they are actually doing the work; it's not from when they are documenting how the work is done. But when they are doing the work is where the aha and all these things comes to them.
So let's say a document or a procedure has ten steps. Now the employee is doing the work, and the procedure is right in front of them. They are now able to say, "Okay, why do we need ten steps for this? I just found a better way. We probably just only need four steps." Now they can now take that input; hopefully, it's a proactive employee that we all want; they can take that input and pass it back to you. And that document can be improved based on that feedback.
Or they might come across some new way that was not even encountered for or discussed in the document, and now that feedback can as well be passed to you so that you can improve that document based on the feedback. But you see how all these things I've talked about, if you don't have the right software in place, it might be a little bit tricky. And that's why when we built SweetProcess, we made sure that it has everything in one place where the documentation side of things and how to collaborate together with the team to document is in one place, as well as the actual aspect of getting work done, which is assigning tasks.
So, for instance, in SweetProcess, you cannot assign a task to someone that is not based...every task you assign to someone must be based on an underlying procedure you've already documented. So when the employee is actually getting the work done, the instruction is right there in front of them as they are getting the work done in real-time. And if they come across any changes or anything, they can pass that back to you, the manager, who you can make changes on their behalf.
Or, if they are the proactive employee, they can literally click a button to edit the underlying procedure and make the changes while giving you the management oversight. So all these insights that I've shared about how to do it regardless of whether you use SweetProcess was based on our initial finding when we had all these conversations, and we put it in together and packaged it into our software.
CHAD: I'm glad that you touch on this idea of continuous improvement, one, because it's one of our core values at thoughtbot is continuous improvement. And I think it's one of the challenges that we have despite it being one of our values. We've been around for 19 years now. We have a very robust internal documentation handbook, procedures, and the way a lot of things are done. And I think it's very easy for someone to show up in that environment and even have all of the best intentions about practicing continuous improvement.
But when so much is already laid out for you, it can become easy to fall into the trap of saying, "Well, the answer to everything is here, and I don't need to worry about improving it because clearly..." I don't know; it just builds up this culture of like, we've got things figured out. And it's easy to just fall into the mindset I think of just blindly following the things there and not actually looking at them critically while you do it.
OWEN: Well, I think that is the wrong way to think about stuff because maybe people are thinking, oh, documenting might make the employees robotic, and maybe they don't have a say in what's going on because maybe the instruction has been passed on to them, and that's it. But the way we want people to think about this and the way we built the software is that it needs to be a collaborative thing where it's not just one person that does it.
So that's why in this software and in our software, we allow even the ground-level employee who has been assigned tasks based on the underlying document they are empowered to literally go in there and click the edit button and make the changes to it, knowing that yes, the manager or the owner of the company still has management oversight to approve the changes.
But then, even deeper than that, from a cultural standpoint, what other way can you have your voice heard in a company than when you have a tangible role in the actual improvement of how the work is done? Because that's what the procedures are, right? Your document procedures for how work is done. Guess who is doing the work? You. And if you have the ability to, and you are empowered to make changes to the documents that outline how you do your work, that is you literally having your voice heard.
On top of that, I think documenting procedures allows you to be more creative. So imagine if you're a manager and there's a specific task you do maybe every three months, and you don't have a document for it. Now, at the time it comes when you need to do this task three months from now, you're going to have to start context switching, remembering okay, how do I do this?
Spending all this time trying to figure out how to do something and then when you figure it out, now you're going to spend time doing it. But imagine if, on the other hand, you had the instructions right there in front of you. You don't have to spend one single minute remembering anything. The instructions are right there in front of you.
You get started on doing the task; what does that allow you to do? First of all, it allows you to get the task done faster, but then it also frees up your mind to start asking yourself the question like, how can I make this be done better? How can I improve this stuff? How can I get rid of some of these steps? That's where the creativity comes in. And you start thinking of new and better ways to get things done.
Because remember, documenting procedures is all about, okay, creating steps and instructions for how those tasks that you cannot automate that will be done by human beings are done the right way. But eventually, they get to certain points wherein parts of the task, you can figure out certain things to automate, and you get rid of the manual aspect of human beings doing it. So this is where this whole creativity comes into the whole thing of documenting. That's the way to think about it.
CHAD: Yeah, that's great. One of the tools, additionally, or techniques that we use a thoughtbot too is there are times where you might have a sense that something isn't quite working right or be improved, or maybe a non-technical person is the one doing the task. And they have a sense that it could be better, but they don't necessarily have the skills to know how to automate it or something like that.
To have people come together in what we call a retrospective format where you're identifying things that might be better or could be improved. You're talking about them and coming up with action items for improving them. It's is a nice forum that we have for talking about maybe the more vague feeling that someone has that something could be better and then coming up with a way to improve it as a team. Is that something that you do at SweetProcess?
OWEN: Well, yeah. So we have a bunch of different tasks that we do. And every now and then, we get to a point where we asked ourselves, is there a way we can automate this so that we don't have to do…? I'll give you an example. Every time...before we automated this when someone signs up for SweetProcess, a lot of our customers come through us creating content that addresses these questions all around documenting and how do you scale the operations of your company and so on and so forth. So a lot of people come through our content.
And as a result of coming through our content, they get into our email automation. We use ActiveCampaign, and they get into our email automation. And before, in the past, before we automated this when someone came in, they get into our email list, and then eventually, they sign up for a trial of our software. And then, we will get this email about it, and we will have to manually go into the tool that we use for our email automation and change their status so that they don't keep getting emails from us as if they were not trial. That became a thing where we were doing too much.
And we said, you know, "Hey, let's get some engineering on this," and basically got API integration built directly with our software so that when someone signs up for trial, it looks to see is this person already in the email list as someone who's not a trial user? Yes. So let's move them in a different...tag them the right tags and put them in a different category so that now they receive a whole bunch of different emails.
But the signal for us to decide that we needed to automate that stuff was doing it manually. Although we had step-by-step instructions on how to do it, it was still taking time. And so we said, "Okay, can we automate this?" And so we got to the level where we automated the stuff, and now it's not a thing that we have to even worry about or have someone do. It's just automated.
CHAD: You have a degree in computer science, right?
OWEN: Yes.
CHAD: Do you wonder or…because I sort of have this theory about myself too because I have a degree in computer science as well. But I'm now still doing some development but in operations as well. And sort of this systemized thinking or systems thinking, do you think it comes from our technical backgrounds, your technical background?
OWEN: I think you can say part of it was enhanced by this, but I've always had this mindset of when I see things like maybe if I go to a company and I see how customer service is happening or how they produce things, I've always been fascinated with how things move around within the different parts of a company to end up with the outcome that I'm trying to achieve.
Like, people might be having fun watching music videos, but I don't mind sitting down and watching a manufacturing plant like a video showing how they...because I've always been fascinated with how things come together to make the output. And so then you throw in the computer science degree there, and that also enhances that thinking. So I think from my own standpoint, it was just me personally always wanting to know the ingredients that you put together to make something happen. I'm always fascinated by stuff like that. So I'm always thinking systems-wise.
CHAD: That's great. If folks want to get in touch with you or try out SweetProcess, where are the different places that they can do that?
OWEN: So obviously, they can go to sweetprocess.com. And you'll be welcome to try out a free 14-day trial of the software. But one of the things I want to leave with you as a gift is I've shared with you how to go about documenting procedures. But you might also want to have templates in front of you so that you're not starting from a blank screen. You have a bunch of…
What I'm offering is about 52 standard operating procedure templates that you can download right after this interview. You can go to sweetprocess.com/giantrobots, and you'll be able to download it. And that's sweet like candy, process like process, forward slash giant robots just like the name of this podcast or sweetprocess.com/giantrobots. And you'll be able to get a PDF that contains 52 standard operating procedures, and from there, you can tweak it and build upon the templates.
CHAD: That's awesome. I'll make sure that we link that in the notes, which will be right in people's podcast player too.
OWEN: Thanks for having me on the call. I really appreciate it.
CHAD: Yeah, if folks want to get in touch with you, where are the places where they might do that?
OWEN: owen@sweetprocess.com, very easy.
CHAD: Awesome. Thank you so much for joining me. You can subscribe to the show and find notes for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter at @cpytel.
This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening, and see you next time.
ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.
Support Giant Robots Smashing Into Other Giant Robots