The team should fund the part of the demo tied to the clearest urgent problem and the fastest credible test of demand. A six-week build must answer one expensive question, rather than carry three promising ideas forward without proving any of them.
At 9 a.m., four teammates sat around a plastic table in Lagos with warm bottled water, two charging cables and a demo that had worked under judging-room pressure. The team is an invented composite, but the decision is familiar. Their founder, Kelechi, had slept for ninety minutes and was still wearing his hackathon wristband.
The demo could read stock requests sent through WhatsApp, predict when a small retailer might run out of key items, and suggest nearby suppliers. During the presentation, each capability had attracted interest. Now the team had enough runway to fund one of them for six weeks.
By noon, one engineer needed an answer. If Kelechi chose badly, they would spend most of their remaining cash improving a feature that people applauded but would not use.
Three working features created three different businesses
On the laptop, the product looked coherent. A shop owner sent a message. The system interpreted it, checked likely stock needs and proposed a supplier. The full sequence took less than a minute when the sample data behaved.
Outside the demo, each step carried a separate assumption.
The message reader assumed shop owners already recorded useful stock information in messages. The prediction tool assumed the team could obtain enough reliable sales history. The supplier suggestion assumed merchants wanted an introduction and trusted the proposed source.
Kelechi initially wanted to preserve the whole flow. Removing any part felt like damaging the product they had spent the weekend building. His technical lead disagreed. Supporting all three meant dividing engineering time across message handling, forecasting and supplier data before they had confirmed which problem created enough pain to change behaviour.
That distinction matters. A demo proves that a sequence can run under prepared conditions. It does not prove that someone will provide the required data, return next week or pay to keep the sequence running.
Teams often leave a hackathon with feature confidence because the software moved. The harder uncertainty sits elsewhere: which part deserves a place in a customer’s working day?
The decision turned on evidence they could collect
They wrote the three options on the back of a printed event schedule. Then they replaced “Which feature is strongest?” with a narrower question: “What can we learn in six weeks that would change whether we continue?”
The forecasting feature looked technically impressive, but it required historical records the team did not yet have. Six weeks could disappear into cleaning sparse data while leaving demand unresolved.
Supplier suggestions offered a clearer commercial path, but only after the team built and maintained a dependable supplier set. A positive reaction to the demo would reveal little about whether a retailer trusted the recommendation enough to place an order.
The message reader had the smallest surface area. It also sat closest to an observed behaviour: merchants already sent informal requests in chat. The team could test whether turning those messages into structured stock requests saved enough effort to earn repeated use.
This was the turn. They stopped asking which feature completed the vision and started asking which assumption could be exposed to reality before the runway tightened again.
The principle is similar to the one in AI Product Validation: What Ada’s Monday Taught Femi About Building the Right Workflow. Validation becomes useful when it follows the actual work, including its awkward inputs and exceptions, rather than the clean path prepared for a presentation.
Six weeks needed a boundary and a failure condition
Kelechi circled message interpretation, then added two boundaries.
The product would structure a retailer’s request and return it for confirmation. It would not predict future demand. It would not recommend a supplier. Those exclusions gave the engineer a buildable scope and gave the team one behaviour to observe.
They also defined what failure would look like. If merchants would not send real requests through the tool, confirm the extracted items and return without repeated prompting, better forecasting would not rescue the product. The team needed to see recurring use before reopening the larger roadmap.
This is where founders can protect runway. Set the evidence threshold before development begins. Otherwise, every weak signal acquires a generous explanation: the onboarding needs work, the sample was wrong, one more feature would make the value obvious.
A useful six-week commitment names the user, the recurring moment, the behaviour that signals value and the result that stops the work. It also names what the team will leave untouched.
The same discipline appears in Shared Codebase Strategy: How Kwame Drew Boundaries Without Splitting the Team: boundaries preserve the decision a team has made when daily implementation pressure starts pulling it apart.
Monday began with the smaller promise
On Monday morning, Kelechi removed two tiles from the product screen. The interface looked less impressive than it had during the hackathon. That was useful.
The team could now sit beside a retailer, watch a real stock request arrive and see exactly where the interpretation failed. A missing quantity, an ambiguous product name or a correction typed in frustration would teach them more than another polished run through sample data.
The other two ideas remained in the repository, but they no longer had a claim on the next six weeks. They would return only if repeated use created the data and trust they required.
Kelechi’s next meeting began with one promise: send the request you already send, then check what the system understood. By shrinking the demo, the team had given itself a fair chance to discover whether there was a business inside it.
Comments
No comments yet.