Episode #39: Combining Product and Design in a Small Team with Mahmoud Ilyan

In a small company, product strategy and interface design cannot always wait for separate layers of management. In Episode #39, Mahmoud Ilyan explains how combining product and design can shorten the path from direction to execution, provided the team keeps listening to users and respects its constraints.

What you'll learn

• How development, design, and business experience shaped Mahmoud's product perspective

• Why one leader may cover product and design effectively in a small company

• How customer communities support frequent qualitative feedback

• Why teams should combine user conversations, product usage, and quantitative research

• How to make progress with limited time, budget, and resources

Build a broader view of how products work

Ilyan started as a backend developer, working with databases and data rather than interfaces. His early interest in technology went back to installing and configuring software and games on older Windows systems. He later studied business while learning computer science and working full time, eventually leaving university when the competing demands became too difficult to sustain.

Design gave him a way to make technical work visible and think more directly about the people using a system. He sold design templates, moved into frontend work, and became interested in solving user problems. Coding still appealed to him, but he found that backend work could leave him isolated from the full product picture. Product management, design, business, and technical knowledge offered a wider view.

That range matters in his leadership approach. Instead of treating a roadmap, an interface, and an implementation as unrelated artifacts, he sees them as connected parts of one effort. Technical familiarity helps him collaborate with engineers, while design work turns product intent into something the team and users can examine.

Combine product and design when the scale fits

At VBOUT, Ilyan served as VP of Product and Design. He argues that the combination can work well in a small company because efficiency matters and the same person can connect strategy to execution. He can imagine the roadmap and product direction, write it down for others, design the experience, and collaborate with engineers to make it functional.

He does not present the structure as universal. Once a company has many features and a larger workforce, one leader may need to focus on a single discipline. The useful boundary is capacity. Combining roles should reduce handoffs and improve coherence, not overload one person or prevent specialists from giving each area enough attention.

Ilyan also sees design as a possible source of meaningful product differentiation. He uses Notion as an example: its capabilities can be compared with familiar document, spreadsheet, and project tools, but the experience of using them together feels distinct. His point is not that design can replace product value. It is that interaction design can shape how familiar capabilities become a coherent product.

Create regular, human feedback loops

VBOUT used a private community of loyal customers and held calls weekly or monthly. The relationship had become comfortable enough that conversations felt closer to collaboration with friends than a formal research session. The team could present designs, hear reactions, and test whether its direction matched how users thought about their work. The company's CEO also brought marketing experience and another community into those conversations.

Ilyan supports using both qualitative and quantitative research, but he emphasizes the need for unstructured human listening. A product leader should sometimes step away from technical details, let people speak freely, and ask what they are doing and why. That setting can reveal concerns that are difficult to reduce immediately to a metric.

He also recommends using the product yourself. Internal use does not replace customer research, since team members are not identical to customers. It does create another route for experiencing friction directly and checking whether the product is something the people building it can understand and rely on. Community conversations, direct usage, and quantitative evidence can each expose a different part of the problem.

Ilyan describes balance as one of the hardest parts of leading product and design. A team may face limited time, budget, and resources while competing in a crowded market. It must retain existing users, attract new ones, and confront features that are easy to imagine but difficult to build.

His response is practical. Before committing to a large implementation, the team can look for a library or adaptable component, modify it, test the idea, and decide whether a custom version deserves further investment. He also warns against disappearing too deeply into a design or one feature simply because it is personally interesting. Time away from the screen can help a leader reassess priorities.

This thinking extends to personal and organizational weaknesses. Ilyan argues for accepting the actual challenge in front of you rather than wishing for the problem described in another company's story. Every company has its own constraints. Progress comes from patience, negotiation, and making better use of the resources already present.

Listen to Episode #39

Listen for a compact discussion of multidisciplinary product leadership in a small company. Ilyan offers a useful standard: connect strategy, design, engineering, and customer learning, but shape the operating model around the team you actually have.