Yaw Aning (Malomo): Services Founder vs. SaaS Founder

Yaw Aning: The best early stage products, they don't do everything. They aren't trying to be everything for everyone. They do one thing and they do it extremely well.

Blake Bartlett: Welcome to BUILD, the podcast from OpenView. I'm your host, Blake Bartlett, and the show features conversations with software founders, leaders, and investors. Each episode unpacks a new key insight on how to build your company and navigate the fast-changing world of software startups. Today, we're talking founding stories, and we all know the typical founding story of two folks in a garage in Silicon Valley building the next big thing and surviving off of ramen and Red Bull. But that story, it's more of a legend or a fable than real life. And sure, Steve Jobs and Wos started Apple that way, but that was the mid 1970s. What about today? How are startup ideas hatched and built in the 21st century? Good questions, and thankfully our guest in this episode is Yaw Aning, co-founder and CEO of Malomo, and his founding story is much more common these days in the modern era. Before becoming a SaaS founder, Yaw was a services founder. He ran an agency that built tons of websites and apps for clients and like many agencies and consultancies, he started seeing a consistent pain point from his clients. In fact, it was so consistent that he decided to solve the problem once and for all with a SaaS product rather than reinventing the wheel in a serial fashion or client after client. And many other SaaS startups have a similar founding story. With that said, it's now time to ditch the old fable and hear the real-life story of Malomo and how other services founders can follow in their footsteps. All that and more on this episode of BUILD, so let's dive in with Yaw Aning.

Blake Bartlett: Well, Yaw, thank you so much for joining us here on the BUILD Podcast. It's great to have you on the show.

Yaw Aning: Yeah. Very fun to be here. Been a longtime listener, so it's a bit surreal to kind of be on the podcast as a guest, so thanks for having me.

Blake Bartlett: Today we're going to be talking about your journey as a founder. Initially, as an agency founder, and then the things that you saw that led you to become a SaaS founder, and some of the lessons learned along the way, so that's probably a really good place to start. You did run an agency for seven-plus years, and you were building apps and websites for many different types of clients, many entrepreneurs and founders included, and I guess in seeing so many opportunities, what did you learn? Best practices for building products as founders.

Yaw Aning: Yeah. There were so many.

Yaw Aning: We built about 100 different web and SaaS products over the seven-year period, and really grateful that we had that opportunity, because the learnings were immense. I try to sit back and reflect on that period and I felt like I could condense the learnings, the major learnings into kind of three buckets that when we were working with our clients we saw them running into time and time again. The first big mistake that we saw founders make was that they tried to build their seven-year vision today. We joke that those were the founders that were trying to boil the ocean, like it's super easy to just see all the possibilities when you're a founder, all the opportunities. We'd have founders that would come to us with 10-page specs on features that they wanted to build and we always knew right then that we're pretty sure that this founder is not going to be successful. Because it's hard to narrow down your focus. You often think nobody will want your product unless it has all the bells and whistles in it, but the best early stage products, they don't do everything. They aren't trying to be everything for everyone. You have to be able to separate the vision of where you're trying to go with the realities of where you are today, and if you can't take the most important part of that seven- year vision and boil it down into something you can deliver in three to six months, you're going to have a really hard time building anything that matters. So, if you can't separate those two things, we saw it often led to the second problem we saw a lot, which is like founders would often target the right customers but at the wrong time in the company's trajectory. So, as an entrepreneur, you always sort of have this dream list of customers in the back of your mind. You position your product to serve that audience from day one. And I think that's a huge mistake. There's a concept called a technology adoption curve which I'm sure, Blake, you know very well. Basically, it's like this mental model for how new technology is adopted in a market, and the way that this happens is there are groups of people that adopt a product in a particular order, right? You've got the innovators, the early adopters, the early majority, late majority, and laggards. And all these groups have very different needs and expectations when it comes to adopting new tech. Most of the time, the entrepreneurs, we all want the types of customers that would fall in the early or late majority category, and so the best customers to do that with are not mainstream customers, but they're rather the innovators and early adopters. The best way to think about this is your earliest customers have to be as innovative as you are. These customers don't care that the product's fully featured. They just see the same future that you see and give you the best insights on what that future looks like, so they'll oftentimes, they'll also forgive your early missteps, like the feature gaps you have. They will give you the benefit of the doubt because they really are focused on also seeing that vision come to life, and so those people, they view themselves as trend setters and they love to discover new technology and evangelize that tech to their communities. It's really important to find those early customers, because you kind of have to stage out your progress to match that technology adoption cycle. The early innovators, they'll signal to the early adopters what's new and upcoming and hot, and then those early adopters will signal to the late adopters again, and so on and so forth. It's really important to target the right customer at the right stage you are at the company. And then the last major problem we saw was that once you identified the one thing that you should focus on and be 10X better at, and who the right first customer set is, you have a tendency to start building the product immediately. And this was probably the most fatal mistake we saw. Customers don't buy software. They buy solutions to problems. We actively pay for problems to go away. I think that's a really subtle mindset shift that founders need to have. It's like you have an idea, knee- jerk reaction, go build the idea. When really, you should take the opposite approach of try to build nothing for as long as humanly possible, which sounds really weird, but the companies that we worked with that just killed it came to us having started their businesses basically as consulting firms. They were already working with a customer base to solve a problem through a service that they were offering and they came to us looking to build technology to automate the things that they were currently doing manually. And they succeeded because they understood the problem so deeply that their customers faced because they were the ones actively solving the problem on behalf of their customers. And so, we often joked at our agency like there are two types of entrepreneurs we worked with. The ones that believed that they didn't need their own product to get to revenue and the ones that were wrong. And so, the ways that we saw those customers making that work is they'd actually use two or three off- the- shelf products, kind of stitch them together, and then that's how they managed the delivery of their service, and it was like a super potent and effective strategy that we saw working. Yeah. Those are the three things that we often saw our customers really struggle with early on.

