In each entry in this “conversation” series I talk to a designer/product manager/engineer on a topic. I want to make basic practical skills education transparent and free.
Today I’m talking to Ryan Scott, a senior product designer at DoorDash, about how product managers and designers should work together to create desirable products that solve business needs.
What’s your experience working with Product?
I’ve been lucky to work closely with Product at some very different companies. I was Director of Product at a start-up that launched at TechCrunch Disrupt and was acquired by Docker. As a product designer at Salesforce I worked with a team of product managers to build and launch the Salesforce Analytics Cloud.
DoorDash is my first experience with a hyper-growth consumer brand. I joined the design team two years ago when there were eight engineers, three designers, and no product managers. We’re now a team of 70 engineers, 13 designers, and six PMs.
How is the relationship between Product, Design, and Engineering unique at DoorDash?
At DoorDash Product, Design, and Engineering make decisions together as peers. Product Managers are experts on business needs. Engineering Leads are experts on technical feasibility. Design Leads are experts on the customer. We believe these three perspectives are equal parts in determining what products to build and features to prioritize.
What is DoorDash’s development process like?
The whole team is responsible for identifying problems. Product Managers work with Ops to understand our markets around the country. Engineers analyze bug reports, crash reports, and performance analytics. Designers speak regularly with customers to understand their wants and needs.
When we identify a meaningful problem the team brainstorms solutions and discusses trade-offs. We consider anticipated business impact, complexity to build, and what will create the best user experience.
"We consider anticipated business impact, complexity to build, and what will create the best user experience."
Visuals help make abstract concepts more tangible, so I start mocking up solutions very early on. I get feedback on visual design and usability from other designers. Feedback from Product and Engineering is usually more focused on making sure edge cases and technical constraints are accounted for.
Depending on the project we may do a round of user research for further validation. Many times we launch features behind an experiment on one platform to quickly get feedback from users. We assess stability, viability, and desirability constantly as we ramp new features.
What do designers expect from a PM?
It’s important that PMs represent the business impact while continuing to see the big picture. Business impact is only one part of the pie. PM’s need to be able to facilitate a meaningful conversation about the tradeoffs of business needs, user needs, and technical feasibility.
Product Managers should work with Engineers and Designers to create the team’s roadmap. Engineers and Designers should be able to look at the roadmap and know what projects are coming up next and why they’re important.
Finally, Product Mangers can play a big role in facilitating organization and clarity. PMs at DoorDash help keep projects moving forward by making sure everyone knows the next steps and have clear action items. Designers and engineers spend more time focused on execution. PMs need to effortlessly alternate between the big picture and small details.
"PMs need to effortlessly alternate between the big picture and small details."
How do PMs earn the respect of designers?
So many companies don’t know how to effectively utilize designers. Great designers incorporate visual design, interaction patterns, usability conventions, competitive analysis, user feedback, human psychology, and even the physiology of the eye or brain into their designs.
"“Hey Designer, we’ve decided to build this thing, can you make it pretty?” is the worst way to utilize your design talent. Don’t treat design like a service. It’s a waste of time and money to hire experts only to have them work in a very narrowly-scoped role. The company should hire designers they trust to provide expert opinions. PMs should make sure everyone understands the problem and then engage designers in a meaningful partnership to reach solutions together."
How should a PM ask for last-minute design iterations?
Last-minute changes can be disruptive. They usually represent a failure earlier in the process (the right stakeholders weren’t involved, the team overlooked an important detail, people are nitpicking little details, etc). Keep these to a minimum.
"Last-minute changes can be disruptive."
When it does come up, it’s important to know when to give and not give last-minute feedback. As the expert on the business’s needs, a good rule of thumb for Product is to give feedback when it’s relevant to the business problem at hand. A productive conversation for a PM to have with a designer is: “The label on this button may not be clear to users, which could negatively affect our primary KPI.”
Nitpicking over details that won’t materially impact the product’s success will slow down the release. It’s not productive to give feedback on subjective preferences. Trust your design partners to make these decisions. “I don’t like this drop shadow, let’s try ten more versions” isn’t the right elevation of feedback for a PM to provide.
How can a PM productively critique a design?
Giving good feedback is often about understanding the context behind why a designer made certain decisions or tradeoffs. Seek to understand these reasons before giving feedback.
"I’d recommend becoming familiar with native and web patterns. Google’s Material Design or Apple’s iOS Human Interface Guidelines are good places to start. They contain standard conventions that designers use regularly, so it’s helpful when PMs know where those decisions are coming from."
People often think the foundation of design is art (subjective), but great design leans into human nature by embracing psychology and physiology (objective). Many design decisions leverage how the brain interprets information, color, motion, etc. I’d highly recommend product managers read the Universal Principles of Design to familiarize themselves with the science behind design.
"Finally, product managers should ground their feedback in how the design may or may not solve the business need. There are sometimes tradeoffs between what’s best for the business and what’s best for the user. Balancing those two needs will lead to desirable product and a more successful business. PMs should be able to see both perspectives and discuss tradeoffs to strike the right balance."
How do designers or PMs justify redesigning a page or feature?
I’ve seen designers, engineers, and PMs be tempted to recreate a product from the ground up. It’s exciting to shape the direction of a product and feel like you left your mark. However, this isn’t always the right strategy. It’s important to know when to be evolutionary, and when to be revolutionary.
"It’s important to know when to be evolutionary, and when to be revolutionary."
Evolutionary
Optimizations may be all that’s necessary when a product is already successful. Refinements are also less likely to risk existing success. An evolutionary approach may also be right if an underlying key differentiator or principle hasn’t changed. Simplicity and utility were differentiators that helped catapult Google to success. In 20 years, the appearance of Google’s landing page has barely changed because the desire for simplicity and utility has remained constant. A major overhaul could have violated the core principles that contributed to the company’s success.
Revolutionary
On the other hand, optimization has diminishing returns. A purely iterative approach is slow and creates opportunity for your competition. Sometimes a reset is necessary.
"A purely iterative approach is slow and creates opportunity for your competition."
When I was at Salesforce the UX team was completely overhauling the software’s decade-old interface. In the ten-years since the previous redesign technologies had evolved, new devices had been released, and customer expectations had shifted. Because so much had changed it was more efficient to work end-to-end from the top down than piece-by-piece from the bottom up.
When it comes to user experience the whole is always greater than the sum of its parts. You can’t predict the impact of an overhaul by measuring the impact of each feature in isolation. If a product is a hodgepodge of loosely-tied together features — a Frankenstein’s monster?—?overhauling the product from the ground up can be faster and lead to a better user experience.
How do you get buy-in from founders and other stakeholders?
The best way to get buy-in is to identify and involve key stakeholders from the beginning. The most effective teams I’ve worked on have one representative from each key function: Product, Engineering, Design, Ops, BizOps, and Support. Involving multiple teams helps ensure problems and solutions are thought through from multiple perspectives. This increases the likelihood that you’re building a smart solution, and decreases the chance of pushback later in the process.
What tools do designers use at DoorDash?
Early in the ideation process designers rely on low fidelity sketches and wireframes. These are a quick and accessible way for the whole team to collaborate visually. Designers should lead this type of brainstorming. Designers at DoorDash then use Sketch and prototyping tools to bring concepts to higher levels of fidelity. High-fidelity mocks make concepts feel more tangible and exciting. Product often uses high-fidelity mocks to socialize concepts and get buy-in from stakeholders.
What’s the number one piece of advice you’d give product managers?
"Not every decision can be made with data, so don’t rely too heavily on data to tell you what to do."
The team should have conviction to make decisions on concepts, and then use data to inform the execution. “Should we communicate transparently with our Drivers?” isn’t a question you should approach with data. You’d waste a lot of time tracking retention or NPS trying to assess the value of an abstract concept like transparency. When the results came back inconclusive you’d be right back where you started. The answer to whether to be transparent is yes. You only need to speak to a few customers to validate this concept. Whether you communicate through email or SMS to achieve a specific metric is a question of execution. That’s a better test to run, and a better place for data to influence your direction.
"It’s also very important to know when data invalidates a concept versus invalidates the execution."
Conversion at eBay dropped when they first added photography to their site. Some interpreted this to mean that adding photos wasn’t the right strategy. It turned out that the images had significantly increased page load time. Having photos was the right strategy, but was almost abandoned because of poor execution. Reduce the risk of throwing out good ideas by questioning whether data disproves a concept or whether it’s the execution that needs refinement.
This article was originally published on Romy's Medium page.
