Argue Hard, Then Build

At a hardware startup I worked at, there was a point where we started exploring the next product.

The existing machine was roughly the size of a small fridge. It worked, customers were buying it, and we had spent years and millions of dollars getting it to that point. It had problems, as all real products do, but it was no longer an idea. It was in the world. It had customers, revenue, service history, manufacturing knowledge, scar tissue, and all the unglamorous lessons that only arrive after a product has been dragged through reality long enough to stop being imaginary.

The company wanted to build a tap.

The idea was simple in the way dangerous ideas often are. Take everything in the existing machine and shrink it down so it could be installed like a tap, with the visible unit mounted cleanly on the bench and most of the hardware hidden underneath. Instead of taking up the space of a small fridge, the system would become part of the kitchen or office fit-out. Cleaner footprint, better visual appeal, easier to imagine in places where the existing machine felt too large.

Before the tap became the serious option, we had also considered a countertop unit. That version was closer to the existing product: same basic function, smaller form factor, designed to sit on a counter rather than stand as a full machine. Other companies had already moved in that direction. The shape of the market suggested there was demand for something smaller than the machine we already had.

My first response was a hard no. Not because I disliked the idea aesthetically. The tap was attractive. The strategic appeal was obvious. If we could swap into a competitor’s footprint without modifying the countertop, that was clever. Very clever. The kind of thing that makes salespeople’s pupils dilate because they can already see the objection disappearing before the customer has finished raising it.

My objection was execution.

From where I was sitting, moving to a new product line looked irresponsible. We had spent millions developing the larger unit and had not saturated that market. There was still money to be made from the machine we already had. It was selling. It was known. The organisation understood how to build, install, support, and service it. It was not perfect, but it was real.

A new product would not be real for a long time. It would require development, testing, certification, supply chain work, support planning, installation processes, spare parts, service training, and all the other invisible work that sits underneath the clean little render on a slide. As a startup, we did not have unlimited resources. Supporting one hardware product is hard enough. Supporting two can become a wonderful way to discover that your company is actually a spreadsheet full of lies.

There was also transition risk. If we mistimed the move, we could end up in the dead zone between products: the old machine no longer getting enough attention, the new product not yet ready to sell, and the company stuck maintaining momentum with enthusiasm and crossed fingers. Hardware does not forgive that kind of optimism easily. It has lead times, physical constraints, manufacturing defects, compliance issues, and vendors who somehow become unreachable the moment you need a straight answer.

Then there was hot water. The tap concept required it, and we had not done it before. That sounds like one extra feature if you say it quickly enough, which is how product conversations become haunted. In reality it meant thermal considerations, safety concerns, material constraints, new failure modes, new testing requirements, and a whole set of engineering problems the existing platform had never needed to solve.

From my point of view, the business case did not stack up. Not yet. The opportunity was real, but the timing looked wrong. We had more to extract from the product we already owned, and I did not believe we had the runway, capacity, or in-house capability to take on the tap without putting the business under avoidable pressure.

I made that argument hard. Then the decision was made.

We were going to pursue the next product anyway.

That is where disagreement becomes real. It is easy to talk about alignment when everyone agrees. It is easy to be collaborative when the decision matches your judgement. The harder version is when you believe the business is making the wrong call, you have made your case, and the call goes the other way.

At that point, you can keep fighting as if the decision is still open. It feels principled, but it usually turns into sabotage with better posture. You can sulk and comply just enough to preserve deniability. You can detach from the work and wait to be proven right, quietly collecting evidence for the future “I told you so.” These are all emotionally satisfying in the small, ugly ways humans enjoy, but none of them help the company.

The only useful move is to accept that the business has made a decision and start working on making that decision successful.

That does not mean pretending you agreed all along. It does not mean your concerns were invalid. It does not mean the person making the call had perfect information or magical founder intuition blessed by venture capital and industrial design mood boards. It means that if you are still in the seat, the work has changed. The argument against the decision is over. The work is now improving the chosen path.

Once I accepted that the next product was happening, I went looking for the strongest version of the business case. If we were going to do this, then it needed to be more than a shiny new form factor. It needed to help the company learn something useful. It needed to reduce risk, not simply create it. It needed to become a bridge between where we were and where we wanted the product platform to go.

