Four Lessons Learned From Bootstrapping Products

Four Lessons Learned From Bootstrapping Products

Fix bugs faster! Log Collection Made Easy

Almost every software consulting company feels the desire to dabble with products at some point – the potential of revenue that’s not tied to people billing is just too great (we recently wrote about our own reasons for building products). But making the leap from consulting to products is often hard, if not impossible. At Mobile Jazz we understand. In our very first year of existence, we built a product that didn’t take off, mainly because we didn’t push hard enough on marketing. We tried again three years ago, and now have a successful product for mobile app logging in the cloud called Bugfender. And we’ve recently released two new products: Enterprise Push Technology and Localname.

Based on our successes and failures, we wanted to share some things we’ve learned that might be helpful to other consulting companies considering the plunge into products. And we particularly wanted to share our experience as developers building products because we feel that’s a common situation for consulting companies and it presents some unique challenges.

One thing to say first is that none of the lessons on this list are about getting the product implementation right. That’s because most products fail because they don’t fit a market need or hit at the wrong time, not because the team failed technically. This is especially true for successful consulting companies, where the team already has a track record of successfully building software. So, while you might be tempted to focus almost entirely on building the product, our experience agrees completely with the available studies: you should worry as much or more about what to build and how to sell it.

The Mobile Jazz product family, including our free open source projects.

Be Prepared To Learn How to Market a Product

I was once part of a company that built 4 products with a 4 person team over about 3-4 years, only to scrap all 4 products when they didn’t sell well. That’s a lot of money with no return! It wasn’t the technology, features, or pricing that killed the products. It was the marketing. Something that is all too common with products launched by consulting companies.

Now, this company was not run by idiots. It was a successful consulting company at this point. And around the same time, they made investments in consulting sales and marketing that paid off well. They even eventually succeeded with products, but it was after a very long, hard process of learning how to market them.

The problem was that marketing and selling a product was completely different than selling consulting. It doesn’t seem like there should be such a huge difference, but there is. Especially for a bootstrapped consulting company, where most of the consulting sales come from word-of-mouth and the sales to new customers is often done by the founders of the company. Making an in-person consulting pitch that is driven by the personality of a likable, knowledgeable, and trustworthy founder is hard to translate into a broader sales and marketing campaign (though content marketing is one way that can work).

Aleix our co-founder at Mobcon EU in Bulgaria. A conference we sponsored and a marketing strategy that didn’t work for us.

In comparison, product sales are often very hands-off. For a software-as-service (SaaS) product, all of the marketing and sales might happen without direct interaction at all. Even for products with relatively complex, hands-on sales, the lead generation is very often comparatively hands-off marketing.

So how can you avoid making costly mistakes when learning to sell products? How can you build the highly automated, repeatable sales and marketing process that can help grow a product business?

Of course, there isn’t a magic solution because every product and target market is different. Not to mention it’s incredibly difficult to predict how people are going to react to a marketing campaign.

The best approach is to do lots of experiments and clearly track the results so that you can see what works. I know that this isn’t particularly satisfying advice in a lot of ways. For many of us with a technical background, it’s frustrating that there isn’t a clear, rational plan to follow. But it’s crucial to know that there isn’t going to be a simple, easy to follow path to successful sales and marketing for a product.

You have to plan to spend a significant amount of time – but not necessarily a lot of money – experimenting. If you make the experiments small, try lots of creative options, and don’t get fixated on what “should work” according to the experts you should be able to find the right approach on a modest budget.

If you don’t have any marketing experience, there is a wealth of advice available. But I would suggest that you treat ideas from marketing experts – whether general online advice or paid consulting – as a great source of what to try, but not a prediction for what should work for your product. Even the best, most experienced marketers can’t know what will ultimately work for your product. And the best marketers will tell you the same thing and emphasize the value of experimentation.

For Bugfender, we had hoped that we would be able to simply place some ads on Facebook and Google and be done with it (what “should work”). Facebook and Google make billions of dollars for a reason, right? But the result was not good. After that we tried sponsoring conferences, developer newsletters, and podcasts. Still nothing.

Writing thorough, comprehensive blog posts is a strategy that works for us to promote Bugfender.

Eventually, we landed on in-depth, insightful blog posts (content marketing), answering questions on StackOverflow and Quora, and comments on Hacker News and Reddit. A marketing plan that surprised us, but has helped us build a very large user base and convert enough to paying customers to have a successful product.

A few things to take away from our experience.

First, everything we tried was an approach that works for many products, it was just that some of it was not right for our product and customers. If you think of sales and marketing as a means of reaching the people that need what you are building, then it makes sense that you need to find the place – through experimentation – that those people hang out and are looking for a solution. If people are actively searching for what your products does and you can identify the right keywords, Google search ads can be awesome. But for us, our potential customers were often thinking about or talking about their problems in a more general way. That made content that was more educational, like blog posts, comments, and answers to questions, a better fit.

