Ten Lessons I Learned From a ‘Failed’ B2B Software Startup

By guest author and 1M/1M member Luis Montes

Below are ten key lessons our team learned following an unsuccessful two-year launch of PatientDox – a cloud-based startup Software-as-a-Service (SaaS) solution for healthcare providers. It is our intention to not only learn from our mistakes but also help other tech entrepreneurs and colleagues avoid them.

1. Understand your partners’ motivations prior to starting a business. Are your values, goals and motivations for starting a business aligned? This question may not have many implications early on, but can have a profound impact in the end.

2. Quantify and qualify the problem you are out to solve. It is not enough to qualify the problem through interviews alone. It is best to design a quantifiable tool that will allow you to measure various data points when validating a problem (i.e. survey, questionnaire, etc.). What people tell you and what they write on paper (what they really think on their own) can sometimes significantly vary. Learning at this stage occurs both through listening to the customer (interviews) and through measuring and documenting responses in a quantifiable way. Early on, our team was led to believe that the problem we are out to solve was a high priority problem.  We talked to a lot of potential customers. But we didn’t properly quantify our data. In the end, our exit survey showed that the problem we were out to solve was not really rated that highly.

When rating a problem follow the following guidelines:

• Qualify it through personal interviews and dive deep into the motivators
• Quantify it objectively on paper preferably through a scoring mechanism
• Find plenty of data points to analyze (i.e. n>100)
• Do not get emotionally involved or excited about a problem you find. Quantify what the market response is and don’t let your mind convince you that you are “on to something”. Properly captured market data plus intuition developed from your interviews will more than often give you plenty of evidence on deciding to move forward on a problem or not

3. Validate the proposed solution and value proposition to customers preferably before building.  Solution validation should answer two fundamental questions: 1) is the end user willing to change behavior to use your proposed product or solution? And 2) is the organization willing to pay for your product given the hypothesized value proposition? During the solution validation process, PatientDox failed on both fronts: Our initial goal was to secure 5 paid pilots before moving forward. However, we only secured one and decided to move forward anyways due to emotional attachment. Shortly after building a Beta version of our product, we realized that the inherent processes of our end users were too complex for a stand-alone technology solution to work effectively and fully solve the problem we were after. In order to avoid this costly mistake, the following topics and questions must be understood prior to writing code:

a. Who is the end user and what is the value proposition to them? What value do they see in the solution (how much are they willing to pay for the solution?)

b. What is the value proposition for the decision makers in the organization (CEOs, administrators, directors, etc.)? What value do they see in the solution (how much are they willing to pay?)

c. Are your customer’s customers a key part of your solution? With PatientDox, we failed to realize how hard it would be for home health agencies to sign up physicians (their customers) to the platform. In the end this oversight put us out of business

d. What are the end users’ current workflows and how is your solution simplifying those workflows or making any output more effective? What would it really take to change the end-user behavior given the current organizational systems in place?

When validating a solution, the following guidelines will avoid future barriers and greatly diminish risk:

• Map out the workflows of the end-users in order to understand what it would take to effectively change behavior. The team might have arrived at a validated high-pain point problem, but if systems are too complex to change within an organization and old behaviors are deeply rooted, then the team must be prepared (financially and mentally) for slow end-user adoption rates and little revenues early on in the venture. This can be overcome with customer training and industry education, but such methods will substantially increase your customer acquisition costs. Higher capital needs will be required to overcome this inertia and low revenue period. It is best to know early on (before building) if it’s worth fighting that battle or not.
• Validation = Upfront payment. Successful procurement of early adopters or pilot customers before actually building your product should be the ultimate goal at this point.
• Do not get emotionally attached to a problem and the proposed solution – let the market speak and don’t proceed to building something before you have pre-sold some customers. At the very least, secure some customers with a minimally viable product (MVP) before continuing to invest in the product.

4. Be very careful of outsourcing your core competency to another party. Since none of our co-founders had a software engineering or technical background, we decided to outsource product development early on. Although this can be a potential viable strategy with teams that lack technical co-founders, the team must understand the nature of proceeding this way and weigh the pros and cons of outsourcing versus finding a competent technical co-founder. Having a technical co-founder or in-house development team is a major advantage during start-up because:

• As a lean software start-up, at least 90% of your costs will result from product development. Having a technical co-founder can substantially reduce cash out-lay early on and the amount of capital needed to start the company.
• Speed and the ability to make changes on the go based on customer feedback are key factors early on. Outsource developers typically work on various projects at the same time and simply cannot proceed at the speed you need them to during this stage. With outsourcing, one loses control of the core offering and the team is at the mercy of the developer’s priorities and pre-established project milestones (which always change no matter how good you are at hitting milestones).
• If the plan is to scale the company through outside investment, most professional investors do not invest in tech-companies that have outsourced their development to other firms.
  I’m a big believer in outsourcing during the start-up period when resources are scarce. Outsourcing allows the team to concentrate on what they do best (core competency) so that they can offer solutions and services that customers can love and cannot live without. This is the true engine of early growth. Outsourcing your core competency and relying on a third party to execute on the quality of your product can be a dangerous proposition. Think of it as a restaurant that outsources it’s cooking.

