Alfred AnyanInsights
← All insights

Should I Pause an Engineering Offer When Customers Want Three Different Products?

A young entrepreneur gives a presentation on startup strategies indoors with a flip chart.

Photo by RDNE Stock project on Pexels

A founder should pause the engineering offer when promising customers describe incompatible reasons to buy. Three different buying stories usually mean the company has three possible products, and hiring before choosing one can turn that uncertainty into months of expensive code.

In 1985, Coca-Cola chairman and CEO Roberto Goizueta faced a version of this problem at a far larger scale. The company had tested a sweeter reformulation against its existing drink, and the research supported replacing the original formula. Yet the decision depended on what those tests actually measured.

When positive evidence points in different directions

Coca-Cola introduced the reformulated drink as New Coke in April 1985. The taste tests had answered a narrow question: which sample did people prefer?

Customers answered a broader one after the launch. For some, Coca-Cola was a flavour. For others, it was a habit tied to family, place and memory. A preference between unlabelled samples could not settle what people believed they were buying when they reached for the familiar bottle.

Thomas Oliver documents the episode in The Real Coke, The Real Story. Seventy-nine days after introducing New Coke, the company announced the return of the original formula as Coca-Cola Classic.

The useful part of this story comes before the reversal. Coca-Cola had evidence. The evidence was positive. The mistake lay in treating several possible customer jobs as one settled demand signal.

That is the shape of the founder’s Friday decision.

One prospective customer wants the product because it removes manual reporting. Another wants an AI assistant that helps staff make decisions. A third sees a way to give clients a branded portal. Each conversation sounds promising. Together, they create a problem: the customers agree that something is valuable, but they disagree about what that valuable thing is.

An engineer can build any of the three. That does not tell the founder which company to build.

The hire commits more than salary

At pre-seed, an engineering offer changes the company’s direction even when the job description stays broad. The new hire needs a backlog. The backlog needs priorities. Those priorities soon harden into architecture, onboarding flows and customer promises.

The salary matters, especially when runway is short. The larger commitment is organisational. Once someone joins, the founder feels pressure to keep that person productive. Ambiguity that should have triggered more customer work starts generating tickets instead.

I would not read the three customer conversations as proof that demand is absent. I would read them as three hypotheses:

  • Reporting teams may pay to remove a recurring manual task.
  • Operators may pay for help making a specific decision.
  • Service businesses may pay to present work to their own customers.

Those buyers could require different data, interfaces, sales motions and definitions of success. One engineer working across all three will produce activity. The company may still learn very little about repeatable demand.

This is the same danger behind a hiring plan that assumes future demand has already been earned. I explored that more directly in Startup hiring plans: What the funding memo that assumed unearned demand taught this founder about customer-led growth.

Replace the offer with a short buying test

Pausing the offer should create a deadline for learning, not an indefinite retreat from hiring.

I would give the founder one week to turn each customer’s explanation into a concrete buying test. Ask each prospect to choose a narrow workflow, identify who owns the budget, define what must change for the purchase to be worthwhile, and accept a next step that costs something. That cost could be time, access to data, an internal introduction or a paid pilot.

Then compare the evidence.

Which problem appears without prompting? Which buyer can approve a purchase? Which workflow already consumes enough time or money to create urgency? Which customer will participate before the full product exists?

A product demo can impress the person using it while leaving the budget owner unconvinced. What Happens When Your Demo Wows the User, But Not the Person Paying? examines that gap. It matters here because three enthusiastic users can still represent zero approved purchases.

The founder can send the offer once one buying path produces stronger evidence, or once the company deliberately chooses a path despite incomplete evidence. Both are real decisions. “All three sound promising” is avoidance dressed as optionality.

What the unsent offer protects

The Friday pause protects the engineer as much as the runway. A good engineer should join a company with a hard problem to solve, not become the mechanism for discovering which problem customers meant.

Coca-Cola could reverse its 1985 decision and restore the original formula. A small startup has fewer ways to undo months of scattered product work. Code remains in the repository. Customer-specific promises remain in conversations. The team keeps maintaining features built for buyers who never shared the same reason to buy.

Keep the offer drafted. Put a date on the next decision. Before that date, ask the three customers for evidence that requires commitment.

If one path survives, hire against that path. If none survives, the unsent offer has already done valuable work: it preserved enough runway to keep looking.

Comments

No comments yet.