Chapter 5: Understanding the Client
A core and continuing problem in technical services is the ability to derive the core problem and motivations from a client. First, let’s lay out why this matters. We are in the service business. We are here to serve others’ needs as efficiently as possible. To provide the most streamlined and direct service, we must first determine what they want. I’ve found that many people do not clearly outline their goals or the reasons behind them. When that is coupled with a shallow understanding of the service being provided — most of our clients are non-technical and do not understand the complexities of software — the distance between a client’s vision and a forward-deployed developer’s understanding is typically large.
Take the Uber example from the previous chapter. This is an extremely common scenario. A client does not understand the technical complexity of building Uber. Many people also look at software as the mechanism for revenue generation without understanding that software is a component of business, not the business itself. The disconnect between a forward-deployed developer and a client is often large, and it’s extremely important to reduce this gap as fast as possible so we can ground ourselves with that first pillar of discovery: understanding client goals, motivations, and vision.
There’s a reason this is labeled as one of our discovery pillars. If you don’t understand the client’s vision, the project will not work. Let’s go in depth into some methodology and systems you can use to align your understanding rapidly.
First, let’s break down a distinction between two layers of client drivers that we typically see. There is always a business reason a client is doing something, and there is always a personal reason. The business reason is the rational and conscious reasoning. The personal reason is the emotional and subconscious driver.
Using the Uber scenario: the client’s business reason was that they saw an underutilized labor pool in taxi drivers and were well positioned to take advantage of the opportunity. The client’s personal reason was likely that they felt their business was snuffed out by Uber and were driven by that resentment to build something. It’s important to understand both while maintaining professional boundaries. I’ve utilized a framework established by Toyota called the “5 Whys” that I’ve found effective for deriving these core reasons.
The 5 Whys was originally developed by Sakichi Toyoda, the founder of Toyota Industries, and became a cornerstone of the Toyota Production System. Taiichi Ohno, the architect of that system, described it as “the basis of Toyota’s scientific approach — by repeating why five times, the nature of the problem as well as its solution becomes clear” [16]. While originally designed for manufacturing root cause analysis, the iterative questioning technique has been widely adopted across industries including technology, lean management, and Six Sigma [17]. The method’s strength is its simplicity: by repeatedly asking why, you move past surface-level symptoms to uncover deeper causes — or in our case, deeper motivations.
The 5 Whys: Drilling to Core Motivations
SURFACE ─────────────────────────────────────────────────────────────────────── CORE WHY #1 WHY #2 WHY #3 WHY #4-5 ┌────────────────┐ ┌────────────────┐ ┌────────────────┐ ┌────────────────┐ │ │ │ │ │ │ │ │ │ "What do you │ │ "Why this │ │ "Why are you │ │ "What is your │ │ want to │─────►│ project? │─────►│ heading │─────►│ personal │ │ build?" │ │ What business│ │ this up?" │ │ goal here?" │ │ │ │ opportunity?"│ │ │ │ │ │ │ │ │ │ │ │ │ └────────────────┘ └────────────────┘ └────────────────┘ └────────────────┘ SOLUTION BUSINESS OWNERSHIP PERSONAL LEVEL REASON REASON REASON (what they (rational & (why them) (emotional & think they conscious) subconscious) need)Example — Uber Scenario:
| Why # | Question | Answer | Layer |
|---|---|---|---|
| 1 | “What do you want to build?” | “An app like Uber” | Solution |
| 2 | “Why? What opportunity do you see?” | “Taxi drivers are underutilized at airports” | Business |
| 3 | “Why are you pursuing this specifically?” | “I run a taxi fleet” | Ownership |
| 4 | “What’s driving this personally?” | “Uber has crushed my business” | Personal |
When a client tells you what they want to build, ask why. There’s no need to be curt or impolite about it. You can phrase it like: “I have a good understanding of the software you want to build here. If you don’t mind me asking, can you provide some insight into how you came to this idea and what business opportunities you see?” Typically at this stage you’ll hear the business reason — business needs, market opportunities, a company initiative. Take note.
Then ask “why” again. For example: “Thanks for outlining that. It’s really helpful to know that the motivation for this project is a company-wide initiative. Can I ask why you specifically wanted to undertake this and head up this project within your organization? It’s very commendable, and it would be helpful to understand if there are any personal goals you have in mind as well.” Here is where you can get to the personal reason. Perhaps the client is gearing up for a promotion. Perhaps they have a personal experience that aligned them closely to the project. The personal reason is always tougher to derive because we are not therapists and must maintain boundaries. But it’s good to get an indication.
These two motivations are core to understanding the full picture, which allows us to align the project in accordance with what they actually want. It also helps position our communication more effectively and compose deliverables that are easily digested by our clients.
However, in many situations there are multiple client stakeholders, and this can complicate the ability to determine project goals. Research consistently supports this: a PMI survey found that companies aligning their project management office to strategy had 38% more projects meet original goals and 33% fewer projects deemed failures [18]. Stakeholder engagement has been identified as the most valuable project management process, and 62% of successfully completed projects had supportive, actively engaged sponsors [19]. It’s important to map stakeholder roles to communicate most effectively. Typically what we see is someone who holds the decision-making power, someone who serves as a trusted advisor (typically technical) to the decision maker, and someone who provides opinions — or some combination of these roles. Regardless of the dynamic on the client’s side, it’s important to explicitly make that determination. If it’s not clear who is calling the shots, we flag it as a major blocker to being able to align on vision. It’s also important to set the expectation that we are happy to communicate with all stakeholders, but most directives, questions, and communication should come from the project lead. We expect internal communication to be funneled into queries from that person. The project cannot move past this phase until someone is determined as the project lead. Once this determination is made, move to understand the business goals and personal goals from each stakeholder.
Stakeholder Mapping Template
Use this to map and document the client’s power structure at the start of every engagement:
| Role | Name | Decision Power | Involvement Level | Business Goal | Personal Goal |
|---|---|---|---|---|---|
| Decision Maker | ___________ | Final say on scope, budget, direction | Must attend all sync meetings | ||
| Trusted Advisor | ___________ | Influences decisions (often technical) | Regular involvement | ||
| Opinion Holder | ___________ | Provides input, no authority | As needed | ||
| Behind-the-Scenes | ___________ | May have veto power (spouse, co-founder, board) | Rarely present but influential |
Validation Checklist:
Once the power dynamic is identified and set — so to speak — in a multi-stakeholder project, this will be a continual aspect of the project to manage. Slight power dynamics may shift, people may get removed from the project, and so on. It’s just important, as a forward-deployed developer, to always keep this in mind and call a meeting to realign if it starts slipping. Additionally, even in single-member projects, there are always stakeholders behind the scenes: advisors, spouses, friends. It’s important to clock this as well, and if necessary, pull them into the communication or expedite the communication cycles with behind-the-scenes stakeholders. For example, if a client has a co-founder who is not technical and does not join the project meetings but does have to sign off on every decision, it’s important to raise that as a red flag and mandate that they delegate all decisions to the co-founder who does join the meetings, or involve the other co-founder in meetings moving forward.
Assuming the project is ready to go from a power allocation standpoint, it’s important to start getting a feel for what the success criteria will be. This is extremely important — if we do not determine what to build and what determines when building is done, technical projects especially have a tendency to never end. There will be endless change orders, revision requests, and headaches. This will eat into profitability and overall sentiment toward the project. Once you know and agree on what to build, you must quickly qualify what determines the completion and success of the scope. Typically, this is done by outlining a set of success criteria that correlates with the project scope. However, when determining what the success criteria are, make sure not to implement impossible success criteria and pigeonhole yourself early on. This has come up specifically when using the scope of the project and then dropping it into AI to generate success criteria. The success criteria that comes back is akin to what you would see at massive, multi-year projects. Most of the time, the success criteria — especially for greenfield projects — is that the app should work, scale relatively well, and be secure. We do have some larger projects that require enterprise-level compliance, HIPAA, and so on, but most of the time a simple suite of criteria is sufficient. It’s also important that the determination of the success criteria is verifiable internally. The success criteria should not be client-approval-based — for example, if the client needed to verify that the project is HIPAA compliant. This will just slow things down indefinitely and puts the forward-deployed developer on their back foot in the relationship. The client should agree to what the success criteria are, but the verification of the criteria itself should all be internal.
Success Criteria Quick Guide
Now, assuming client power is allocated and identified correctly, goals have been extracted, and success criteria are scoped, timing is important to understand. This can be done with a simple question: “Why now?” Further questioning may be needed, but most of the time, rationale for timeline boils down to urgency or importance. If something is urgent, this means the client has a real pain point that the project needs to solve. This could be a business problem or personal problem, but the need for the project is mainly predicated on pain and an urgent need for it to be solved. Importance is more nuanced — it’s less predicated on pain. “This is an initiative that we wanted to explore,” “this could expand our operations,” and so on. Not necessarily coming from a position of “Our accounting system is down and we need this integration ASAP or we won’t be able to file our quarterly report.” Both rationalizations for timing can be utilized to best assist the client. If a forward-deployed developer identifies a timing reason of urgency, it may be best to expedite the discovery process by scheduling extra meetings to move into a solution faster. Clients may be willing to pay extra for expedited work in these situations as well. Conversely, for a reasoning of importance, clients may be more open to scope expansion for exploratory reasons, or more open to expanding the discovery phase for additional research. Most of the time, urgent clients need the project done, and done now. Importance clients need the project done, and done right.
The last lever to understand in terms of business context is budget and how it relates to all previous aspects of the project. Budget in itself is nuanced and fairly complex to understand. It encompasses how much money a client can allocate to the project, but it also has other components — namely, where the money is coming from, how much capital can be allocated right now versus over an extended timeline, how painful allocating budget is to the project, and what methodology of collection should be utilized. Let’s break down each component and some methods to extract them.
Determining where the money is coming from is key and can give you insight into the importance of the project to the client at a personal level. If a client is funding the project personally, that typically means the client is personally tied to the project. The money that the client uses for their own life is being allocated to the project — so, to some level, the project is tied to the client’s life. This typically means stricter expectations and timelines, more pushback, and less of a business-oriented outlook. Again, this is completely fair as the client is fundamentally personally impacted by the project. This is usually the case with startups and smaller SMBs. Additionally, there may be some misunderstanding in the function of software within a larger business ecosystem. Specifically, with self-funded projects, it’s important to clearly explain that software does not guarantee the business success of a project. Technically, the software will be sound, but just having working software does not supplement marketing, sales, management, governance, and so on. In terms of determining this, a forward-deployed developer can just ask if needed, though an internal conversation with the account executive or sales staff would typically uncover it.
If working with a larger organization, typically the money is not coming out of the project lead’s pocket. This results in a more business-oriented outlook toward the project and a greater emphasis on the software working to solve a technical constraint or problem. Unlike self-funded projects, the money is not directly impacting the client’s life — their salary will be the same with or without the project. This means there could be less urgency, with more importance placed on working, secure, and well-documented solutions that can be consumed by multiple stakeholders. It’s also important to understand the reporting mechanisms at play and where the client’s personal tie to the project is. Most of the time, this comes down to the client wanting to look good to their boss or senior members in their organization who are closer to the personal financial impacts of the project. Facilitating great progress reports to show up the line or easing the visibility of the project’s success can be great deliverables to add on here. Cutting through the noise: money doesn’t matter to the client, but success of the project will make them look good, so anything that assists in showing that will be helpful.
Client Timing & Budget Matrix
TIMING MOTIVATION Urgency Importance ┌───────────────────────┬──────────────────────────┐ │ │ │ │ • Pain-driven │ • Opportunity-driven │ │ │ │ │ • Need it NOW │ • Need it RIGHT │ SELF- │ │ │ FUNDED │ • Willing to pay │ • Open to expanded │ │ a premium │ discovery │ │ │ │ │ • Expedite the │ • Scope exploration │ │ discovery │ welcome │ │ │ │ │ • Stricter │ • More flexible │ │ expectations │ timeline │ │ │ │ ├───────────────────────┼──────────────────────────┤ │ │ │ │ • Pain-driven │ • Initiative-driven │ │ │ │ COMPANY- │ • Formal approval │ • Formal approval │ FUNDED │ may slow things │ process for budget │ │ │ │ │ • Urgency helps │ • Emphasis on docs, │ │ push approvals │ reporting, security │ │ │ │ │ • Progress reports │ • Long-term value │ │ matter │ focus │ │ │ │ └───────────────────────┴──────────────────────────┘
Let’s discuss total budget allocation. Many times clients come in with an understanding of how much they can allocate to the project right now, but not much thought has been given to how much money they can allocate over the course of months or years. This, again, differs depending on where the money is coming from, but there are time levers at play. In self-funded projects, there is going to be more pushback on project budget expansion, again because the funds allocated have a larger personal impact. But very rarely do self-funded projects have an extensively strict cap on budget allocation. Specifically, very few self-funded clients have moved $25K into a bank account and determined that no matter what happens to this project, they will not exhaust more than this initial allocation. Many clients come in with a rough understanding of what they are able to spend on a month-by-month basis, and so long as the capital allocation fits within a macro expectation of the cost, they are fine with it. Sales and marketing also play a part here in what clients are coming in expecting to spend, so it’s extremely important to always keep in mind what clients’ expectations are as well. To round this point out: many self-funded clients are coming into a project with a spending expectation set by sales, will have more pushback toward a misalignment of that expectation, but generally have an abstracted view of what they can actually allocate to the project — this obviously differs on a client-by-client basis.
With company-funded projects, there are different factors at play, and again, it differs org by org. Some companies do have that strict limit of capital allocation discussed earlier — essentially, no matter what happens, they cannot exhaust more than $1M on AI initiatives until a new budget is determined. Some companies are completely problem-oriented and do not have a strict budget for initiatives. Most of the time, though, project budget is more explicitly set and changes to project budget have to go through a formal process with approvals from different people within the organization. This means that setting project cost limits earlier on is important with company projects. Again, it’s not the client’s personal money, but money allocation does mean everything to someone within the organization. Whether that’s the CFO or the owner, changes will bubble up to someone in the organization whose head will be on the chopping block if company finances go sideways — so changes in project budget will be slower to enact. The level of urgency or importance plays a role here as well.
With that out of the way, what are some methods to determine budget expectations and capabilities? To start, talking to sales and marketing to determine if any expectation was given to clients upfront will be key. Additionally, many clients outline their expectations early on in the sales process. However, if needed, a forward-deployed developer can professionally ask the client early on in the discovery process: “Let’s discuss budget expectations, as understanding this will fundamentally impact what we’re able to build and the timeline. In an ideal project execution, what are you expecting to invest? And are there any hard limits on investment that you have?” This is nuanced, because the client may be defensive when it comes to these questions, so it’s important to outline that a transparent understanding of budget is necessary for a proper discovery phase.
If the forward-deployed developer has properly navigated context understanding, they should have identified and organized a clear chain of command and power allocation with the client stakeholders, identified each stakeholder’s business and personal goals, identified if the client is coming from a place of urgency or importance, determined the client’s budget, and have a good feel for the success criteria to define following alignment on what to build.
Client Context Extraction: Master Checklist
Complete this before moving to scope determination:
Power & Stakeholders
Goals & Motivations
Timing & Urgency
Budget
Success Criteria (Preliminary)