Blake Bartlett: In those first two, kind of what I hear in that as a common theme is... Well, certainly as a starting point, entrepreneurs and founders are ambitious. Kind of comes with the territory. But it's also very easy to be too ambitious, especially maybe for a first- time founder. And so, to be sensitive to your eyes being bigger than your stomach and wanting to sort of, like you said, you have this vision and you want to build it from day one, and feeling the need to build it all to completion before you want to get it in front of customers, and that will... You're biting off too much and then it's also going to take way too long. Figuring out the right starting point and then being patient is incredibly important.

Yaw Aning: Yeah. Patience, man. It's really hard. Because you can see it. You can see the future. You're rushing to there. And it's so hard to just take a step back and methodically work through the stages to get there.

Blake Bartlett: Exactly. And I think it also applies to the second bucket that you were talking about, which is being realistic about who is ready to adopt your product today. I think similar to the idea of being overly ambitious, you could be overly ambitious and say, " Well, this is a product that's experienced by the largest organizations in the world, so I am going to sell seven- figure deals to blue chip Fortune 500 customers. And that's where I'm going to start."

Yaw Aning: Yeah.

Blake Bartlett: Pretty hard to start there, right? And so, being realistic about all right, well, what's the starting product we're going to build? And don't build a seven- year vision. Build a solution to a starting problem and build it for those who are most apt and ready to adopt today, the early adopters, but knowing specifically who your early adopters are, not just going after these vague, " Somewhere out there there's an early adopter, I know it."

Yaw Aning: Yeah. It's funny. There's a common joke in the enterprise, like nobody ever gets fired for buying Salesforce, right? Because Salesforce is the juggernaut. It's a proven product in the market. When people adopt technology, they're putting a little bit of personal stake in advocating for that solution inside their organization, and if it's wrong, they themselves lose personal credibility. And so, that late adopter group, like you said, who it's like you want to go after those customers because that's who you want, but they need to see other people succeeding and believe in that success and the results before they can really effectively sell that vision and solution inside the organization. And so, it is really important to have that. Even if that's your future goal, you've got to like... Hey, there are people that we have to prove that this works for before we get to these bigger massive deals that we ultimately feel like is our real long- term target customer in the market.

Blake Bartlett: Let's bring it into the very practical. For your own journey, when you did this transition from agency founder, building product for others, and then got to a point where you said, " All right, now I'm going to build my own thing," how did some of these lessons influence the decisions you made and how you went about building Malomo?

