Office Hours with Sameer Bhiwani

Sameer Bhiwani is currently a UX Lead at Google, he has worked with companies like HP, startups like Blue Jeans, and headed design at Scripbox. Sameer is a familiar face at ownpath. He was a coach at The Design Management program at Gojek, where he helped senior designers transition into management roles. And this year, Sameer has played a vital role in building the fellowship program and curriculum.

We hosted Office Hours with Sameer Bhiwani on Wednesday evening with the hopes of answering your questions about the Product Design Fellowship, and to address any concerns you may have had.

We put together our key takeaways from the questions designers asked Sameer, as well as other learnings about working in the product design space. We hope this helps those who were not able to make it to the Office hours or are looking to learn about how the program could benefit them!

1. Improving your design interview skills and practices for better success

Portfolio: A lot of designers present sparse information from projects and emphasize only the end result. By discounting the journey, they miss out on things like the research conducted, minor interactions, collaboration, and experimentation. To present the full picture, designers need to incorporate these things and talk about how they arrived at the end result. Document what you learned and show your process more.

Soft Skills: It’s not only about mockups, communicating your awareness of soft skills is as important. Designers should be mindful of gaining and talking about their soft skills. Things like time management, working with non-designers, collaboration, working with teams from different fields and functions etc.

Find allies who will be able to speak for you and represent you in meetings where you’re not present.

2. Working in big teams vs small teams

Working in smaller design teams or reporting to seniors who don’t have a deep background in design can pose some challenges. With the lack of representation in teams with only one or two designers, making sure your voice is heard becomes difficult.

Find your allies: Find individuals within your organization who share the same ideas as you. People who are willing to work with you on new concepts, and will collaborate with you in communicating them. Find allies who will be able to speak for you and represent you in meetings where you’re not present. They don’t need to have the same function as you, you can seek these individuals out in other domains like marketing, engineering, research etc.

Different types of roles: Small design teams will usually have more generalist roles, while bigger teams will have more specialized roles. In big teams, there will be more opportunities to learn from your colleagues. You can always be more specialized in a small team, and learn new things in a bigger team; however, the opportunities for both these paths differ. For example, if you want to research something new, it would be likely that someone else in your company would have looked into it already, and you can discuss the learnings and research with them.

Defined structure and levels: With big teams and organizations, there are more defined levels and career ladders. You would usually be able to consult with HR about the kind of traits, skills, and requirements a certain level possesses. So, when discussions for appraisals come up, you can clearly talk about how you’ve exhibited the skills required, or talk to your manager about giving you work or advice that would satisfy those requirements.

With big teams there is strength in numbers, there would be more opportunities to find a mentor with more experience or mentor someone with less experience.

Smaller teams leave a little more room for exploration. The structure at startups is built through discovery, where roles and levels are defined as needed. To advance in a team like this, you would have to pave the path and bring structure to your company. Since all startups and teams do have to mature at some point, you have the unique opportunity of taking the initiative and bringing it forth to management.

A book that lays this out very well, for roles within design and beyond is Org. Design for Design Orgs by Kristin Skinner and Peter Merholz. They define these levels that are more or less applicable to most organizations.

3. Domain expertise: How much should designers know about complex domains?

Competent Product Team: Any successful product would have a balance of design, business, and technology. This would be represented by three competent people respectively, who are experts in their own fields and know a great deal about the other two. To illustrate a dynamic where there is an imbalance, consider a product team where the Product Manager and Designer work together, but the Engineer is either junior to them, or not as clued in. You could come up with something that is designed well and is aligned with business values, but it may not have technical feasibility, or it may not fit in a certain timeframe. There are different problems that would occur if there is a deficiency in any one field.

As a designer, it will always help to know more. If you take the effort to learn about the business side of things, like the market fit, knowing your competitors etc., you will have a better contextual understanding of the product. Because the usability of your product is affected by say competitors, or features in the technology. So, it helps to have these conversations with people from different domains.

Subject matter expertise: Learning this expertise is relative to the domain and its context. Is it something that comes naturally to you, like video conferencing; or is it a core-engineering product that will take months to get a grasp of what is happening? Learn a little about a lot of things, and if you’re interested go ahead and learn more!

Big organizations will also have more subject matter experts who you can talk to. For example, while I was at HP, we worked with the airline industry within the travel sector. Here, we had a business analyst who had 30 years under his belt and who we could consult with. So, when you’re trying to learn more you can seek these people out but always make sure you have a balance, and there is user representation in your understanding of the domain

As a designer, it will always help to know more. If you take the effort to learn about the business side of things, like the market fit, knowing your competitors etc., you will have a better contextual understanding of the product. Because the usability of your product is affected by say competitors, or features in the technology.

4. Transitioning to Product Design from other design fields

For designers who are actively interviewing, make sure you get feedback and ask questions about what skills you have missing. It’s really important to go back and fix these problems and work on the skills that hiring managers have brought up.

