Chapter 4: What Discovery Actually Is
“Agentic coding has already compressed implementation timelines dramatically. In the near future, parallel agentic systems — operating at lower cost and reduced latency — may compress technical feasibility discovery as well, treating agents as simulations that run concurrent experiments to surface roadblocks before a single line of production code is written. As implementation approaches instantaneous, the locus of value shifts upstream: determining what to build, within fixed time and budget constraints, is becoming the most critical phase of software development.”
The whole purpose of discovery is to determine what we can realistically build that gets our clients to their goal — solves their problem — or, given time and budget constraints, what gets them on the right path and identifies what is blocking them from reaching their goal. Full stop.
Let’s go piece by piece and break down other aspects of discovery and how they are downstream from what to build.
First, requirements gathering. There are two types: one that is downstream from what we need to build, and one that is not. Let’s start with the latter. Let’s forgo the question of what we can realistically build and just gather requirements for the sake of gathering requirements. A client has an idea and we are to gather every single technical requirement needed to bring it to life.
Fair enough. The client wants to build Uber. Great. What do we need? An extremely scalable architecture likely predicated on microservices. An intuitive UI matching the client’s branding preference. Native mobile applications — codebases in Swift and Kotlin. A matching algorithm accounting for surge pricing. Integrations with local taxi cab services. A payment processing system. Multi-language support. Geolocation. Offline protection. A chat system. A rider safety escalation workflow. And on and on.
We’ve gathered all these requirements. Let’s bring them to the client. They’re so impressed! Let’s move into flow diagrams and technical architecture. It’s going to take a long time because we have a billion-dollar platform to design, but let’s get to it. The client loves it! Let’s map out timelines and cost. Hm — the client said that the five-year, ten-million-dollar timeline did not match their expectations. They were expecting something that could be done in three months for $20K.
This is not an uncommon outcome. A Geneca survey of 600 people involved in software development projects found that 78% of respondents felt business requirements were out of sync with the actual project, and 45% of managers said business objectives were unclear to them — even at the start of the project [15]. The problem isn’t that requirements gathering is unimportant. The problem is that when it’s disconnected from the question of what we should actually build, it becomes an exercise in documenting a fantasy.
Now let’s go through the second scenario and focus first on the what. First, we set expectations and make sure the client understands that we will likely provide pushback — necessary pushback — to focus on building something that solves their problem. Next, we make sure the client understands that the determination of what to build is a conversation, but we go in with this understanding: once we agree on the spec, we feel it is our duty to fulfill our promises. If we don’t think we can own a project, we will not continue it. We’ll talk about team placement options or shake hands and go our separate ways. We explain that we understand this is a hard stance, but it is necessary for implementing proper guardrails to ensure a successful engagement. Once that is clear, let’s dig into the what.
The client says they want to build Uber. Sheesh — rough undertaking. First, let’s figure out why. What problem are they trying to solve? What are their motivations? The client says they got the idea because they see many taxi cabs in their city, Houston, piling up around the local airport and not getting booked. Everyone is just booking Ubers. Let me take note of that — I wonder if that’s a widespread issue or just what they see. They don’t actually want to build Uber; they’re claiming they’ve identified an underutilized labor pool. But that’s also interesting. Uber is a massive company that integrates with taxi services in other cities. Why haven’t they expanded into the Houston market yet? Is it a regulatory issue? Something must be blocking that. Let me dig deeper and ask the client what they want out of this engagement. I understand the core problem they’ve identified, but what are their personal motivations? Money? Proving someone wrong?
Interesting — they run a taxi cab fleet. Don’t know why Sales didn’t flag that. They’re saying Uber has been trying to infiltrate the market but they don’t know why it hasn’t worked. They’ve also expressed deep frustration since Uber hit the market, which has had a massive negative impact on their business. Sales let me know they have an ideal timeline of three months and a budget of $20K. Let me schedule a follow-up call, do my due diligence, and provide them a formal recommendation.
In my research, I found that Uber has not been able to infiltrate the Houston taxi market due to technical constraints. There doesn’t exist a software system that can properly integrate with taxi fares, though this technology does exist in other cities. This is a real and widespread issue. Given their limited budget and time constraints, the path is fairly limited. Even a widespread, fully integrable software to solve that gap would be a multi-month undertaking, and a direct partnership with Uber would have to be developed. If I were in their shoes, I would first focus on digitizing their existing business by catering to their existing customers.
There’s a key thing to note: an eventual partnership with a massive provider is likely needed long-term. If they truly wanted to compete with Uber, they would have to compete on market, price, and brand. In the very best case, they would be the third or fourth app people go to after Uber and Lyft. A simple booking application that allows their existing clientele to book taxis directly could provide immediate value and still puts them on the right path toward a future acquisition or partnership. It also gives them a foothold to expand into being the provider of that integration technology specifically for taxis, positioning them well to expand horizontally to other taxi cab services they likely already have relationships with.
We should keep the features simple. A straightforward application that their existing drivers can download and that clients can use to schedule rides in advance only. This is an easy entry into their clientele’s habits because currently their clients just call an individual driver and ask them to be at their house at a certain time. We could add a simple triage system where scheduled rides get sent to the entire fleet, so one driver’s availability doesn’t block the entire system. This still works with traditional taxi cab fares since it can be treated as a normal metered ride — no complex integration with the fare hardware needed. It also sets up a position to prove demand for a larger-scale system. If this goes well, in a second version we can discuss developing that complex fare integration system, or selling the software horizontally to other fleets. If a technological moat is captured through the fare system, or market capture is achieved by obtaining most of the Houston taxi market, this puts them in a great position to be bought by Uber or enter into a lucrative partnership.
This is going to be a fairly abrasive pivot from the client’s original vision. I need to be very clear about explaining how this still sets them up for their final goal — backed by research and a comprehensive roadmap. I need to explain the rationale and real business problems behind their original idea. I need to acknowledge their motivations and personal bias against Uber. But in my opinion, this sets them up well to take advantage of the labor gap they’ve identified, and it works within their time and budget.
Stepping out of the scenario: assuming the client is on board with our recommendation, that car is pointed directly at the finish line. It’s aligned with the client’s goals and ready to step on the gas. No wasted time. We know exactly what we want to build. The client is ready to roll and the entire rest of the engagement is set up. Supercharge that with AI implementation, and we’ve set up a client with a real shot at a massive payout — and at the very least, the potential for immediate success within their own company.
Requirements-First vs. “What”-First Discovery
REQUIREMENTS-FIRST (Wrong) "WHAT"-FIRST (Right) ────────────────────────── ───────────────────────── "Build Uber" "Walk me through the problem" │ │ │ │ ▼ ▼ Gather ALL requirements Understand goals & motives │ │ │ │ ▼ ▼ Design massive architecture Research feasibility │ │ │ │ ▼ ▼ Present $10M / 5-year estimate Determine realistic scope │ │ │ │ ▼ ▼ Client is furious Present aligned recommendation │ │ │ │ ▼ ▼ Backwards negotiation begins Client sees the path (trust damaged) (trust established)
This scenario demonstrates that requirements are downstream from what is needed. More friction up front, absolutely. But the scenario above is the only thing that matters. Let’s tackle another false assumption about discovery: estimation.
Let’s return to the Uber scenario through the lens of estimation. This is more straightforward. Skip the what part of discovery and jump right into estimation. A client comes in wanting to build Uber, and we understand the end goal of discovery as getting them an estimate. So we go through a similar unfiltered requirements-gathering process and end up giving them a multi-year timeline. They can’t accept that, and they’re rightfully pissed. What do we have to do? Talk about the what again. What can we remove to get the client into timeline expectations? But at this point it’s backwards. Expectations weren’t set, and the client feels as though we’re bargaining against their idea rather than working with them in good faith. The engagement turns competitive, and even if the project moves forward, the client will never feel satisfied because they feel they had to compromise their vision to conform to our process.
From these two situations, we can derive a couple truths about discovery. Everything is downstream from scope definition — the what — and risk: the core business or technical risks that directly affect the scope. It is our job as forward-deployed developers to view these two aspects within the bounds of the project’s overarching budget and time constraints. We need to do this with such transparency that, if those three paradigms don’t align with the client’s vision and problem, it is our duty to raise a massive red flag. If we don’t, the project was destined to fail from the beginning, and we are putting our company and the client at risk. Tough conversation, sure. But it’s better to be honest than nice in order to protect all parties.
We can compile this into a simple three-pronged framework. Scope must conform to the client’s vision, motivations, and goals — everything in the scope must match or be directionally aligned with their end goals. Risk must conform to scope — all risk must be properly represented, and there should be no inherent business or technical risk so grave that it cannot be accommodated. These three pillars must all conform to the project’s time and budget constraints. If this model does not hold, the project will not work.
The Three-Pronged Discovery Framework
┌─────────────────────────────────────────────┐ │ │ │ CLIENT GOALS │ │ │ │ Vision · Motivations · Business │ │ & Personal │ │ │ └──────────────────────┬──────────────────────┘ │ must align with │ ▼ ┌─────────────────────────────────────────────┐ │ │ │ SCOPE │ │ │ │ What we build must solve the client's │ │ problem and align with their goals │ │ │ └──────────────────────┬──────────────────────┘ │ must account for │ ▼ ┌─────────────────────────────────────────────┐ │ │ │ RISK │ │ │ │ No technical or business risk so grave │ │ that it can't be accommodated │ │ │ └──────────────────────┬──────────────────────┘ │ must fit within │ ▼ ┌─────────────────────────────────────────────┐ │ │ │ TIME & BUDGET CONSTRAINTS │ │ │ │ Everything above must be achievable │ │ within the project's real-world limits │ │ │ └─────────────────────────────────────────────┘ If any layer breaks, the project will not work.Quick Validation Checklist: