Make-or-break lessons learned about MVP, capacity, sales metrics, & fractional resources along the way
When looking at companies started by an entrepreneur, it can appear from the outside that the path was planned and clear. It is hard to believe that at least relatively speaking, Amazon, Facebook, Google, Microsoft and Apple were all little companies just starting out, not that long ago. When one thinks about these companies, it is easy focus on the success. But these companies had struggles, made mistakes and learned valuable lessons along the way.
I am not about to compare Vigilix to companies like those mentioned above, but we are still very proud of what we have built. Starting as a technology built for a client to solve one problem—the monitoring of plant floor and back office systems—we eventually turned Vigilix into the leading Remote Monitoring and Management (RMM) platform in the Retail/Point-of-Sale (POS) space.
I can tell you with absolute certainty that the path we have taken was not the path originally planned. Along the way, we made mistakes and had both planned and unplanned successes. I learned a lot in the process of building a product/SaaS company like Vigilix. At one point, I thought about getting my MBA, but decided I couldn’t afford to get it. I don’t know whether an MBA would have helped avoid some of the mistakes I made along the way, but I can tell you that I paid my share of real-life “tuition payments”. I have learned a lot and I’d like to share a some of the key lessons with you here.
Sales Matters
It turns out, if you build it, they don’t just come. Like many entrepreneurs, I had a vision. In my case, it was technology that would solve what I perceived as a very important problem. But my passion was initially about the technology. Surely if we build something that solved this problem, people will beat down the door to get it.
Well, it turns out that many entrepreneurs are thinking about solving problems, but often very few people other than you realize the problem exists. Perhaps that is due to being visionary, meaning you have a lot of market education ahead of you. Or perhaps it is due to simply being wrong. But regardless, it turns out that just because you see the problem clearly and are hyper-focused on solving it, does not mean other people are searching for a solution.
The key lessons for me was that sales matters. To engineers, sales people are a different breed. But it turns out they are a very important breed.
The Best Market Research Is Selling
We spent a lot of money doing “market research”, thinking we were learning details about the problems people wanted us to solve and zeroing in on how much they would pay. We then went into our cave and spent a lot more money building what we thought was the perfect solution to the problems we heard. We kept everything tightly guarded because we wanted it to be perfect on day one.
When the product was finally ready to sell (and by the way, neither myself nor the engineering team really thought it was ready (i.e. perfect) yet), we went back to all those market research customers. Excited, we told them “we have built a solution to the exact problem you described and it costs exactly what you said it needed to cost”. To our surprise, it turns out there is a big difference between talking about writing a check, and actually writing the check.
As we actually were asking for money, we really learned the important problems and the value of solving them. Much to our dismay, we had missed the mark both in terms of pricing and product.
The key lesson learned was get to a point where you can ask someone to write a check ASAP.
Minimum Viable Product (MVP)
Ironically, without realizing it, I had learned the lesson (and paid the tuition to learn it) of building a minimum viable product (or MVP). An MVP is, by its very nature, not perfect. It is the minimum feature set needed to ask someone to pay you.
The key lesson was that if you focus on spending the least amount needed to start selling, you spend a lot less to learn what you should really build, and you spend a lot less to hit the real bulls-eye.
Variable Costs To Get To MVP
One big challenge in building an MVP and focusing on selling/learning is the cost of a full-time development team. If you build a development team, with all the skills really needed for successful development such as project management, quality assurance, technical writers, designers, DBAs, architects and engineers, you have a large fixed cost.
Instead of building an entire development team to get through the MVP (likely a subsequent phase), another option is to find a full-service development partner where you are only paying when they are working. While the per hour cost is almost always higher, the overall cost can be much lower.
Said another way, the key lesson was that there can be value in being able to turn the development team into a variable cost. It can allow you to turn off the development costs and focus precious cash on sales once the MVP is completed.
Avoid Losing Institutional Knowledge
However, depending on the partner’s model, there can be major downsides to outsourcing development to an external partner. We learned the hard way that, depending on the partner’s business model, the resources you engage may not be full-time employees. Why does that matter? Because once the development is completed, “your team” disperses and become employed elsewhere. You have lost the team’s product knowledge, which you paid for them to obtain. In this scenario, if you need to turn the team back on for fixing issues or a subsequent version, you will likely not get the same team again and you will have to pay learning costs again. I found that this had very negative impact on our existing team because they were frequently stuck supporting something they had not written.
The key lesson I learned was that, if you are working with an external development partner to build and are relying on them for most development roles (i.e. they are not just augmenting your existing team), it is in your best long-term interest to find a partner whose team is full-time employees and where the partner has low turnover. There is huge value to being able to re-engage with the original team on subsequent releases.
A side benefit is that while you will likely build an internal team as you grow, this partner can provide the ability to add on-demand development capacity for situations where a feature is needed faster than the internal team can deliver.
Fractional Resources Let You Iterate Team Building
One of the most valuable lessons I learned was the importance of having people other than myself in most of the roles needed to move the company forward. Having started the company, early on I wore almost every hat. As a result, I had the tendency to think that I could do everything. While technically true, the reality is that I was mediocre at a lot of roles, and terrible at others, simply because I was trying to do too much and did not have the time to be anything but mediocre at the things I should have been great at doing.
I was not holding on to everything because I wanted to do it. In fact, it was wearing me down. The issue was that I did not think the company could afford people in all the roles. Had I needed to hire full-time employees for all of the roles, that would have been true. What I failed to realize is that I could use fractional resources for many of those roles.
Some examples of roles/functions where I learned I could build a team using fractional resources were:
- Lead generation (specifically, we found people niche focused in our industry, not generalists)
- CFO
- COO
- DBA
- Infrastructure operations
- Development
- HR
- Marketing
Again, as with development, while the per hour cost of each resource was more than had we hired, the reality is that I was able to round out my team with experts in each of these areas at the cost of about half that of an employee. Could I have hired 1 or two people and assigned these roles to them? Absolutely, however, I believe the chance of winning the lottery is better than the odds of finding one or two people who were great at all of the required functions (and their sub-functions).
The key lesson learned was to get talented people in the key roles and functions needed to drive the company forward as quickly as possible, frequently using fractional resources.
Value of Metrics
As the team grew, I learned the value of providing visibility to each member of the team. The specific visibility depends on the role, but once there are more than two people in positions whether their decisions can significantly impact the company, it is important to provide metrics. People need to know whether their actions are having a positive, negative or neutral impact.
The lesson I learned was that most team members want to do a good job, but if they cannot see measurements that give them feedback, they will assume that what they are doing is the right thing.
Have patience
I have learned many lessons in patience. Frequently, despite your best efforts, plans do not execute as expected and need to be adjusted, thus impacting time frames. Almost everything takes longer than planned.
But the need for patience becomes more important as roles are delegated. While the execution might have been mediocre when I was doing all the roles, I always knew the exact status. There is a tremendous amount of patience, and trust, needed when you have a team making decisions and executing a plan. But if you have the right team, the results can be amazing.