Second was that the approaches that we landed on were things that we had to do ourselves. The insight and expertise that we could show in the blog posts, answers, and comments helped convince our target customers – skeptical software developers – in a way that content written by non-experts or ads never could. Of course, that means we have to continue to be involved and engaged. But the upside is that it highlights one of our biggest assets. Bugfender was built by us to solve problems that we have. We have a unique insight into the needs of app developers. Marketing in this way highlights that advantage.

Bugfender’s co-founders in the Black Forest, Germany to set up the company.

The final point is related to the second. We are doing the marketing ourselves rather than using a marketing agency. That saves money, of course, but with a product, if you can spend 2x the money on marketing to get 10x the profits then you should definitely spend the money. But my conclusion after working with many marketing agencies is that they are seldom helpful marketing new products. It’s not that most aren’t good at their jobs, it’s just that they aren’t focused on marketing new products from previously unknown companies. Why would they be when there are plenty of big companies wanting to spend lots of money against relatively loose goals? Most marketing agencies just aren’t optimized to handle the relatively small amount of money and very specific and measurable goals associated with marketing new products (just like most software consulting companies aren’t optimized to build prototypes of products for almost no money for bootstrapped product startups!). If you can find that marketing agency, that’s great. But just be aware that’s not what most do.

Building an internal team to do product marketing (or just learning to do it yourself) also has a lot of other benefits. It’s much easier to keep the marketing aligned with the overall product strategy. And not just aligned. If you do it well, the marketing can influence the direction you take the product. Seeing what marketing messages resonate is a great way to understand what your customers want. The expertise that you gain can also be applied to additional products or marketing for your consulting. Becoming a great marketing, like becoming a great developer, is not easy and requires constant learning. But the payoff over your career can be huge.

What Are 1000 Apps Doing to Reduce Their Bugs to Zero?

Down to Zero is a practical guide to solving bugs. Our team has been developing mobile apps for over a decade and we'd like to share some tips we've picked up along the way.

Get the Ebook for Free

Down to Zero Ebook

Decide on Market Positioning, Business Model, and Pricing Early

While sometimes it feels like startups these days just randomly pick a business model out of one hat and an industry out of another to build the next Uber for Something or Blue Apron for Other Thing, business models and pricing often have an enormous impact on your success. It’s easy to focus on what a product will do – especially for technical people – while putting off thinking about the details of how you are going to make money with the product. But it’s critical to figure out how you are going to position yourself in the market, your business model, and how much to charge.

Just to stick with Uber to illustrate a bit of what I mean. When Uber first started it was to provide “black car” service to customers in a more convenient way. So it was positioned as a premium service and the pricing was higher than cabs to match that positioning. As they evolved, they took on cabs directly with their Uber X offering (which allows drivers to use less elegant cars) and adjusted pricing accordingly. If they had not made that change in market positioning they would not have grown nearly as fast. But even as their positioning changed, their basic business model – easy payments through their app – remained the same and is a core part of their appeal. An Uber that required cash or was only sold as a subscription service seems laughable. As Uber illustrates, all the variables around market positioning, pricing, and business models and how you change them or keep them the same have an impact on how customers perceive the product and, ultimately, whether they will pay for it.

Localname provides a secure tunnel to a developer’s local machine allowing them to easily share their work.

For Mobile Jazz we have three products and each of them has a different business model. Not because we like complexity, but because the success of each product requires something different.

For Bugfender we use a “freemium” model, where you can use the service for free up to a point, but after that you need to become a paying customer. For that product, which is incredibly easy for a developer to get started with, that model works great. They try us for free, we help them solve hard problems, and convincing them to become paying customers is much easier.

For our Enterprise Push Technology, we provide a easy-to-use push notification service that’s incredibly scalable and hosted within your infrastructure so that you don’t have to hand over sensitive data to 3rd party providers. That product is priced higher than Bugfender, reflecting it’s critical infrastructure role, complex support requirements, and our willingness to allow deep customization. Because our Enterprise Push Technology customers typically have complex requirements, integration requires more investment, and ongoing support is more complex we charge both an initial setup fee and a yearly subscription per-server.

We could use either of these business models and pricing strategy with both apps. But instead, we’ve tailored the approach based on the product and what will help it succeed in the market.

It’s important to think about these issues early on, as they can have a big impact on development. For example, one security product I worked on was developed with the assumption that there was a market for a cheaper, more flexible version of a high-end security product. But once development was complete, we discovered that the pricing of the alternative was actually much lower than we thought and, while the flexibility that we offered was nice, the lower security we offered killed too many deals. So we were left with a product that was positioned and priced poorly and un-doing those mistakes would require more investment in product development. Not a good place to be.

Making the right choices about these things is tough. You need to know your competition well, distance yourself from the product you want to build so you can view it as a potential customer might, and get the opinions of real potential customers. But be warned: people aren’t always great at predicting what they will do. So even if you have lots of people that say that they will pay you X for a product, you can’t be certain they will until they actually make the purchase. So be prepared to make changes after release. Just remember, though, that it is often easier to lower the price than it is to raise it, so consider starting with a higher price first.

Stick With What You Know

