Product fluency was a management skill. The SDO doesn't have that excuse anymore.
For most of the history of software engineering, there was a clean separation between the people who understood the business and the people who built the software. Engineering managers lived on the boundary. They translated. A product manager would arrive with a problem — a metric declining, a customer complaint, a competitive threat — and the EM would convert it into something the team could act on: a ticket, a sprint goal, a technical specification. Engineers could stay in the implementation layer and do excellent work there. Understanding why something was being built was someone else's job.
That arrangement made sense when translation work was genuinely difficult, when the pace of development meant there was always a queue, and when specialization was the most efficient use of everyone's time. The EM processed the queue. Engineers worked from it. Product fluency lived at the boundary, not inside it, and the system functioned because the boundary was stable.
It isn't anymore.
The SDO doesn't have a queue in that sense. The SDO has a conversation. AI-assisted development has compressed the time between "someone understands what needs to be built" and "the thing is built" to the point where the translation layer — the EM, the grooming session, the carefully written ticket — is becoming a bottleneck rather than a guardrail. The SDO operates closer to the business than any individual contributor has before. That proximity has a cost: you have to understand what you're near.
An SDO who lacks product fluency is just a faster implementer. They can execute against a spec at speed, but they can't catch a bad spec before it ships. They can't prioritize competing work using business criteria. They can't push back on a feature because they know the customer well enough to know it won't land. They can do the job technically and miss it entirely.
This is the mandate the EM used to hold. It hasn't gone away — it's moved. The SDO who treats it as someone else's responsibility is operating on an assumption that stopped being true at the last horizon, and will be less true at every horizon after it.
Product fluency isn't a single skill. It's a cluster of capabilities that the EM traditionally held and that the SDO now needs to develop. None of them are mysterious. All of them require deliberate attention.
Understanding the metrics your work moves. Every piece of engineering work connects to something the business cares about — conversion, retention, latency, error rate, revenue per user. Most engineers know the technical metrics. Product fluency means knowing the business metrics and being able to trace a line from a technical decision to a business outcome. Not perfectly — the line is rarely clean — but well enough to have the conversation.
Being in the room where product decisions happen. The SDO needs access to upstream context — the conversations where priorities get set, where customer feedback gets interpreted, where competing bets get weighed. This isn't about attending more meetings. It's about understanding the logic of the decisions before they arrive as requirements. When you know why a decision was made, you can make better decisions in its service — and you can flag when an implementation path is in tension with the intent.
Prioritizing across competing work using business criteria. Purely technical prioritization — pay down the debt, fix the fragile thing, build the abstraction that would make everything cleaner — is not wrong. It's incomplete. The SDO has to be able to weight technical priorities against business ones, and sometimes lose that argument gracefully, and sometimes win it because they can make the case in language the business understands.
Understanding the customer well enough to push back. This is the highest-order version of product fluency and the rarest. It means having enough firsthand knowledge of how customers use the product — what they're actually trying to do, where they get frustrated, what workarounds they've built — that you can evaluate a proposed feature from their perspective, not just from an implementation perspective. When an SDO can say "I don't think this is what they need" with credibility, they've become something more than an implementer.
The EM used to be the translator. The SDO has to learn the language. — The mandate, plainly stated
Product fluency doesn't come from reading a book. It comes from proximity and repetition — from being in more of the right conversations and paying attention while you're there. A few investments compound faster than others.
Get upstream of the ticket. Whenever you can, be part of the conversation before the requirement is written. Ask why. Ask what problem this is solving. Ask what success looks like. This isn't about slowing things down — it's about entering the work with better information than the spec alone provides.
Learn the metrics your team is measured on. If you don't know the two or three numbers your product leadership cares most about, find out. Then start noticing when your work touches them. Make it a habit to think about what you're building in terms of those numbers, even when the conversation doesn't require it.
Talk to people in product as peers, not translators. The EM used to be the intermediary. As an SDO you have to build the relationships directly — with product managers and designers, understanding how they think about problems, showing up to those conversations with genuine curiosity rather than waiting to be handed a spec.
Use customer context when you have it. Support tickets, user research, NPS comments, sales call recordings — wherever your organization surfaces what customers actually say, read it. Not systematically, just enough to keep your mental model of the customer honest and current.
When you disagree with a direction, say so in business terms. Technical objections are easy to override. Business objections require engagement. "This will be hard to build" is easy to dismiss. "I don't think this will move the metric we're trying to move, and here's why" is harder to ignore — and it's the kind of contribution that changes what the SDO is understood to be.
The SDO who understands the product isn't just a better implementer. They're a different kind of contributor — one who can shape what gets built, not just how quickly. That's what the role is now asking for.
The tooling will keep accelerating. The question is whether the person holding it understands the business well enough to point it in the right direction.