The existing unit had issues. Every first serious hardware product does. There were things we wanted to improve, things we had learned the hard way, and design decisions we would not make the same way again. A new product could be a way to explore those improvements without immediately trying to replace everything at once. It could let us solve problems in the current machine, prove better architecture, and carry those lessons into a future generation.

That was the case I could get behind. Not “the tap is obviously the right move.” I did not believe that. More: “If the business is going to move in this direction, we should use the work to de-risk the platform and make the next generation stronger.”

That led me to propose the countertop unit instead of the tap.

The countertop version was still a new product, but it was closer to what we already knew how to build. It could share more of the existing architecture. It could reuse more hardware. It could reuse more of the software and UI. It could let us shrink the product and improve the platform without also taking on the full installation, thermal, spatial, and mechanical complexity of the tap immediately.

My team put together a prototype to make the point. We used the same PCBs, the same software, the same pump hardware, and as much of the existing system as possible. The message was simple: we are already mostly there. This is the bridge product. It gives sales something smaller and more flexible. It gives engineering a controlled path to improve the platform. It gives the company a way to learn without taking the largest possible bite out of the problem on day one.

That proposal was also rejected. We were making the tap, and everything that went with it.

I understood the reasoning. The tap was more attractive. It was a stronger wedge into certain customer environments. It had a cleaner story. The ability to replace a competitor’s unit without modifying the countertop was genuinely smart. In product terms, there was a lot to like.

My objections were still execution objections. I did not think we had the capacity, runway, or in-house skills to pull it off cleanly. I thought the countertop was the more responsible intermediate step. I thought the tap introduced too many unknowns at once.

But the decision was made, so the job became making the tap less risky.

A lot of organisational dysfunction lives in the space after disagreement. People argue, lose, and then keep behaving as if the decision is still open. They comply in public and undermine in private. They become passive. They distance themselves from the work so that, if it fails, they can say it was never really their plan. They protect the ego instead of improving the outcome.

If you are senior, disagreement has a shelf life. You make the strongest case you can. You put the risks on the table. You explain the trade-offs. You argue from the business, not from personal preference. You force the decision to confront reality as honestly as possible. But once the decision is made, the useful question changes from “should we do this?” to “given that we are doing this, how do we make it less stupid?”

That is where the real work starts.

No one sees the whole board. I might have been right about the execution risk. I might also have been missing constraints that mattered more. There may have been sales pressure I did not fully understand, competitive positioning I weighted incorrectly, investor context I was not carrying, customer conversations I was not in, or strategic timing that made the tap worth the risk. That does not mean every founder decision is wise. Plenty are not. Let us not get sentimental and pretend authority comes with divine download. But in a functioning company, different roles carry different information and different burdens.

Your job is not to treat your own view as the only adult one in the room.

Your job is to contribute your judgement, make the risks visible, and then help the company execute the decision it has chosen. That is not blind obedience. It is not being a passenger. It is not abandoning standards. It is separating the argument from the work. It is stopping the defence of your preferred path and starting the improvement of the chosen one.

If the decision is wrong but survivable, make it better. If the scope is too large, reduce risk. If the unknowns are dangerous, expose them early. If the business is underestimating the cost, make the cost visible before it becomes fatal. If the team lacks capability, identify the gap and work out how to cover it. If the chosen path creates unavoidable trade-offs, make sure leadership understands what is being traded away.

That is very different from sulking in the corner while reality proves you clever.

The tap was not the path I would have chosen. The countertop was the path I argued for. But once the business chose the tap, the work was to turn that decision into the best possible version of itself. Sometimes you will be required to build things you would not have chosen. Sometimes the business will move in a direction you think is wrong. Sometimes you will lose the argument even when your argument is good. That is not automatically a betrayal. It is what happens when you are not the only person holding the company.

The lesson is not to stop arguing. The argument matters. If you see risk and stay quiet, you are not being aligned; you are being useless. Put the risk on the table. Make the business case. Explain why the decision is dangerous if you believe it is dangerous. Push for the path you think gives the company the best chance.

But once the call is made, it is “yes, boss.”

Then you get to work.