Remember how I mentioned that most companies fail because the product that they build doesn’t match a market need? This is true both in the big picture of what the product does and in the details of individual features. A great way to avoid these mistakes is to build something to solve a problem that you already know incredibly well.

An in-app screenshot from Bugfender, our remote logger and console.

One way a lot of consulting companies do this is by developing the core of a product as a by-product of their consulting work. Bugfender started as an internal tool we built as we were building mobile apps for clients. We needed a way to collect logs from mobile apps and didn’t like the products that were in the marketplace. So we built Bugfender for ourselves. As we rolled it out into production we realized that a lot of other companies in our position likely had the same needs.

By using this strategy we removed a lot of risk. We knew that the product served a need. We also knew how it fit within the market for similar tools because we had first tried to find someone else’s product to buy. That meant that we had a very clear vision for the product and who the potential customers likely were.

We also had a working prototype, removing a lot of technical risk. And while we have to continue to invest money in maintaining the product, that work is related to our consulting work and benefits it.

With this strategy, you do have to be careful to ensure that the product you build is generalized so that it’s useful to a wide variety of people. Products are funny things. While they have to meet a need, they need to meet a need for a broad range of people to make sense economically. This is different than a lot of things that get built as consulting contracts. Internal tools for big companies are often intentionally tailored to a specific environment or workflow. Big companies can often also afford to build things that seem like products but are really more for marketing. I once met a guy that built a fully animated, interactive burger building app for a big, national fast-food chain. I feel pretty confident that there was not a huge market demand for virtual burger building and that a simple menu would have sufficed. But I’m sure the app screenshots looked great in the marketing material.

Mobile Jazz team members setting up a remote office in Cape Town.

Decide What Success Looks Like First

Building a product is an investment – it takes time away from billable work at the very least. If you start a marketing or sales campaign or the product is not pure software that you can build yourself, it can require a cash investment. And if you’re not careful you can end up investing a lot in a product that you’ll never get back out.

The trouble seldom starts at the beginning. You make a plan about how long the product will take to build and then create a beautiful spreadsheet projecting customer growth (“all we have to do is get .05% of the billion people is this very broad demographic to buy our product and we’ll be rich!”). Given that you can put together a basic budget.

Then reality sets in. Maybe the product takes longer to build than you hoped. Or marketing isn’t as effective at generating leads as you helped. Or you discover that the sales cycle for the industry you are targeting is really long and cyclical in a way that you weren’t aware of.

The most dangerous place to be is when you have a product out in the marketplace that has some sales – so it’s not an obvious flop – but it’s still not self-sustaining. So you have to make a monthly decision about whether to keep investing or to kill the product off. It’s really easy to think one more feature will enable you to close deals, or just a little more money into marketing will generate the traffic that you need.

That’s the situation we faced with Bugfender:

“We wanted to see if there was demand for our product, so at first we offered it out completely free of charge. Finally, in September 2015, we rolled out paid subscription tiers and our first paying customers soon followed.

Fast-forward one year, to June 2016: 17 paying customers. A Monthly Recurring Revenue (MRR) just below €1000/month. A burn rate of €3-5k a month spent on development, data storage, customer support, and marketing expenses.

It doesn’t take an accountant to work out that we were talking about killing the product.”

In situations like this, it’s important to do some rationale business planning and financial modeling (and work hard to not let sunk costs influence your decision making).

The safest approach is to decide how big your investment will be before you start work on the product. This is exactly like walking into a casino with only the cash you are willing to lose. If you leave your wallet with a debit card at home, there is simply no way to spend too much. It’s easier to decide before you start what the stopping point should be because, in the middle of the product gamble, your emotions or the allure of hitting the jackpot might tempt to you make too big a bet (ok – I promise no more gambling metaphors after this).

But I would suggest that most services companies don’t go into products simply for the financial returns. There are often side benefits: learning new technology, honing marketing skills, bringing leads to the consulting business, or benefitting a community your company is active in. And while you can’t ignore the financial concerns, it helps to have a firm grasp on what success looks like if the product doesn’t sell like you hoped.

If you’ve thought about what success looks like – and ideally written that down – it can be easier to make the decisions if a hard period comes. If your primary goal was learning a new technology and trying some marketing, it’s easier to view a product that didn’t succeed financially as a success in other ways and shut it down. Similarly, if the product itself is not generating lots of revenue, but it’s a great lead generator for your consulting company, then it’s easier to justify continued investment as a marketing expense.

Final Thoughts

Building and selling products is tough but incredibly rewarding work. If you’ve got a consulting company that’s doing well financially and you’ve got a desire to try your hand at products, it’s a great learning experience that also helps make you a better consultant. I hope this post gives you some things to consider if you give products a try. But – like everything else in running your own business – you ultimately just need to give it a try, keep an open mind, and keep doing more of what works for you.

Expect the Unexpected! Debug Faster with Bugfender

Trusted By


Already Trusted by Thousands

Bugfender is the best remote logger for mobile and web apps.

Get Started for Free, No Credit Card Required