TechCrunch tells founders to arrive in Boston with 'a decision you're working through'. The question that asks what you put first.
On October 15, 2026, TechCrunch published a last-call notice for its own Founder Summit, telling readers that "Savings of up to $200 end October 16" for Founder and Investor Passes. The pitch is to "Join 1,000 founders and investors on November 4 at Boston’s SoWa Power Station" for a day on which the agenda "covers fundraising, hiring, product-market fit, and building an AI native company." Founder Passes are listed at $199 and Investor Passes at $399, and the named speakers are Kent Bennett of Bessemer Venture Partners, Lior Div of 7AI, and Vineet Edupuganti of Cogent Security. It is a promotion rather than a news report, and TechCrunch notes that it may earn a commission on purchases made through its links. The instruction it gives attendees is still worth reading on its own: "Come with a decision you’re working through."
Read the list of what that decision might be. "Your next funding round. Your next hire. Your next big product decision." Three claimants on the same founder's attention, and only one of them is about the person who pays for the product. The piece then asks readers to "Consider which assumptions you need to test," which is the quieter half of the same thought. A founder who shows up in Boston with a decision is really showing up with a conflict between things that all deserve the next month, and with a set of beliefs about customers that may not survive contact with them. That is the behaviour a hiring manager is probing with the question below. They are not asking whether a candidate likes customers. They are asking what the customer beat, and how the candidate knew.
Why they ask it
"Tell me about a project where you prioritized the customer" sounds like an invitation to be warm. It is actually a question about allocation. Every organisation says it is customer-focused, and nearly every candidate says the same, so the words carry no information. What distinguishes an answer is whether the candidate can point to a moment when the customer's interest and some other legitimate interest pulled in different directions, and show that the customer won on evidence rather than sentiment.
The interviewer is listening for a real competitor for the resource: a roadmap commitment, an executive's pet feature, a cleanup the team wanted, a metric the candidate was measured on. They are listening for a defensible basis for knowing what the customer actually needed, as opposed to what the loudest account or the candidate's own taste suggested. And they are listening for whether the candidate understood what the choice cost and managed that cost rather than pretending it did not exist. A story with all of that is a story about judgment. A story missing any of it is a story about being agreeable.
The trap
The common failure is a story with no opponent. "Customers asked for an export feature, so we built it" describes order-taking, and order-taking is not prioritization because nothing was displaced. The interviewer hears it and privately files the candidate as someone who responds to whoever spoke last.
The second failure is letting one customer stand in for all of them. A manager who reorganised a quarter around a single large account may have made a sound commercial call, but if the story never establishes why that account's request reflected a broader need, it reads as deference to revenue. The interviewer cannot tell the difference and will assume the less flattering version.
The third failure is omitting the cost. Candidates finish with the customer delighted, the team proud, and nothing lost. Experienced interviewers do not believe this. Something was pushed, someone was disappointed, a date slipped. A strong answer says what it was, because naming the cost is the only proof that a choice was made.
Applying STAR-T
Situation. Set up the conflict briefly, and make sure both sides are legitimate. "Our team owned the invoicing service. The quarter plan, which I had agreed with the CTO, was a ledger refactor engineering had wanted for a year. Partway in, support escalated a pattern of tickets from customers receiving duplicate payment reminders after a partial refund."
Task. State what you had to decide, not what you had to build. "I had to decide whether this was a bug we could schedule behind the refactor or a problem that justified breaking a commitment I had made to my own leadership."
Action. This is where the evidence lives. Say how you found out what the customer actually experienced, and who you talked to before you moved anything. "I read the tickets myself rather than the summary, and asked support to pull every case from the previous month, not only the escalated ones. I called a couple of the affected customers. Both told me the reminders had reached their finance teams, which meant our error was becoming their internal problem. I took that to the CTO with the ticket data and proposed pausing the refactor for a sprint, with a named engineer and a defined exit condition. I told the engineering lead directly that the refactor was being delayed and why, rather than letting it show up as a changed board."
Result. Give the outcome in terms the customer would recognise, then the outcome for the thing you displaced. "The duplicate reminders stopped within the sprint, and the customers I had called confirmed it. The refactor resumed a sprint late and finished inside the quarter, tighter than anyone wanted."
Trade-off. This question rewards naming the cost plainly. "The engineering lead was right that we had deferred that refactor before, and my decision made it look deferrable again. I accepted that, and in the next planning cycle I made the refactor the first item rather than the carryover."
The example is generic by design. What matters is its shape: a real competitor, evidence gathered firsthand, a choice communicated to the person it hurt, and a cost owned afterward.
The follow-up that breaks weak answers
"How did you know that was what the customer wanted, and not just what they said?" Candidates with order-taking stories have nowhere to go, because they never checked. Candidates with a single-account story have to admit they generalised from one voice. Candidates with a strong story have already answered it in the Action, and the follow-up simply lets them say it again with more detail. If an answer cannot survive this question, the problem is not the delivery. It is that the story does not yet contain a decision.
Score your answer against the director’s bar
Q: Tell me about a project where you prioritized the customer.
Bank the story where the customer beat something that mattered, and rehearse it until the cost is as easy to say as the win. Try it free →