Saeed Raja: A Focused Playbook for Building Valuable Controllers

This installment quizzes Saeed Raja, VP of CXL Products at ScaleFlux, on his experiences in product management and planning across software, systems, and components.

1. You started in applications and product marketing. How did that path shape your approach to ASICs and controller design?
2. What are those four tenets in practice, and how do they guide feature tradeoffs and ROI?
3. Tell me about a product that didn’t go as planned—and what you changed after.
4. Different customers want different things. How do you reconcile hyperscaler pressures for commodity / uniformity with memory-vendor desires for differentiation, and what sets ScaleFlux apart?
5. Product planning and development process: rigid gates or flexible framework? And how do you define being a good partner?

Q1. You started in applications and product marketing. How did that path shape your approach to ASICs and controller design?

Saeed: I came up through software, systems, and modules—always asking four simple questions: why would someone buy it, how will they use it, what benefits do they get, and what does it cost us to deliver? Those questions followed me from data-center applications into storage systems and, eventually, down into silicon. Seeing the full stack—app to storage to SoC—made the value of the controller obvious: raw memory isn’t valuable until a controller turns it into something deployable and profitable. That’s why I moved into ASICs: to sit at the leverage point where silicon choices directly improve application performance and business outcomes. Those four tenets remain my lens for every product decision.

Q2. What are those four tenets in practice, and how do they guide feature tradeoffs and ROI?

Saeed: I frame product definition with performance, power, schedule, and cost. They’re not slogans; they’re guardrails. Customers will ask for many features, and some deserve to make it into the design—especially when they clearly tie to customer value and we can monetize them. Others, we decline. Saying “no” is part of being a good partner because it preserves focus and prevents orphan projects. We continuously tune features and resultant costs in response to real customer needs, but we won’t add cost without a clear ROI path. That discipline also means watching cost deltas from change requests, accepting justified increases, and pushing back when changes aren’t aligned to the roadmap or the business case.

Q3. Tell me about a product that didn’t go as planned—and what you changed after.

Saeed: We assumed that our deep expertise compression technology on NAND would port easily to DRAM—it didn’t. That assumption cost us time to market for CXL. The big takeaway was not to underestimate how different media behave.

We simplified the development plan and the scope of project. We increased resources on the compression R&D development. We realigned our roadmap. That clarity helped rebuild trust with key ecosystem partners and got the development team re-energized around execution.

We offered compression in the next gen products when it was fully hardened and with buy-in from key customers. In the end, I learned that focus really is a performance multiplier.

Q4. Different customers want different things. How do you reconcile hyperscaler pressures for commodity / uniformity with memory-vendor desires for differentiation, and what sets ScaleFlux apart?

Saeed: Hyperscalers tend to want uniform controllers—no islands to manage across hundreds of thousands of servers. Memory suppliers, by contrast, often want selective differentiation to mitigate device idiosyncrasies and surface their strengths. Both are reasonable. Our approach is to provide a solid, production-grade baseline and offer customers the ability to build on top of our firmware source for their specific needs. When a customer wants unique behaviors, we can support via statements of work—while keeping core quality and schedules intact. Another differentiator: we’ve been intentional about compliance and jurisdictional requirements, making sure our IP and export posture are aligned with what large customers expect. That kind of forethought reduces friction during qualification and builds trust.

Q5. Product planning and development process: rigid gates or flexible framework? And how do you define being a good partner?

Saeed: We’ve matured our processes across generations by narrowing the roadmap and clarifying roles, but I’m not a “process for process’s sake” person. In chips, not everything is linear. A pragmatic framework beats rigid ritual: define milestones, know what “good” looks like, use reviews and approvals where they matter most (for example, engineering sample readiness), and retain flexibility to make informed exceptions when the data says it’s safe. The real key is staffing—having the right people in the right roles—so the framework enables speed rather than becoming a speed bump. As for partnership, it comes down to “commit thoughtfully—and then deliver.” It’s okay to say “no” to a request.  However, once we commit, we must meet the performance, power, schedule, and cost expectations. If a slip becomes likely, we communicate early, explain the rationale, and align on revised plans. Saying “no” early is better than stringing anyone along. Credibility takes years to earn and seconds to lose, so we protect it with disciplined commitments and transparent execution.

In Summary

Relentless focus on value—defined by customer benefit and monetizable delivery—drives what gets built and how it’s built. To establish and deliver that value:

1. Four-tenet framing: Every decision is filtered through performance, power, schedule, and cost—plus the original product-management questions of why buy, how used, which benefits, and what it costs to deliver. This aligns engineering effort to business outcomes.
2. Disciplined scope: Saying “no” to misaligned features (even when tempting funding is attached) prevents orphan projects and preserves focus for the must-do work that customers will deploy—and pay for.
3. Transparency for trust: The DRAM-side compression assumption forced a roadmap reset. The fix—simplify, right-size, and articulate exactly what’s new vs. proven—strengthened external credibility and internal velocity.
4. Framework over dogma; partnership over promises: Use process as an enabler, not a cage. Commit only after sober analysis—and once committed, deliver with transparency. That’s how trust compounds across generations.