Ouzair Hafeez has spent his career working across different stages of product development, from an extremely small yet ambitious startup in Pakistan, to Telenor, and eventually to established technology companies in Sweden... Klarna. He then joined Spotify, where he has spent the past four and a half years working across several product teams.
His experience spans fintech, consumer software, connected devices, and entirely new product experiences. At Spotify, he's worked on widgets, CarPlay and Android Auto, the smartwatch experience, and Spotify for Airlines.
This was Ouzair's second visit to Grayhat. He first visited two years ago, and his return offered an opportunity to revisit the conversation with a different perspective: what it takes to build products in large technology companies, how their working methods translate to smaller teams, and what separates someone who can execute a task from someone who can question whether the task is worth doing in the first place.
Building from scratch at Spotify
One of the most interesting parts of Ouzair's experience at Spotify was building a product for an entirely new environment. Spotify already worked across mobile devices, cars, TVs, and smartwatches, but airline entertainment systems (In-Flight Entertainment Systems) presented a different opportunity.
The initial opportunity came from Spotify's business development team. Spotify didn't have a very strong customer-facing presence during flights. Improvements in in-flight connectivity, including the arrival of Starlink-enabled Wi-Fi, opened up the possibility of a streaming experience directly on the screens in front of passengers.
The first challenge was not designing the interface. It was convincing the organisation that the opportunity was worth pursuing. The design team explored an opportunity to connect it to broader product principles:
"The user should be able to seamlessly transition from one device to another - what we call a 'seamless ecosystem' at Spotify."
i.e. someone listening to music in a car should be able to continue listening on their headphones at the airport and then move to the entertainment screen on an aircraft.
The exchange illustrates an important aspect of senior product design. Designers cannot assume that leadership will immediately recognise the value of an idea. They need to articulate the underlying product principle, connect it to business strategy, and explain why a seemingly unconventional opportunity belongs within the company's broader direction.
Research, a wider funnel, and a major design pivot
United Airlines provided an initial opportunity to assess the potential audience. A study amongst the audience examined how different traveler segments individuals, families, and adult groups use Spotify, revealing distinct usage patterns, account structures, and user expectations across each category.
But this study changed the scope of the problem. The initial idea had focused primarily on engagement: how to bring an existing Spotify experience onto an airline screen. But if more than half the audience did not use Spotify, simply improving engagement would leave a substantial part of the opportunity untouched.
The team reframed the experience around the wider funnel: awareness, activation, engagement, retention, and re-engagement.
The important distinction was between designing a screen and designing an acquisition and retention experience. A passenger who already had Spotify needed a straightforward way to access an account. Someone unfamiliar with the service needed to understand what it was, why it was available, and how to begin using it. These were different user journeys, even though they ended on the same screen.
The implementation appeared straightforward until they unboxed the actual hardware in their device test-bench. The actual aircraft screens had remote controls, which meant D-pad navigation in addition to touch gestures. This changed how users moved through the interface, located controls, and selected content. Also, after thorough testing, the team also encountered readability problems for business-class passengers sitting farther away from their screens, as well as layout issues caused by translating a tablet experience into a landscape display.
Ouzair emphasised that these were not cosmetic problems. Navigation is fundamental to media applications, where users expect to find and play content without unnecessary effort. An interface that works well on a touchscreen does not automatically work well with a remote control.
The team therefore audited available framework options, and pivoted towards a different native architecture that addressed the experience related issues in better way.
The team updated the design, prototyped it, and explained the problems with the original approach, and showed why the a "TV-like" experience better matched the hardware and the research.
The prototype helped make the argument tangible. Leadership could experience the navigation problems and understand why the proposed alternative was more appropriate. The pivot was not a change of taste. It was a response to evidence.
"We moved away from the tablet."
The final experience used QR codes for sign-in and onboarding, allowing passengers to pair their Spotify accounts with the in-flight screen. Privacy was a key constraint, requiring a solution that automatically cleared user data before departure. Ultimately, the team delivered the product and established a long-term roadmap that met the launch timelines.
Vision and design
A recurring theme in Ouzair's talk was the distinction between a product vision and an MVP. At Spotify, a vision describes a longer-term direction for a product or ecosystem, while an MVP identifies what can realistically be delivered to test or establish the experience.
For an established product, designers can build on an existing foundation. They can explore how the product might evolve over the next five or six years, establish a direction, and then reduce that vision into phases of implementation. The vision is not supposed to be a detailed specification of every interaction. It establishes what the experience could become.
He explained that the Spotify app team usually developed visions for 2026, 2028, and 2030, using them to communicate how the experience might evolve over time. The later vision, he said, was deliberately more ambitious than the product that could be shipped immediately.
"It's basically for the VPs to know [...] what our North Star is."
The North Star provides a shared direction for product, design, engineering, and leadership. It also gives teams a way to evaluate individual features against a larger goal, rather than treating every request as an isolated addition.
One might be able to run design execution and keeping a vision, at the same time. Ouzair, however, described it as one of the most difficult parts of his design career because the two activities required different kinds of thinking.
"I wouldn't recommend it."
His advice was to establish the vision first and then work backwards towards the deliverable scope. For the airline project, the team eventually separated requirements into three categories: must-haves for the MVP, should-haves if time permitted, and could-haves that belonged in the longer-term vision.
This is a familiar prioritisation technique, but its value depends on the discipline behind it. Without a clear distinction between the desired future and the immediate deliverable, teams can end up compromising the vision while still trying to ship everything at once. A good vision gives the team a direction; a good MVP makes a deliberate trade-off about what is necessary now.
During the Q&A, an audience member asked how a vision survives changes in research, implementation, and stakeholder feedback. Ouzair explained that the vision should not be tied to small implementation details. Whether a device uses touch gestures or a D-pad, for example, should not fundamentally determine the long-term vision. Those are implementation constraints that the design must accommodate.
He also explained that Spotify's established product development cycle begins after the initial opportunity assessment. The process then moves through research, design, and development, with reassessment when new evidence requires a change in direction. Senior designers and engineers are expected to define a better path when the standard process no longer fits.
The process provides consistency, not an excuse to stop thinking. Even at Spotify, following the established cycle does not mean remaining inside it when the circumstances change.
Spotify vs a four-person startup
An audience member posed a practical question: if Ouzair joined a startup with four people, consisting of two designers and two engineers, how much of Spotify's process would he retain?
His answer was direct.
"I wouldn't implement the Spotify ways of working in a startup because they have money to burn, to be honest."
Spotify can invest months in research, maintain established product development cycles, and allocate specialised people to different stages of a project. A four-person startup usually cannot afford the same overhead. Its needs, resources, and pace are different.
Ouzair's recommendation was not to abandon process, but to retain the useful parts and make them lighter. He would bring over the distinction between vision and MVP, along with a clear approach to design iteration. These practices help small teams make decisions without losing sight of where the product is heading.
What he would not bring over wholesale was a rigid sequence of activities that prevents people from moving forward until someone else has finished their part. In a small team, designers and engineers need to work across boundaries and respond to problems as they emerge.
He used Lovable as an example of a more compact, flat structure. In his recent discussions with Lovable's cofounder, he learned that team members are responsible for the success of the product rather than only the tasks assigned to their role. A junior designer does not necessarily wait for a senior designer to finish something before contributing. They work proactively and pass their work into the product.
"Everybody is responsible for everything."
This is a different operating model from a traditional hierarchy in which responsibilities are divided by seniority and discipline. In a small startup, a designer may need to identify an engineering issue, and an engineer may need to propose a design improvement. The boundaries still exist, but they are more permeable. Design is not an isolated discipline that engineers need to sit through passively. The two increasingly overlap, particularly in startups where people have to make decisions quickly and understand the whole product. With AI, the lines blur even further.
His advice was to keep the process lean and agile, avoiding dependencies that unnecessarily block progress. A small team still needs research, prioritisation, and a longer-term direction, but it must apply them in proportion to the problem and the resources available.
Developing critical thinking skills
The conversation then moved from design process to a broader question about hiring and professional development. With AI increasingly capable of generating code and producing solutions, what distinguishes a strong engineer or designer from someone who can simply execute a task?
Ouzair described a shift in the kinds of capabilities companies look for. Rather than hiring only for expertise in a particular framework, such as React or JavaScript, teams increasingly value people who can move between technologies, understand unfamiliar systems, and resolve problems independently.
At Spotify, he explained, engineers do not necessarily wait for a manager to assign every task. They may identify work during a designated internal hackweek, take initiative on a problem, or move between frontend and backend work when the team's workload allows it.
This is not the same as abandoning roadmaps or accountability. It means that the roadmap is not the only source of useful work. Employees are expected to recognise problems and take responsibility for addressing them.
Ouzair also challenged the classification of communication, problem-solving, and critical thinking as merely soft skills.
"It's not a skill that you can easily learn. It takes quite some time."
He argued that critical thinking develops through experience and cannot reasonably be expected to appear overnight. He even described disagreements with HR over how Spotify assesses junior designers: expecting someone who is 20 or 21 to demonstrate the same level of critical thinking as a much more experienced professional risks confusing potential with accumulated experience.
For him, the challenge is to assess how someone reasons, not just whether they arrive at an impressive answer. That distinction was also present in his account of interviews at Intercom, Meta, Google, and Lovable. In the design interviews he described, interviewers were interested in the thinking behind a solution, how candidates responded to challenges, and whether they could explain their decisions. At Spotify, he said, interviewers receive two to three days of training, and the process includes structured note-taking and review.
The point is not that the finished solution is irrelevant. It is that a polished output alone does not reveal how a candidate arrived there, whether they understood the problem, or how they would respond when their assumptions proved wrong.
Start with the problem, not the solution
When an audience member asked how to build critical thinking skills while working with AI, Ouzair offered a simple starting point: resist the urge to jump immediately into solution mode.
"You need to think about why does this problem exist in the first place, why does it matter, why should I solve it."
This is especially relevant when using AI tools. A person can receive an apparently convincing answer to a poorly framed question without ever examining whether the question was worth asking. Ouzair gave an example of someone taking a screenshot of a manager's message in Slack, sending it to Claude, and forwarding the generated response back to the manager. The person had obtained an answer, but the process revealed little evidence of independent reasoning.
His recommendation was to deliberately step back when approaching a problem. Ask why it exists, what caused it, why it matters, and whether it needs to be solved at all. Only then should the work move towards a solution.
This is a small change in working method, but it affects the entire development process. Instead of treating a task as an instruction to execute, the individual begins to investigate the assumptions behind it. The same approach applies to product design, engineering, and business decisions.
For Ouzair, being senior is less about title or years of experience and more about taking ownership, exercising judgment, and thinking beyond the task at hand. At Spotify, he described a working culture where engineers proactively pick up work, sometimes move beyond their own specialisation, and take responsibility for the product rather than waiting for someone senior to tell them what to do. Critical thinking is a big part of this: understanding why a problem exists, whether it is worth solving, and whether the proposed solution actually addresses it. Seniority also means being able to explain and defend your decisions, even when challenging people above you in the hierarchy. The goal is not to follow a process blindly or to prove you are right, but to make better decisions and help the team build the right thing.
Look beneath the surface
Ouzair illustrated this with a story from his previous visit to Pakistan, two years earlier. He and a friend, who runs the Pakistan Literary Society and helps children access education, had met a confident, outspoken boy. The child appeared enthusiastic and comfortable speaking with adults. Ouzair's friend helped him obtain a place at a government school.
Two years later, Ouzair learned that the boy had left school and begun working with his father. At first, the explanation appeared straightforward: the child simply did not enjoy studying. But his friend continued asking questions.
Why did he not enjoy it? Because studying was difficult. Why was it difficult? Because he could not understand the material. Why could he not understand it? He tried, but the teacher became angry with him.
As his friend investigated further, another possibility emerged. The child had been confident and outspoken before entering school, but his confidence had diminished. "When you start unveiling things, like, if you start looking at things not just on a surface level," Ouzair says, "... it's critical thinking," suggesting that repeated reprimands may have made the child fearful and suppressed the personality that had initially made him so comfortable speaking with others.
For Ouzair, the same reasoning applies to products. A user may say they dislike an application, struggle with onboarding, or abandon a feature. Treating the statement as the entire problem can lead to a superficial fix. Investigating the underlying causes may reveal that the real issue is comprehension, confidence, context, or an assumption the team never tested.
Critical thinking, in this sense, is not about being contrarian or making every decision unnecessarily complicated. It is the discipline of questioning the first explanation, connecting evidence, and remaining open to a more accurate understanding of the problem.
Ouzair was clear that this capacity develops over time. It requires repeatedly looking beyond the obvious, in professional work and in everyday life. AI can accelerate parts of the process, but it cannot remove the need to decide what matters, which assumptions deserve scrutiny, and whether a proposed answer actually addresses the underlying problem.
A different way of working
Across the session, Ouzair returned to a common distinction: following a process and exercising judgement are not the same thing.
Spotify provides established cycles, research capabilities, product frameworks, and a shared understanding of how teams operate. Those systems help a large organisation coordinate work across many disciplines. But the airline project still required the team to challenge leadership, rethink its technical approach, and revise its scope when the evidence changed.
At the other end of the spectrum, a four-person startup cannot reproduce Spotify's full process. It needs people who can work across disciplines, make decisions without waiting for permission at every step, and take responsibility for the product beyond their individual tasks.
The connective tissue between the two environments is not a particular design methodology. It is the ability to understand the problem, justify decisions, adapt when new information emerges, and distinguish the long-term direction from the next deliverable.
For Grayhat, the discussion was a reminder that mature working practices are worth learning from, but they should never be adopted without understanding why they exist. The goal is not to make a small team operate like Spotify. It is to develop the judgement that allows a team of any size to build the right thing, challenge its assumptions, and keep moving when the original plan no longer works.