Take note of the bigger picture: There are two considerations here; process and content. For process, what are the fundamentals of design that you have learned and practiced; what are the basic design values of another design space you want to get into; how do their values differ? Design decisions are driven by principles and values that we hold. So, reflect, go deep within and think about why you made those decisions and what fundamentals they reflect. A lot of the design justifications that you will make will all be telling of your core design beliefs.

Design decisions: Once you understand the difference in design domains and how the fundamental values change, you would be able to think about the different design decisions you would make.

Think about when folks initially transitioned from print to digital design in the early 2000s. There are fundamentals that have come from print design, like the grid layout. This may not be obvious to someone who is just starting out at web design but will be familiar to designers who used to work in print. Now, the shift to responsive design is a flexible grid layout, this in turn affects the technology. So, design is a confluence where people bring knowledge from their previous domains. Use this as an advantage by bringing more domain knowledge from different fields of design.

5. Transitioning from a service company to a product company within product design.

Working with a service-based company restricts the amount of time you get to work with a certain product, and the work becomes more transactional. That being said, there are design agencies who have worked with product companies for years and played integral roles in the handling of the product.

Skin in the game: Working in a product team means you have to live with your design decisions and know they will keep coming back to you release after release! ;) You will have the time and opportunity to deliberate a lot more on smaller details.

User problems and solutions > Midway interactions: You want to be able to have a long-term vision here, and think more about what the solution to the user problem is, as well as how it aligns with business values. Over a period of time, what matters most is being able to solve a user problem in the best way possible; that is the end result. When you’re about to put out a new release, a slick design will be less important that the product function. Although the visual design aspect is important, the business will run only if the user’s problem is solved.

Presenting your features: It’s possible that a feature you think will help is not being implemented into new releases. It then is up to you to create presentations and actively talk to different teams and present your larger vision about how your idea fits into the vision. Being able to have that determination is very important in a product team. You may have to make multiple attempts at communicating the benefit of your ideas, you may also need allies to collaborate with you, but the difference will be the energy you put into chasing it.

Over a period of time, what matters most is being able to solve a user problem in the best way possible; that is the end result. Although the visual design aspect is important, the business will run only if the user’s problem is being solved.

6. How the fellowship will teach you skills to make a smooth transition from other design fields to product design

The missing link with product strategy: Many designers will have design prowess, and be equipped with skills in illustration, visual design, and fluency with tools; but they fall short of knowing how the product impacts the user. In order to contribute to the product roadmap, designers need to be able to connect user needs with business needs. Designers are far more creative and can do more than what’s asked of them to be done! ;)

User research: This is another important skill the fellowship will impart. Most big companies and teams will have dedicated user researchers, but smaller teams with more generalist roles may require that designers conduct research as well as build prototypes. For those who come from more interaction and visual design roles and have no experience with research, they will learn to be able to learn this skill set and know enough about user research.

Aspirations: As a designer, think about the products or apps that you look at and are inspired by. For example, if you’re a designer at a major Automobile company in India, and want to work at Tesla, it’s likely that you will have skills and expertise to gain. So thinking about your personal next level will point you towards that skill set. Think about the different outcomes a high role would have. The Fellowship will give you an opportunity to address these skill gaps and focus on honing in on specific skill sets that will award you that next level. You can work with your mentor on this, as well as practice it within your project and get feedback.

These projects will teach you process. Eventually, hiring managers will look at how well you understand the process and how easily can you repeat it to different types of problems.

7. What kind of projects can learners take on? Is something like ‘next billion users’ feasible?

Focus on a specific problem: All the activities you would do would be for users in a specific domain. Even within the next billion users, pick one problem.

Ownership: This experience will differ from your college experience and learning because any work that you do is yours. It will be about how much effort you put in and how much you own your project, and work in general.

Nuance and Process: These projects will teach you process. Eventually, hiring managers will look at how well you understand the process and how easily can you repeat it for different types of problems. So you solve different types of problems, knowing the process. As you grow you will get a better handle of the nuances of processes and how it adapts to the product you want to build. If you’re thinking about the next billion users, naturally, you cannot blanket the Apple library process. You’re catering to a different user group with nuanced tech and education literacy, so knowing how to adapt those processes to these different problems is key. As a hiring manager I’m going to think, have you run the process enough and can you run the process to different content.

Consider knowing processes like knowing how to drive; you know how to drive on a straight road with no bumps. But if you have to drive a bigger car on an icy road, the dynamics change. But the driving process stays the same and you can adapt. Think of the truckers who have to drive on icy roads, they know how to drive trucks but the curveball is the icy road. So the more you know the process, the easier it will be to navigate content; whereas if you know the process only for one content it becomes difficult to adapt.

Learn by doing: The combination of learning the process with the opportunity to practice that in a real-world experience is what will eventually help you to transition.

If you’re a designer, you can join our Product Design Fellowship. The next cohort begins soon!

For regular updates, please follow us on Twitter, Instagram, and LinkedIn.