Different Ways to Pay for Product Development

There are many more ways to pay for product development than you may realize, including not paying for it at all. What is right for your situation will depend on your exact circumstances. You may wish to review the following before starting your next product development project.

Most of us are familiar with this method: hire the engineers and technicians that you need to do the work and pay them a salary. This works well for large companies that can attract top talent and have the scale to afford large specialized teams of experts along with the leadership and management infrastructure necessary to keep product development running effectively. Smaller companies almost never benefit from this model as they struggle to attract talent, have difficulty keeping all of the staff busy, and struggle with low productivity with less specialized and/or smaller teams. This method is rarely a good choice since small companies have less scale to leverage development cost.

Freelancers can be an effective way to manage the gaps in your technical team. They almost always work at an hourly rate that is often less than the total cost of a full-time employee and many of them are experts in their field. Mid-size companies use them effectively to augment areas of specialization that do not warrant hiring a full-time person, especially if these companies have effective management structures in place that allows the freelancers to focus on the technical challenges. Small companies of ten or fewer make the mistake of using these specialists as system designers and suffer from the “if you’re a hammer, everything looks like a nail” syndrome. Without management and processes in place, it is hard to utilize this category effectively. It is not uncommon for small companies who utilize this strategy to do the wrong thing really well.

These companies (including Finish Line PDS) provide complete product development teams with management, processes, reference designs, etc. Product Development Companies (PDCs) work best with small companies (<$100M in annual revenue) that can’t afford, or don’t need, a permanent team—their product cycles are measured in years, not months. PDCs do not work well for large companies with existing teams and their own effective processes unless the company suspects the specific project is significantly disruptive of the status quo. Large groups can suffer from NIH (Not Invented Here) syndrome and often have a vested investment in the current technology to the point of dismissing the “next thing.” This is why Walmart, with its enormous investment in physical stores, will be put out of business by Amazon, who, by using innovative online retailing, was free from investing in physical stores.

Requirements are agreed to, and the PDC provides a fixed bid for these requirements. Most PDCs will not do fixed-priced bidding because of the destructive dynamics set up by this type of contract. Once the contract is signed, the PDC must keep within the budget at all costs, and the client wants as much as he can talk the PDC into. The focus becomes less about the potential ROI and more about who will be burdened with what cost and how to justify such action. The result is more energy spent on negotiation and less on product enhancement. In theory, this method works well; in practice, it destroys the relationship. There can be exceptions if the project is broken down into very small steps, and each step is taken one at a time.

This is the most common method when working with a PDC. A good faith estimate is given for each phase of the project, the PDC keeps good records of each engineer’s time, and each engineer is billed at a rate commensurate with their skill level. If you need your PDC to become a true team member—someone who will provide value beyond just performing a task—this is one of the best options. It combines the best of having employees without the fixed cost commitment.

Some PDCs will exchange equity for work done. This can be an effective method for a startup that is pre-series A and needs an MVP in order to complete a series A round. Typically, this takes the form of a note with interest and unpriced warrants to compensate for the risk.

This method is starting to gain popularity—especially with smaller companies. Instead of paying for development, you simply buy the product you need; the design is built into the purchase price. This can be a win-win in many cases as the client simplifies their purchasing decision and the product development team simplifies “management of the customer.” The PDC will own the IP, subject to certain warrants and performance clauses, but this ownership also creates an incentive to create a product that outsells anything else on the market. I predict that the world will largely move toward this model exclusively.

Of course, any combination of these methods can be used. In fact, it is rare for us to see any one of these methods used exclusively on any one project. Small companies typically have a few engineers in-house to focus on the core technologies, use a few freelancers now and then to fill in gaps, and use a PDC to roll everything into a controlled Master Book with the proper controls and documentation necessary for effective manufacturing and sustaining.