Yaw Aning: Yeah, so for super quick context, Malomo, we are a shipment tracking platform in the eCommerce space. So, in order for our product to work, we have to connect into a ton of large scale software systems in our eCommerce merchant's tech stack, so we have to connect into their order platforms, like Shopify, to pull in customer order data. We have to connect into the global delivery network in UPS, and FedEx, and international carriers, to get all of the tracking information. We've got to connect into their marketing platforms so that they can craft and trigger the right messaging about where their order is in transit. And so, all of those were super large scale integrations that we'd have to build, and that's super daunting. It's like in order to just get to market we've got to build a ton of tech and we didn't really know if people would one, if they would use it, like if this was a problem that people had. And even if they used it, would they be willing to pay us for it? We really wanted to prove those two things out before we went down the path of spending any energy on this, and so we did what all of our successful clients did, was we launched an agency. So, it was a post- purchase agency, like we kept the focus pretty broad. We were going to help our customers understand how to drive down support tickets related to people asking about where their order is. And so, we approached a couple of friendlies that we knew in the space, and a couple people that we didn't know, and kind of said, " Hey, we've got this agency." We had worked with several other Shopify merchants in the ecosystem, so we had a general understanding of the nomenclature, how to position and target these customers, what to talk about, and so we positioned this as a service offering. And again, when we went to these customers, we had no software to actually trigger these emails out to customers, so we basically, we told our earliest customers, " Hey, we have this software. We're going to provide this service offering to design out this post- purchase experience and then we've got this plugin that you can plug into your store and it will automatically send all this data to trigger these emails out." What we ended up doing was so convoluted, it was... So, our customers thought there was software there. What we did was we asked for our customers' login info. We said, " We need the login info to make these connections happen." We ultimately would log into their Shopify store. When a new order would come in, we'd grab all that information about the customer, the line items, we would log all that data into a spreadsheet. We'd also grab the tracking number and then we'd go to USPS. com, plug in the tracking number, and look at tracking. And if the status, we'd check it like three or four times a day. If the status changed, we would log that new status into the spreadsheet, and then we asked for login information to the marketing platform, and we would go in and for each customer when the status changed, we'd trigger an email one by one for every single customer. Did this for hundreds of orders, right? We were sending out thousands of emails manually. It was one of the worst summers of our lives just doing all this stuff. But it helped us prove several things. So, the spreadsheet at that point, that was the product. We had no software. The spreadsheet was the product. We identified two really interesting insights. The one was that the open rates on these emails were 60, 70, 80%. When you look a normal marketing email in eCommerce, you get a 20% open rate. And the click- through rates were like 20, 30%, when normal click- through rate's like 2%. So, it's like, " Oh my gosh. These customers, consumers, are super engaged. They actually really want to know where their order is." And every single email that we sent, if it was like, " Hey, it's just shipped. There's been a problem. We're aware of it. It should be at your doorstep tomorrow." Every single one got opened along that value chain and we saw the customer support tickets just drop dramatically, just a nosedive, and so it's like, " Oh yeah, proactive notification. Seems so simple, but proactive notification on delivery matters a ton to consumers." And it actually has a tangible impact on the businesses that we serve. And in the eCommerce space, the second insight was everybody is highly focused on growth, and so could we actually harness this engagement to drive a secondary growth lever for the merchant? Which is obviously cross- sell and upsell during this period of time. And that unlocked this insane growth for the merchant. It was like we were seeing repeat purchase rates in the 2% to 4%, and that revenue was highly profitable, right? It's your existing customers. You don't have to market to them to acquire them again. And so, it was just amazing for us to see and that's the data that we used to prove, " Oh my gosh, yes. There's a real value proposition. We're solving a real need. Let's go out and build the technology to make this work." So, that was great for us. Those insights. While we had a hunch that those problems existed, we wouldn't have really known and uncovered the second insight to build from had we not launched this agency model to solve this problem for our customers.

Blake Bartlett: So, you basically started a software company without starting a software company.

Yaw Aning: Yes.

Blake Bartlett: To the outside world it looked like a software company, but then behind the website, behind the scenes, it was just a bunch of you kind of putting things into a spreadsheet, sending emails manually and everything, and so it was very, very manual. Very service based. But that kind of ties back to one of the lessons you mentioned at the beginning, which is making sure not to build something before you've validated the solution. I think that it's definitely easy and almost everybody validates the problem, either through their own experience, I lived the problem, I had the problem, or I saw the problem everywhere, or maybe I did research and I interviewed people and they all told me about the problem. They all diagnosed the problem the same way. Great, but you need to do the same research for the solution that you're building, as well, and you need to do the same validation to make sure you actually hit what the market needs. And so, the way that you were doing it was through this manual service offering. Let's make sure before we build a line of code. Let's make sure that this solution to this problem is actually valuable to the end customer, the person that bought the thing from the merchant, and to the merchant, to the service people, the support people, et cetera. And it sounds like you saw the validation in spades.

