At Voltaic Coatings, the material performed at the benchtop. That did not answer what it would cost at production volume, where it fit in a customer's manufacturing process, or who would accept the switching risk. We had technical progress and large-company interest, but the commercial questions were still open. That experience changed the way I evaluate every hardware opportunity.
Later, at SolarCity, the product and installation process already worked. The sales offer did not work as well on the East Coast. Customers resisted an escalating power-purchase agreement, while a fixed monthly lease gave them a number they could understand and compare. We changed the offer, and my results rose to 257% of quota and more than $13 million in sales.
Those companies were different, but the lesson was the same: hardware is not simply software with a longer sales cycle. The customer has to fund, test, install, operate, and support something physical. The sales process has to deal with each of those decisions.
Where the software sales model stops fitting.
A software company can often let a customer try the product with a credit card and an email address. The customer can start small, cancel, and remove the software without changing a facility or writing off equipment. That makes free trials, high-volume outreach, and fast product-led adoption reasonable choices.
A hardware customer may need capital approval, installation time, engineering review, a utility or regulator, trained staff, physical space, and a plan for what happens if the equipment fails. More outreach does not remove those steps. A free pilot does not remove them either; it can simply move the cost onto the buyer.
Hardware sales starts with the risk the customer has to accept, not with the number of demos the seller can book.
I see problems when a company copies the visible parts of a software playbook—more outbound, free trials, simple funnel stages—without redesigning them around the actual purchase. Five differences usually explain where the process breaks.
Five places the hardware buy diverges.
Not every hardware deal follows the same path, and not every purchase is booked as capital expense. The useful question is simpler: what must this customer approve and change before the product can operate in the real world?
Hardware may be purchased, financed, leased, bundled into a service, or supported by a grant. Each structure changes the buyer's cash flow, accounting, approval path, and sense of risk. At Energy Fox, the sale was not only the solar array. We had to make the payback, financing, tax treatment, USDA funding, and utility process understandable as one decision. The financial buyer belongs in the process early.
A hardware pilot can consume engineering time, floor space, staff hours, integration work, and production capacity before a larger contract exists. Before it starts, both sides should agree on the test, the success criteria, the person who will approve production, the budget for the next step, and the decision date. If those details are missing, a technically successful pilot can still lead nowhere.
The technical evaluator may like the product, while finance questions the return, operations worries about downtime, procurement wants different terms, and compliance or safety needs more proof. In commercial solar, a single project could involve the owner, lender, utility, grant administrator, engineer, installer, and local authority. A seller has to map that group and give the internal champion what each person needs.
Budget cycles, technical validation, procurement review, permits, interconnection, and operating schedules do not move faster because the seller sends another follow-up email. The seller still has work to do: identify every required step, attach an owner and date, and keep the business case current while the customer completes its process. A realistic schedule is more useful than a close date that moves every month.
If the product fails, the customer may lose production time, remove equipment, retrain staff, or explain a capital loss. The customer will ask for reliability evidence, references, service coverage, warranty terms, and a credible answer to "what happens when this breaks?" Those are sales questions, not details to leave until contracting.
What the SaaS playbook does to a hardware pipeline.
When the sales process ignores those differences, the dashboard can still look busy. The team books demos, starts pilots, and adds company names to the pipeline. The problem appears later: no financial buyer, no approved implementation plan, no production decision, and no credible close date.
I do not treat every early conversation as pipeline. A qualified hardware opportunity should identify the problem worth funding, the people involved in the approval, the evidence they require, and the next decision on the customer's calendar. If those items are missing, the opportunity is still being discovered.
You give pilots away. The pilot is framed as a low-friction trial, priced near zero, offered to anyone curious. Conversion to production is a number nobody wants to look at.
Your "qualified pipeline" has no CFO in it. The named contacts are engineers and technical evaluators. The person who approves the capital is unnamed on most deals, and nobody finds that alarming.
Your close dates slip on a loop. Every deal is "next quarter," and the explanation is always that the buyer is slow, never that the motion never accounted for the buyer's real process.
Early deals often hide these gaps because the founder is personally involved. The founder can translate the technology, answer the financial objection, call the engineer, and keep the project moving. The gap becomes visible when another seller tries to repeat the deal without carrying all of that knowledge.
What hardware go-to-market actually requires.
Start by documenting how the customer actually buys. Identify the financial and technical buyers. Define the evidence each one needs. Set the pilot's production decision before the equipment ships. Build CRM stages around customer decisions rather than seller activity. Then give another person the process and see where it breaks.
A sales hire can improve a working process. They should not have to invent the entire process while carrying the number.
I call the sequence Proof to Pipeline: learn how the decision is made, turn the technical advantage into a business case, build the sales process around that decision, and run it until the team can take it over. The name matters less than the order. Customer evidence comes before messaging, and a working sales process comes before additional headcount.