Do you have a consulting company and are looking at pivoting to a software company? If so, this episode is for you. Steli and Hiten talk about their own experiences building their software companies. They share their own motivation behind creating software and why they achieved success in what they created. Tune in to hear what it takes to build software that is exceptional and why you NEED to please your existing clients in the meantime.
Time Stamped Show Notes:
- 00:18 – Today’s episode is about making that transition from a consulting company to a startup or software company
- 00:51 – Steli is receiving a lot of emails from people who want to transform their consulting and service business into a software or product business
- 01:21 – Steli met someone who wanted to pivot from being an online information business to as SaaS business
- 02:13 – There was an intern at Close.io who built an online product
- 02:53 – He now has a vibrant community behind him, his customers enjoy the product, and he is making money
- 03:12 – His number one goal for the next year is to build a software product
- 03:34 – Steli says he is uncomfortable when the goal is to go from services to software because he thinks this desire to shift may not come from a right place
- 04:28 – It takes a lot of time to build a brand and it will also take time to build a software product
- 05:14 – Betting the business on a new thing is risky and there are many potential traps
- 05:27 – It is more practical to learn or build small software products rather than pivot the whole business without having any experience
- 06:15 – Hiten did it this way: they had cash flow coming in and they wanted to get out of consulting. They had a general customer segment of marketers and designers and they evaluated which of their products benefited them the most
- 06:48 – They tried 12 different products before Crazy Egg was launched in 2005
- 07:33 – Hiten looked for their lead engineer and partner for Crazy Egg
- 08:01 – It was easier to create a software company back then than it is today because there is enough software out there for every need
- 09:01 – Hiten did a time and budget-box approach
- 09:18 – Steli says they did not make the conscious choice to move from services to a product business
- 09:47 – They knew two things – the 2 co-founders were technical and Steli would be the first sales person they would rent out to
- 10:38 – They figured things out on the way and organically created great sales software
- 11:32 – Steli says there was also a lot of luck involved – they had the right team at the right time and he did not advise people to copy what they did
- 12:09 – Steli says the problem is that other companies rush the process of becoming a software business and put too much weight on it this transition
- 13:06 – The team can get sloppy with their own business and clients because they become to occupied with building the software product itself
- 13:51 – Hiten says to make it a resource allocation project; you have to be smart about how you transition
- 14:10 – Hiten never had a timeline, they just allocated resources to the software because they wanted to learn from it.
- 15:08 – Hiten’s tip: Keep doing what you are doing to make more money and use that money to fund whatever opportunities you are looking for in software
- 16:33 – 37 Signals built Base Camp and Ruby on Rails out of their own need
- 17:43 – They were their own internal customers at first
- 18:42 – Hiten says the mistake that consulting and service companies make is creating software that is not geared towards their own customers and target market
- 19:17 – If you have follow up questions, email them at firstname.lastname@example.org and email@example.com
3 Key Points:
- If you want to transition from consulting to software, do not make it your number one goal; instead, allocate your resources accordingly.
- Be your own customer—what are your needs and what product can you create to meet that need?
- Keep doing what you’re already doing to earn the money that can fund the other opportunities that come your way.
Hey everybody, this is Steli Efti.
And this is Hiten Shah. On today’s episode of The Startup Chat, we’re gonna talk about something that I would consider sort of a kind of business pivot, a business switch, that both you and I have done … Steli and I have done, which is basically going from a consulting company to startup or a software company. I know something probably inspired this, this is definitely a topic Steli brought up.
And so, Steli, what do you got?
Yeah, so, here’s why I wanted to talk about this. There’s two reasons. One is how consistently I’m getting emails from people that are considering transforming their consulting business, or their services business, into a software or product business, and how they see and view the switch we made from Elastic sales to Close.io as something they would want to kind of copy or emulate, so they reach out to ask for advice. But also because recently I was … I mentioned this in a prior episode, I was on a boat traveling on a bunch of islands with a bunch of founders, and one of them was talking to me about his desire to move from a online information business to a SaaS business. I gave him a few pieces of advice that I’ve observed with a bunch of other people, and I thought that that advice might be valuable to others. And I was not sure what your take would be on that advice that I gave. I was like, “Hiten might have a different opinion, a different take of this,” so anytime that I think that I want to talk to you about this to see what you could come up with or how you could broaden my perspective on things. So, I’ll start with that specific founder conversation, and let’s kind of break that down together and then we might want to go more generic later on. So, here’s the case study, if you want, so, there’s a young kid, he was an intern at Close before. I love that kid. I think he’s gonna go places, he’s gonna do big things. A year ago he started building an online product with the idea to build it a big audience and then later use that audience to build a software business on top of it. So, first, create an audience and then sell a product to that audience. The way that he approaches this is that he basically came up with like an information product to sell to the audience and to build that audience. Now, he’s done really, really well in the past few months and he has a very vibrant community going on. He has a product that people enjoy and get value from, and he’s making money. He’s making a good chunk of money. He’s learned a ton. He’s doing some really cool shit, right? He was talking to me about his goals for next year, and he was telling me how his number one goal for next year was … He’s like, “Now that the … I have the audience, I’m making some money, this thing is working, and now, next year, I need to build a software product and launch it. That’s gonna be the big pivot that I’m planning to do.” He asked me for my advice on how to do it and if that’s a good goal and all that, and I always get scared, well, I get uncomfortable when people … When the goal is to go from services to software because it seems like that … That is a very significant change. There’s a number of reasons why I’m very skeptical of that — rattle through these real quick. Number one: it doesn’t come from the right place in my mind in the sense that … You have customers, they have problems. If those problems can be solved better with software, and you have a good idea for a software product, cool. Go that direction. But, if their problems are solved better with information products, then do information products. Don’t just decide that you want to do a software product and then you … I feel like that creates a bias that will make you see opportunities where there aren’t any. That’s number one. The other thing is that it takes a lot of time to build an audience, build a brand, to have a machine that’s working, something that’s working. It took him awhile to get to this place. If he’s built a law of expertise in the area that he’s in now, it’s gonna take a good amount of time to build expertise on building software products. If he knows he wants to do that, I think it’s a good idea to start building software products; maybe even, quote, unquote, “throw-away software products,” so he’s not as attached to them, and he sees it more as a learning experience than betting his company’s future on it — on the first one — because I feel like it’s gonna take a while probably for him to get good at building software products, right? He doesn’t have experience in it, he doesn’t have a track record in it, and … But now he has customers. He has users. He’s gonna have to hire people — he has a business, and betting the business on just switching tomorrow to a software and then betting that that’s the whole thing, it’s just such a risky proposition to me, and there’s so many potential traps that he could step into. I’d rather have him say, “Next year, I’m gonna learn more about software products and I’m gonna build some small ones while I’m still growing my business,” than saying, “I’m gonna transition and pivot my entire business to a software product, but I have no experience in building software products.” I could go on and on, but I’ll just stop here because these two are my top two reasons for why I’m always skeptical when somebody tells me they made the decision and they have to switch, and they have to switch within a given timeline. What’s your reaction to this? I’m super curious.
Yeah, I think there’s two ways to do it, and the funny thing is the way you did it, at least my perception of it, and the way that I did it is vastly different.
Even the way 37signals did it I think is closer to, at least from what they’ve said before, Basecamp now. But 37signals, and they are a consulting company, they did it very similar to how I did. So, what we did … I’ll start with that ’cause then we can talk about what you did. What we did was … We knew we had cashflow coming in and it was highly profitable, and we also knew we wanted to get out of consulting. We also knew that we had a general customer segment we really liked — marketers, designers — that whole category back in the day. We decided to build a bunch of stuff, and we literally, at that time, were throwing spaghetti at the wall and seeing what stuck using some kind of calculative bets. One of them was not very calculated, so we lost a million dollars on it, but that’s okay. It is what it is — learned a ton on that one. So, we did about 12 different products before we found Crazy Egg and launched it in ’05. That was the one that starting taking off. I can tell you all the things we did right there, but what we always did is treat our software projects like yet another client, so we were able to chunk time and money and resources around it in a way that I don’t see many people doing. It was one of like a bunch of different customers, and we treated our own internal product in that way, which is also, I think, what 37signals said they did. I thought that was brilliant. We did it kind of naturally ’cause we were like, “Oh … Gotta still make money while we’re building this thing and learning software.” At that time, my girlfriend and I, we weren’t engineers. I actually went on the Ruby on Rails site and contacted everybody I knew in order to find the current engineer … Lead, head engineer and partner that we have at Crazy Egg also built Kissmetrics for a while and then came back to Crazy Egg, and yeah — We just had to go on a mission. As you were saying, it takes time to learn how to build software even if you are an engineer or if you’re not. It just takes to build the business, customer support, sales, and like … I would say right now it even takes longer than it used to just because the traction in the business requires a different kind of effort than back in the day. Back in the day you could pop something out. If it was unique enough, or useful enough, people would use it ’cause there just wasn’t that much software. Today, there’s a software for everything and every little niche. I don’t want to say everything, but mostly, right?
There’s enough software out there. There’s probably a million x more than when I was out back then — maybe 10,000 times more, if I want to be nice. So, that’s how we did it. From my understanding of your process, it seemed like what you folks did is you had a customer segment, which was sales … People in sales teams, and you were actually building the software, sort of using it internally, and that was your sort of customer development, customer research, prototyping, MVP-ing — which was your own team that you were hiring using it. Maybe the story isn’t that polished, but I feel like that was more of your approach. I don’t know how you dedicated time and all that, but that feels a lot different than how we did it, which was literally try a bunch of stuff, make sure it’s sort of really, really time boxed … Not time boxed in the way of like, “Oh, we’re gonna flip to a software company by now,” but more time boxed and budget boxed on, “We’re gonna spend this much money, release it, see what happens, put our efforts behind it in a very structured way,” is basically how we did it, but we tried a lot of things while I think you did one thing and then pivoted. But please share.
Yeah, that’s absolutely correct. We kind of … We stumbled into this transition. We did not make the conscious choice at any point that we wanted to leave the services business and move into a product business — that decision we never made. From day one, we had decided, okay, we’re gonna build this massive sales force …you know, sales organization in the cloud, and we’re gonna be renting out all these salespeople to do all these B2B subs around the world, and we knew two things. One was that I had two co-founders that were technical, so we had some technical resources that we wanted to put in use. And then two: we knew that I would be the first salesperson that we would rent out, and I hated with a passion all the sales software that existed out there, so it was very easy for us to get to the conclusion that, “You know what, let’s just build our own sales software,” and the idea was that the software would enable the services business to scale. That was the whole intention, and it would enable me not to kill myself, right? That was the whole thinking behind it. There was no really grand vision for the product, there was no clarity on what better sales software look like. We were fairly thoughtless on this, to be honest, with very little strategy sprinkled on top of our thoughtlessness. And so we … I started cold-calling companies, and they all wanted to use the service. And then we had to hire a bunch of salespeople, and we were just going along and figuring things out as we moved forward. We just had two engineers building software in the middle of all these salespeople, and it took nine months or so of development internally until we finally really arrived at … And organically arrived at a point of view and a real philosophy on what is good sales software and why have we built something that’s so different from what everybody else has built. It took another few months until we had our customers telling us that they wanted to purchase the software not just the services. So, we kind of just … And then we started thinking, “Huh, maybe the future of the business is gonna be the software, not the services business.” We kind of very organically stumbled into this, and it was not as strategic, and that’s why I tell a lot of people that we might not be a good example … I’m pretty sure we’re not the greatest example in the world to try to copy because this condition happened very naturally and there was a lot of luck involved. We were the … In hindsight, we were the right team at the right time and a lot of things really worked out really well for us, but yeah, I would not advise anybody to copy it, and I would never pretend that there was any real high-level strategy of how to transition. But what I have seen is I’ve seen a bunch of people that have the services business and they get, in my own mind, they get too committed on, “I need to be a software business tomorrow,” and then they forcefully convince themselves that they have a software idea that’s good, and they don’t validate it as much as they should, and they don’t have real customer development around it as much as they should, and they don’t have real development experience or product management experience. Then they put way too many resources on this product, they bet the future of the company on it, and then they launch and it doesn’t work out or it doesn’t succeed and then they’re fucked because they neglected their services business and they bet all their resources and money on their services business on the software thing, and they didn’t take an incremental approach. They didn’t take a smart approach. I’ve never heard the strategy they do described, which makes a ton of sense for me, which was the, “Let’s just treat the software product as if it was a client,” so I look resources accordingly and smartly. I’ve seen a lot of other examples where they just bet way too many resources — they start getting sloppy with their customers, their clients, because the entire team get so passionate about the software product they’re building that the clients now are just a pain in the ass, or the work they have to do for them is just like an afterthought, so they start doing shitty work there. They start to over commit on the software thing and then it doesn’t work out, and they’re in a really bad place. That’s kind of a trap that I … Maybe along those lines, are there any other kind of mistakes that you’ve noticed of companies when they try to make that transition or missteps that services business take or consulting businesses take when they try to transition to a software product business that we could highlight so that, hopefully, people that listen can avoid these?
Yeah, I think what founders forget is it’s a resource allocation problem, and it’s something where you want to be really smart about how you transition. So, setting a deadline or a timeline on the transition doesn’t work unless you had a set of experiments with software that you can do for that timeline. I never have a timeline, and the reason for that is when we were running our companies, our consulting company, we just knew we wanted to invest and allocate profit towards building software ’cause one: we knew could learn anything we wanted to, for sure. We knew that we were really good at bringing in revenue. We also knew that spending the money on software and subscription businesses is what we wanted to do because that was appealing to us at the time — still is, honestly, just because of the recurring revenue stream , and where the world was and is. You have to find what your fundamentals are, and tell yourself and your team the proper story. I think that is super important. For me, I think … This is a little bit of a theme for me in terms of the things I think about, but if you step back and just think about your strategy, even if it’s for a half-day or a couple hours, you’ll come up with a good way to keep doing what you’re doing so you can bring in money, and use that money to go fund whatever opportunities you’re looking at in software. That’s the biggest piece of advice I have, which is many folks just think that consulting sucks, services businesses suck, they don’t want to do it anymore, but they’re really good at it. Because most people, if they’re making some money and have even the opportunity to transition to a software business, there’s something great going on in the services side, whether it’s companies really excited about working with them, them being able to close deals — there’s always problems in services businesses, but at the end of the day that’s usually where there’s a scenario of positivity, a scenario where something’s working, and you just want the next step, and you really believe the next step is software. What I actually wish that we would have done is that we would have taken our customers and started building software that worked for all of them instead of, sort of, doing the spaghetti model ’cause I don’t think if we were to do it today the spaghetti model would be what I would do. I would do something closer to what you did, which is pick an opportunity that was really easy to learn about, really easy to do customer development about, and ideally something our internal team was using where we thought and hoped and believed that we could flip it out and take it out of just us using it, and slowly start letting customers or our target market start using it even if our target market was other agencies. If you think about 37signals, they built Basecamp and a bunch of other tools. Basecamp was built out of a need that they had. Ruby on Rails, which is their opensource programming language, which you could argue, and it’s not arguable, it’s true, is another product of theirs that they still commit to and keep building on, was also out of a need that they saw that a different demographic they had, or really valued, believed in, which was engineers, right?
And software people. So, that was what Ruby on Rails was created out of, and Basecamp was mostly created out of the fact that they were an agency — they didn’t feel like there was a good tool for agencies to manage clients, right, and manage the work. That ended up being something that they felt like could be extrapolated to any company, right? But if you still look at Basecamp, because there’s all these other tools now — Trello, Asana, and the long list — Basecamp is still mostly used by folks who have agency, client kind of relationships in that model. I’m hypothesizing, but when you think about anyone that uses Basecamp, they’re mostly those type of folks, and less folks are using Basecamp to do product management in-house, for example, just ’cause there’s so many other alternatives. So, that core of what they’ve built, and who they created it for, still lasted for a longtime, but they were the internal customer first. So, I kind of like that approach, and I favor it because when you’re the internal customer and you really believe there’s other customers out there, it’s just much easier to invest in that software and realize even what value it’s bringing to your own business, so you end up having this visceral value proposition. I really feel that about you and what you did because what you did was you’re building a product in a very crowded market. It’s probably at the top three market online in terms of software, you would say, right?
Dude, how did you do that, right? That’s another episode, but it’s like, how did you do that? I have the answer — you were your own customer in the beginning, and you had customers who were using your product, maybe they didn’t know it, you know what I mean?
And that’s so cool. So, for me, I am looking at the “grass is greener” here and saying, “Oh, you should do it that way,” but I’m also looking at where the world is today. And one mistake I see consulting companies and services businesses make is they build software not for their customer, not for the demographic they’re already really good at attracting, not for their current target market ’cause for some reason they confuse the services they’re doing with not liking their target customer or the market they’re currently in when it’s actually furthest from the truth. You must be doing it ’cause there’s something you like about it otherwise you wouldn’t want to keep going to these client meetings, trust me. So, there’s something there that I would probably plug into if I’m a consulting company looking to build software.
I love it. I don’t think I have anything to add to it, so we’ll wrap this episode up on this note — super powerful stuff. If somebody who is listening here has a services or a consulting business is currently transitioning, has transitioned, or is thinking about transitioning, and you have some follow-up questions, just make sure to ping us. We always love to hear from you. Just shoot us an email at firstname.lastname@example.org and email@example.com — I think this is it from us for this episode. We’ll hear from you very soon.