Yaw Aning: Yeah. Yeah. You're exactly right. Yeah. And it's like having come from the agency space, we had the resources. We had a bench of designers, developers, product managers, and so it would have been really easy for us to start building, but we really... We saw how much failure people had by doing that starting off, and so we forced ourselves to just be like, " Hey, let's just launch this agency. We'll have it separate from the core agency and that's going to be the thing that we go out and use to validate the market." And the other thing that came to mind as you were saying that, software is super rigid. It works exactly how you design it to work, so if you're wrong even slightly you've lost time, you've lost money, potentially lost trust with your customer. It can be costly to go back and rebuild. When you provide a service, you can adjust instantly on the fly, so you can try multiple different solutions and see the different angles of how they impact results. With one solution you might have uncovered like, " Oh, this works," and then left it at that. But if you didn't employ a second solution that actually worked even better, it's hard for you to pivot. Offering the service helped us just throw a bunch of things at the wall to see what would work and then pick even the best one out of the things that were working.

Blake Bartlett: And then also discover new things like you saw with the repeat purchase rate, as well.

Yaw Aning: Yes. Exactly. You could almost get to a better solution even before you build anything, which also has a massive impact on go to market.

Blake Bartlett: Yeah. And if you had been too wedded to your own solution and if you had built the solution from the beginning, you wouldn't have maybe seen this opportunity. One, you might have built the solution wrong. But two, you might have also not seen the potential for additional upsell and all of the incremental value that you can provide to clients. So, that's huge.

Yaw Aning: Yes. Yeah.

Blake Bartlett: I'm curious the next step. So, you validated the solution through the service offering, kind of software company to the outside world, really behind the scenes a lot of manual effort, and so then you said, " All right. Now it's time to actually build this out and make it a real software company through and through." How does one do that? Especially for folks that are listening right now that might be in the shoes that you were in in the past, where they know services because they run an agency, or a consultancy, or maybe they're a freelancer, and so what they default to is this high touch manual service offering. How do you actually productize and not just kind of fall into hold habits and build a services business by accident all over again?

Yaw Aning: Yeah. It is a super delicate balance. Yeah, and service agencies be servicing. It is like you said, like hold habits die hard. It's so hard to not just get in the motion and just stay on the motion. So, I think there's maybe two ways to do this. The first way, we actually did both of these, but the first way you can think about it is separate the product team from the agency. You almost have to have this walled garden between the two entities. Even if the service part of the business continues going on, you can't have your entire team commingled, still focusing on both, because it'll inevitably be a distraction to both sides of the business. It takes intense focus to go from zero to one on a product. And so, we did that. We just had one engineer from our agency focused on product development and they never saw anything around the consulting part of the business, never got pulled into billable hours, and that's one of the hardest things in the agency. Every person on your team is a cost center and hopefully a profit center. And so, when you knock one resource out it's like it has an impact to your bottom line, so it's super easy to just pull that resource back into the consulting part of the business. We were really diligent about separating the two out. And you have to be really disciplined, right? We always knew we were going to launch a product from the very start. We just didn't have an idea that we were super passionate about and saw a unique market opportunity, so we just stockpiled cash from the agency until we found the thing, and then it was like, " Okay, that stockpiled cash is going to fund this single engineer working on the product." That definitely worked, but the second thing that we did which was actually... Once we got on the path of building the product, it's going to sound super weird, but we actually fired our consulting clients, and the reason being you set this precedent with them where they'll always view you as the consultant, so they're always going to be asking you for more consulting services or one- off projects that are tangential to the thing that you're working on. It very subtly leads you away from the core offering that your product is targeted at. And you don't recognize it right away and then all of a sudden you wake up one day and you're like, "What the inaudible? How are we doing all these weird random things?" And so, we just decided let's just shut down the consulting arm completely, like once we validated the idea with those customers we switched back into product development mode. And I know lots of folks that kept consulting, like I've talked with a lot of agencies about this. They kept consulting through the transition and it can work. It just takes a long time, because that walled off engineer will slowly get pulled into the one- off projects of the consulting agency too. So, we were just like, " Let's just fire these customers." Be like, " Hey, we're really sorry. We cannot continue to support you along this dimension. We'll happily help you find a replacement." And that's super painful to do because you've built up a lot of trust with those customers, but we felt like it was necessarily in order to hit the end goal.

