|
Listen to the article
|
Note: Though the story is true, image and examples, are produced by google gemini and are not real.
The Language Barrier in Solution Space
We’ve all been there: a critical customer problem is reported, a cross-functional team mobilizes, and weeks are spent on slack and email messages. The problem is complex, the product managers (PMs) are articulate, and the engineering managers (EMs) are attentive. Everyone is speaking clear, well-meaning English, yet the solution remains elusive.
I recently experienced this firsthand. A serious issue plagued our sellers on the marketplace. For three long weeks, PMs and EMs exchanged detailed, descriptive English about the what—what the sellers and buyers were seeing, what the business impact was, and what the ideal seller journey should be.
When I joined the conversation on a Thursday, I didn’t introduce new ideas. I simply changed the language. By forcing the discussion into the lexicon of engineering—the how—the problem was solved in under eight hours. The difference between three weeks and eight hours was not technical skill, but use of engineering language instead of english language.
The Pitfalls of Well-Meaning English
English, or any natural language, is excellent for defining goals and customer empathy. It is a disastrous tool for defining technical solutions.
1. The Ambiguity Tax
- English: “We need to make the product management tool more productive, perhaps by adding AI to help them draft better feature specs.”
- Engineering Interpretation: Does “better feature specs” mean grammar checking? Auto-populating Jira fields? Generating user stories based on chat transcripts? Each interpretation leads to a different architectural path.
- Engineering Language: “We need to integrate the large language model (LLM) service with the
JIRA_API_V3.createIssueendpoint, using a zero-shot prompt that consumes thePRODUCT_CHAT_TRANSCRIPTand populates theUser_StoryandAcceptance_Criteriafields.”
The English statement is vision, but the engineering statement is an actionable commit that defines the specific API calls, data sources, and target fields.
2. The Omission of Constraints
Natural language often focuses on the ideal outcome, omitting the technical constraints that govern reality. In our German site issue, the business need was described as “allowing sellers to update their product pricing.”
The English conversation missed the crucial constraints:
- Constraint 1: The price update required a call to a legacy
PriceSyncService. - Constraint 2: The current frontend was calling
PriceValidationServicebefore the sync, but thePriceValidationServicehad a known latency issue in the German region unless the request included a specificRegion_Optimizationflag.
The PMs spoke of price updates; the engineers needed to speak of latency, PriceSyncService, and Region_Optimization flags. The solution was found only when the discussion pinpointed the specific API flow that was failing, not the seller’s goal that was blocked.
How to Talk in Engineering Language
This isn’t about being rude or excluding people; it’s about being efficiently specific. This framework is for any discussion aimed at solving a problem or improving an existing workflow.
| Instead of Talking About… | Focus the Conversation on… |
| User Action/Goal (e.g., “The user logs in.”) | API Calls & Endpoints (e.g., “What happens on POST /v1/auth/login?”) |
| Product Feature (e.g., “The search is slow.”) | Services, Databases & Queues (e.g., “Is the bottleneck in the ElasticSearch cluster or the Redis cache?”) |
| Productivity Improvement (e.g., “We can use AI to summarize meetings.”) | Data Flow & Tooling Integration (e.g., “What is the prompt structure? Which LLM API is called? Does it post the summary to the Slack_Message_API?”) |
| Errors (e.g., “The German seller saw an error.”) | Error Codes & Logs (e.g., “What specific HTTP status code or database exception (500? 403? TimeoutException?) is returned from which service?”) |
A Call to Action for Product Managers
For product managers leading the charge on AI integration and productivity gains, adopting this technical mindset is not optional—it’s the new requirement for effective delivery.
- Map the User Journey to the API Flow: Before any meeting, be ready to sketch the journey, labeling it with the actual services and APIs involved: “The user clicks A, which triggers a call to
Service X. This service then callsDatabase Y.” - Translate “Why” into “How”: When defining a goal (e.g., “improve seller satisfaction”), immediately translate it into an actionable technical hypothesis (e.g., “We believe latency is the issue; let’s monitor
PriceValidationServiceresponse times in the German region.”) - Use the Right Tool for the Job: Use English for defining vision and impact. Use Engineering Language (APIs, services, logs, data structures) for defining scope and solution.
The goal of every feature, every bug fix, and every AI-powered enhancement is to change a state in a system. These systems operate not on paragraphs of prose, but on defined functions, workflows and executed APIs.
If you want to solve problems or dramatically improve productivity, do NOT talk in English. Talk in engineering language. You might just turn three weeks of discussion into an eight-hour fix.