5. Despite great efforts during the problem and solution validation stages things can still not turn out as expected (they never really do) during the actual product development. This is why “lean start-up” concepts such as minimal viable product (MVP) development; rapidly bringing products to market for testing; and “build-measure-learn concepts” as described by Eric Ries makes sense for early stage start-ups. During the early stages, product development should focus on testing and validating products rapidly and in a cost effective fashion in an effort to hedge entrepreneur’s risk.

Product validation through MVPs allows the team to learn about markets in real-time through real products allowing the management team to make fast and accurate decisions about the business viability of those products. For example, if an MVP is not catching on due to structural market and strategic reasons, it is best that the team stops building (the earlier the better) and go back to the drawing board. If this is the case, the team should stop wasting resources and time and focus on where they are going with the product rather than on doing (i.e. building more product features). If adoption rates and utilization are low early on, ask yourself the following questions: What is the reason for the low adoption rate or utilization? If product-market fit is not there, do you need to change directions entirely (pivot into other markets)? Perhaps you need to re-explore workflows and simplify the product offering because the usability of the product is not catching on with end-users. If you realize, however, that there is no product-market fit, it’s best to kill the project early and move on to the next. An MVP is created for testing purposes therefore their capital investments should remain low.

6. I believe that during the very early stages of PatientDox, some time and resources were wasted on seeking capital investment. I’ve learned that during the ‘lift-off’ phase, it is best to stay away from spending energy or thought in this department. Unless you are raising small rounds from family and friends to stay afloat, concentrating on seeking professional investment capital is counter-productive. During this stage, all energy should be instead allocated to:  1) learning your market (problems, pain points, work-flows, comparable solutions, market size, end user behaviors, etc.); 2) validating the market problem and solution through measured testing; 3) development of MVP; testing and piloting the MVP; 4) formulating a clear and defined value proposition based on the problem and solution you are building; 5) validating your value proposition and delivering on that promise with real early adopter customers; 6) getting traction and customers by finding more early adopters to buy your product; 7) defining and testing your business model (subscription vs. licensing vs. services; etc.); and 8) achieving predictability in revenue, growth and early profitability. Unless the team has achieved predictable revenue growth through a tested business model, the entrepreneur should stay away from looking for professional investment funds.

7. Since professional investment capital is very difficult to attain during the early pre-revenue stages, the best way to capitalize the company (outside of friends and family) is by bootstrapping through services. Bootstrapping nonetheless should be strategic for if not it can prove to be distracting and often detrimental to the company. Consulting is an ideal bootstrapping mechanism because it involves no up-front capital investment for the entrepreneur. Consulting leverages the skills and expertise of the team so that they can capitalize on their knowledge base while the team is building a more scalable product or service solution. Sramana Mitra, CEO and Founder of the global virtual incubator/accelerator One Million by One Million (1M/1M) has developed great material for her members on this particular topic and I would highly recommend for entrepreneurs looking to bootstrap startup companies to study her writings and videos on this topic. I will talk about two particular aspects of bootstrapping in this article that could have made an impact to our own venture.

Defining your target market is a key strategic component of bootstrapping (i.e. if you are planning to solve a healthcare-related problem, don’t bootstrap consulting services within the real estate market). Bootstrapping within different market segments can be very distracting and drain energy and resources away from the product that you are ultimately trying to bring to market and scale. On the other hand, consulting in the same market segment can allow the team to learn more about a particular market niche. This intimate learning will in turn allow the team to come up with more relevant and creative ideas and solutions that will ultimately help create focused products that customers will actually need, use, and buy. Another key component of strategic bootstrapping is making investment decisions with the cash being generated from bootstrapping. Investment decisions can vary from product development to customer acquisition and marketing. But in the end, the team must have aligned personal motivators to make the right cash investments. For example, if a co-founder is motivated in building a lifestyle type business, bootstrapping cash then becomes a personal matter and the co-founder will likely want to take the money out of the company for personal gain. In this case, consulting itself might be the end product for the company with the goal of sustaining the lifestyle of the entrepreneur. However, if another co-founder has a longer-term outlook for the company, he/she will be more likely inclined to invest the cash back into the company to build products or services that may have a longer term yield and higher return on investment. Both motivations are perfectly okay. However, it is important that co-founders know from the very start what type of business they want to build and what their motivations for starting a business really are.