Blake Bartlett: Yeah. Drawing that really hard line in the sand versus trying to kind of straddle and say, " We'll keep our consulting clients happy and we'll keep our product customers happy," is just too divided and there's too many competing priorities. If you've gotten the solution validated, then committing to it, so much so that we're shutting down the old thing, we're changing the name, and we're not doing services any more full stop.

Yaw Aning: Yes. Yeah, exactly. You burn all the bridges. You're out there. You have to make it work.

Blake Bartlett: No going back now. Well, technically there always is going back. If it doesn't work, you can just set up a new agency.

Yaw Aning: That is very true.

Blake Bartlett: The downside is very, very low at the end of the day.

Yaw Aning: Yeah.

Blake Bartlett: Yeah, that makes sense. But okay, moving to I think a very important question, and we'll kind of wrap with it, but there still is a role for services in a SaaS company.

Yaw Aning: 100%.

Blake Bartlett: Bringing it full circle, what is that role? What have you kept and brought over from your agency days? What have you left behind for good?

Yaw Aning: Yeah. Yeah, I love this question. So, there are a couple ways that we look at services today, and again, we have to be very... The DNA of the company is kind of like services because of our backgrounds, so we have to actively try hard not to go down this path of being completely service business. So, the couple ways we look at this. The first way we look at services is like can we guarantee our customers success? So, your customers, do they not have enough time or resources to use or adopt your product? If not, then provide services and kind of become an extension of their team, so even if they aren't using your product actively, you are using your product on their behalf and they see the end result and success of it. If they see the end result and success, it's likely they'll commit more resources internally to optimizing that, and so services is just a way to activate and get success on that initial customer. That kind of goes back to the point we talked about earlier, which is customers don't buy products. They buy solutions to their problems and services is a way to achieve that. The second way we look at services is a way to fill in feature gaps that are on the short- term road map. So, it's like, " Hey, oh man, we see that there's real value here, but naturally it's going to take some product resources to build this feature. Can we provide this same outcome through services until the product team can catch up?" If they're not on the short- term road map, we have to be very diligent about we really shouldn't build this. Or sorry, we really shouldn't provide a service for this if we're not sure we're actually going to build an automation for it. The third is we ask ourselves if the services are repeatable. So, is it something that we can do for a customer month after month? If so, then we might want to turn it into a productized service, and then if enough people opt into that productized offering, it's a good signal that you should actually turn that into a feature too. Because technically, it's funny. SaaS is software as a service, like as a service is the important thing. Software is only the delivery mechanism. And so, if you are providing a service repeatably that customers are paying for, good signal that it's a feature they'll continue to pay for.

Blake Bartlett: One thing that really resonated with that that you were saying is that services can be a sort of bridge to future product and I really like that a lot. It's almost kind of bringing back the first idea of create a services version of the thing you want to build. You can keep doing that with individual features and incremental features, but knowing is it actually a bridge to something. Are we going there already anyway? If so, you can kind of get there faster and validate along the way with services. But it's also you need to be cautious that it is a bridge to somewhere, not a bridge to nowhere, right?

Yaw Aning: Yeah. Yep.

Blake Bartlett: It can't just become this appendage onto your core business that like, " Well, we got this core business, but we also have these random services on the side that we're doing. I don't really know why. I guess they're paying us money for it." But that ends up creating the distraction rather than the productive path to where you want to get to.

Yaw Aning: Yeah. My man, preach. It is so easy to follow the money with services. So, so easy. And it's hard too because big customers will ask you for a lot. They will want a lot. And you will want to give it to them because you want to keep the ARR in the business. But there be dragons there. It's really hard to not get caught into this place you don't want to be. And yeah, you hit on the last point I was going to make, which is exactly that. You should use them to get insights on your future product vision. Can we learn something new from the services that will give us some unique competitive advantage in the future? Or can you use them to test out early ideas for the product? That's how we try to look at service. It's not perfect. We have these guardrails and we try to abide by them, and it definitely is hard to say no to specific things and say yes to others, but that's how we try to view the lens through.

Blake Bartlett: Well, this has been a great conversation. I think understanding the journey from agency founder to SaaS founder and how services can be a superpower and can be a strength and can be an enabler to building software is incredibly powerful, incredibly compelling. Yaw, thank you so much for joining us here on the BUILD Podcast today.

Yaw Aning: Yeah. Thanks a ton. I had a lot of fun. This was great.

Blake Bartlett: Thanks for checking out BUILD. If you enjoyed the conversation today, make sure to subscribe on your favorite podcast platform and leave us a review so that others can find the show, as well.