Latest / The Tech Career Podcast with Fexingo: Engineering Jobs, Interviews, and FAANG Career Strategy / How FAANG Engineers Navigate Ambiguous Requirements
Transcript
- Lucas: So last week I was talking to a senior engineer at Google who told me about a project where the spec literally said, 'Build a better onboarding flow.' That was it. Three bullet points. No metrics, no success criteria, no mention of what 'better' even means. Luna: And I'm guessing they spent three months building something that got scrapped. Lucas: Exactly. Two sprints in, the PM shows up with a new data set and says, 'Actually, the real problem is retention on day seven, not day one.' And suddenly the whole direction shifts. That's the cost of ambiguous requirements — it's not just wasted code, it's wasted alignment. Luna: I've definitely been there. It's like playing telephone with a feature request. The VP says 'make it more engaging,' the PM interprets that as 'add more notifications,' and the engineer ends up building something nobody wants. Lucas: Right. And the frustrating part is, the engineer often has the most context about what's technically feasible, but they're not empowered to push back on the ambiguity. They just start coding because the sprint started. Luna: So what's the play? How do you go from 'build a better onboarding flow' to something concrete without sounding like you're refusing to work? Lucas: The technique I've seen work best is what I call 'decision-driven development.' Instead of asking for more details, you frame every requirement as a decision that needs to be made. You say, 'To build this, I need to know: are we optimizing for time-to-first-action or for completion rate? Because those lead to very different designs.' Luna: So you're essentially forcing the trade-off conversation early. Lucas: Exactly. You're not asking for permission — you're highlighting that a decision exists. And the PM can't say 'both' because that's not a real answer. You push them to pick one. That's where the clarity comes from. Luna: I've also seen engineers write a one-pager that lays out the options. Like, 'Here are three approaches, here's what each assumes, which one should we go with?' That forces alignment before a single line of code. Lucas: That's the move. A one-pager doesn't have to be long — half a page, max. It just needs to state the problem, the proposed solution, and the key assumptions. Then you circulate it to stakeholders before the sprint planning. It's amazing how many conflicts you avoid that way. Luna: And it also covers you. If the project later fails, you can point to the assumptions that were signed off on. Lucas: Right. It's not about blame — it's about learning. But it does create accountability. The PM can't say 'I didn't know that would happen' if they approved the one-pager. Luna: Let me ask you this: what about situations where the requirements change mid-sprint? That's a whole other level of ambiguity. Lucas: That's where you need a change-control process. Not a formal committee, but a simple rule: if the requirement changes, the deadline moves. You say, 'I can do this new thing, but it means the old thing won't ship on time. Which do you prefer?' That reframes it as a decision again. Luna: Yeah, because the default is often just to accept the new requirement and try to cram it in, which leads to burnout and bad code. Lucas: Exactly. And that's where the real cost of ambiguity hits — not just the wrong feature, but the technical debt from rushed implementation. I've seen teams spend six months refactoring code that was written in a single ambiguous sprint. Luna: There was a survey last year from the Software Engineering Institute — I think it was 2025 — that said 68% of engineers cite unclear requirements as their top productivity killer. That's higher than bad tools or meetings. Lucas: That number doesn't surprise me at all. And the fix isn't more process — it's better questions. Every engineer should have a mental checklist of three things: what are we optimizing for, who is the user, and how will we know if it worked? Luna: That's a good framework. I also like the idea of writing a 'spec test' — a set of acceptance criteria that you write before you start coding, then you share it with the PM and say, 'If the code passes these, are we done?' Lucas: That's brilliant. It's basically a contract. And if the PM agrees, you have a clear finish line. If they don't, they have to clarify what 'done' means. Either way, you win. Luna: I think the hardest part is actually doing it in practice, because there's always pressure to start coding. It feels productive to write code, even if it's the wrong code. Lucas: The thing is, writing code on ambiguous requirements is like building a house without a blueprint. You might get a wall up, but it's going to be in the wrong place. And then you have to tear it down. That's way more work than spending an extra hour clarifying the requirements upfront. Luna: So the takeaway is: don't start coding until you can answer the three questions. Optimize for, user, and success metric. Lucas: Exactly. And if the PM can't answer, escalate. Say, 'I need a decision on X so I can start. If I don't get it, I'll work on tech debt this sprint.' That's a reasonable ask. Luna: Speaking of reasonable asks, a couple of dollars a month from listeners is what keeps this show ad-free and focused on real tactics like this. If you've gotten something useful out of this episode, you can support us at buy me a coffee dot com slash fexingo. Lucas: Yeah, it genuinely makes a difference. Even a few coffees help us keep the lights on and avoid running ads. So if you're able, we appreciate it. Luna: Alright, back to ambiguity. One thing I want to touch on is how to handle it when you're a junior engineer and you don't feel like you have the authority to push back. Lucas: That's a great point. Junior engineers often feel like they have to say yes to everything. But actually, asking clarifying questions shows you're thinking strategically. It's a positive signal. You can frame it as, 'I want to make sure I build the right thing — can you help me understand the priority here?' Luna: And if the PM still doesn't give a clear answer, you can ask for a quick sync with the team. Sometimes a 15-minute meeting can resolve more ambiguity than a week of back and forth on Slack. Lucas: Absolutely. And document the outcome. Send a recap email: 'As discussed, we're going with approach A, with the assumption that onboarding time is the key metric. Let me know if that's off.' That creates a paper trail. Luna: I also think it's important to recognize that some ambiguity is intentional. Product teams sometimes leave things vague because they want to see what engineers come up with. That's fine as long as you have a clear success metric. Lucas: Right. Not all ambiguity is bad. The dangerous kind is when nobody knows what success looks like. If you can define that, you can be creative within the boundaries. It's like a sandbox — you have freedom, but you know the walls. Luna: So the skill is really about identifying which ambiguity is productive and which is just laziness. Lucas: Exactly. And that comes with experience. But the framework helps regardless of level. Decision-driven development, one-pagers, spec tests — these are tools that work whether you're a new grad or a staff engineer. Luna: I want to ask about something you mentioned earlier — the idea of framing requirements as bets on user behavior. Can you unpack that a bit? Lucas: Sure. When a PM says 'We need to add a share button,' what they're really saying is 'I believe users will share more if it's easier.' That's a hypothesis. So you treat it as a bet. You say, 'Let's define what success looks like — if we add the button and share rate goes up by 10 percent, the bet pays off. If not, we revert.' That makes it easier to decide what to build. Luna: That also makes it less personal. It's not about whose idea is better — it's about what the data says. Lucas: Right. And that de-escalates a lot of conflict. Engineers and PMs can argue about ideas, but they can't argue about data. So the sooner you have a way to measure, the sooner you can stop guessing. Luna: I've seen teams use A/B testing for exactly this. Ship two versions, see which one wins. But even that requires a clear metric upfront. Lucas: Exactly. The metric is the key. Without it, you're just building and praying. And that's not a career strategy — that's gambling. Luna: So to wrap up: next time you get a vague requirement, don't just start coding. Ask the three questions, write a one-pager, and define the bet. Your future self will thank you. Lucas: And your sprint retrospective will be a lot less painful. I think that's a solid takeaway. Thanks for listening, and we'll catch you next time on The Tech Career Podcast.