8. At PatientDox, we poorly managed and executed pilots and we never really got a firm grasp of the actual delivery of our value proposition. I recommend that once pilots (or early customers) have been secured that the team devote all time and resources on managing their execution.  Internal systems should be designed to learn and measure key metrics on a weekly basis and changes in the product (or service) should be made rapidly based on customer results and feedback. Key performance metrics should focus on the following two components: 1) end-user utilization; and 2) testing of your value proposition: is your solution actually delivering on your promise to the customer (cutting cost, improving efficiency; driving new revenue; improving productivity; etc.)? Whatever key metrics you decide to use for validating your value proposition, measure them on a regular basis.
It takes time and effort to design a robust pilot (or early customer utilization) plan. Most importantly, it takes even more time to execute the pilot well.  Make sure that you are devoting enough resources so that you are continuously and systematically measuring your results.

9. Know your Total Available Market (TAM) and decide what kind of business you want to be early on. Knowing your TAM is critical for future strategy. Although we had done a ‘total market size analysis’ of the healthcare market needs, we were not truly aware of our ‘available’ market size. I first became aware of the term TAM from Sramana Mitra, on her 1M/1M virtual incubator lecture series and much of what I know today about TAM comes from her program and my personal experiences with professional investors. In contrast to a generic market size analysis, TAM is calculated ‘bottom-up’ from precise and focused market segments and a defined pricing model of your product or service. Once TAM is estimated, the team could figure out if this is a type of business that a professional investor will be attracted to (>$200M TAM) or not. Before building, the team must make a decision if professional investment will be needed to scale the project. If so, TAM’s of less than $200M will not likely attract professional investors. If outside professional investment is not something that the co-founders are necessarily looking for at the time, then a smaller TAM opportunity is something that might very well be worth pursuing. Smaller TAM niches are great opportunities for entrepreneurs looking to bootstrap a company through internal cash generation. They can be extremely lucrative opportunities for co-founders that allow owners to retain large equity stakes in their companies. One must be aware however that professional investors will not be interested in these types of deals, so looking for outside capital in small TAM opportunities is really counter-productive (unless your solution is applicable in other market segments that will allow your company to scale rapidly with capital injections). At PatientDox, we did waste some time looking for and thinking about professional investment for a business plan that really did not call for professional capital at the time. Know what you are getting into from the start so that you can plan and act accordingly.

10. On hindsight, I don’t think that our team was truly passionate about HIPAA compliant document exchange software or the potential impact of our solution. Whatever your team decides to get involved in, make sure that you are passionate about it. You don’t have to necessarily be passionate about the function or technicalities of the product or service. But being passionate about why you are building what you are building is critical. In other words, be passionate about the problem that you aim to solve and how your product or service will ultimately impact your customers. Be passionate about your value proposition and the ability of your product or service to solve customer problems. Be passionate about why your customers need your tool to help their customers. Be passionate about the impact that your solution can make on society today and tomorrow. Be passionate about building or creating something that your customers cannot live without to do their job. Passion is important because it fuels motivation; motivation fuels action; and properly channeled action, fuels results and success. As an entrepreneur of a new business venture, you have the luxury of starting with a clean canvas. Take this opportunity and don’t waste your time on projects you are not passionate about. Before building and before looking at the viability of the business opportunity, dig deep inside and ask yourself: is this something that I’m passionate about? Is this something I’m willing to devote countless hours and ridiculous amounts of energy and devotion to? If not, ditch the idea and get back to the drawing board. Life is too short to solve dull problems you don’t really care about for the sake of making a profit.

Those are the 10 lessons that I learned from a ‘failed’ B2B software startup. I purposely quoted the word ‘failed’ start-up on the tittle of this article because in entrepreneurship, I believe that the word failure is really an oxymoron. Unless the entrepreneur does not learn from his / her mistakes and fails to get back on the horse again, startup failures are absolutely necessary for entrepreneurial professional growth development. In my book, entrepreneurial failures are nothing but batches of honor. In the end, what is the difference between winning and losing? I cannot deny that the realization of profit is how we keep score of the game. But is profit the real win? Or is playing the game what truly matters? In this respect, I cannot help but think of the words from Rudyard Kipling’s famous poem “If – “:

“…If you can dream – and not make dreams your master;

If you can think – and not make thoughts your aim;

If you can meet with Triumph and Disaster

And treat those two impostors just the same…

Or watch the things you gave your life to, broken,

And stoop and build’em up with worn – out tools:

If you can make one heap of all your winnings

And risk it on one turn of pitch-and-toss,

And lose, and start again at your beginnings

And never breathe a word about your loss…

Yours is the Earth and everything that’s in it,

And – which is more – you’ll be a Man (or entrepreneur), my son!”