How to be the Product Manager UX designers love | by Garrett Rysko | Apr, 2023

It’s spring 2020, with Covid-19 in full swing, cities all over Europe are tentatively trying to emerge from lockdowns, despite social distancing and having to avoid public transportation. People are looking for easy ways to get to grocery stores, get some exercise in, and get out of the house so they don’t have to hear their Nan complain about Boris Johnson’s blow-out while they doom-scroll about toilet paper shortages.

Europeans were able to scratch that itch in droves by grabbing an electric bike for every member of the family, causing the biggest surge in electric bike sales the market has seen to date.

Months prior to this COVID-driven electric bike surge, the Product team at the Dutch-based electric bike company VanMoof predicted this meteoric demand of electric bikes, and knew it was time to scale.

The product team did three critical things at the same time:

1. they released their S3 and X3 bike models at a significantly cheaper price point, with all new features
2. they created a channel to sell direct-to-consumer so they could own design to production to sales to after-service, and
3. they put the right people in place to secure funding to scale their business, successfully securing $13.5M in funding in May 2020.

Well their predictions paid off, with the UK government creating a 2billion pound package to incentivize cycling and walking — VanMoof saw their profits triple from their predicted 40M to 120M that year, and subsequently secured two more rounds of funding totaling $168M.

How did Product teams at VanMoof and many other companies predict what their customers want ahead of big market trends? What research and insights made this possible? And how did product managers work best with their UX research & design teams to make those big wins? Let’s find out.

1. Sit down and shut up! (Stay out of their way)
2. Understand the design process
3. Bring UX into the customer meetings and product process EARLY

The first and most important thing you can do with your design team is… to sit down and shut up!

Of course I’m only half serious… you do need to voice your opinion and evaluate the amazing research & design work your team is doing to give the best experience to your users, but that is secondary to the most important thing you can do, which is to block and tackle for your design team so they can do the best job possible.

If any designers are reading this, raise your (virtual) hand if you’ve heard a Product Manager say,

“oh but can we move that button to the left instead of to the right? It just makes more sense!”

or the infamous,

“can we just make this design ‘Pop’ more?”

Your job as a product manager is to manage the risks of shipping a product. So you don’t want to roll the dice on if your customers will love your product when it ships.

Different people own different risks when shipping a product

1. Business Risk
2. Value Risk
3. Feasibility Risk
4. Usability Risk

You as a PM own two of the four product risks, while the remaining two are owned by your respective design and engineering teams. Of the four product risks there is the value risk, the business risk, the feasibility risk, and the usability risk.

• You own the Value risk — or are we delivering something that your customers truly need and will invest time/money/effort into.
• You also own the Business risk — or are we building something that makes us money/grows the userbase/increases our engagement.
• The feasibility risk is owned by the engineering team and is all about delivering the product, with high quality, in the time that we have, with the team available (covered in a previous article!)

Usability Risk

The last risk is the Usability risk, which is all about making sure we’re building a product that our end-users can naturally discover, navigate, and interact with in a frictionless way — or… are we building the right thing for our users? The usability risk entails:

• Ensuring the product is easy for users to discover, navigate, and interact with the product
• Your Design team is responsible for addressing this risk
• Your job is to give the UX team time and space to do their best work
• How can you help? Listen more than you talk in meetings, to support the design team. They are good at their jobs, and it is to handle this risk.

Asking Questions & Making the Right Decision

Your secondary priority as a Product Manager should be all about listening to insights from your design teams so you can make the best product decisions possible — whether its during a voice of customer research rollup, listening to competitive product insights from the design team, or reviewing a new paper prototype from your UI designers.

If you do this, you will be the PM that hits differently than what UX teams are used to!

So what are those questions?

Your goal in listening is to get informed on the process so you can probe one level deeper on the research that was done, for example:

One group of questions I typically ask is about design choices, like

“for the inventory page of our coffee storefront, what research was done to use infinite scroll instead of pagination?”

“what research led us to using a slider bar instead of a numerical input for the number of days a user wants to stay at our bed and breakfast popup?”

The goal is to probe a level deeper into what the design driver was, so I might ask questions on

“was there a voice of customer session that explained the complexity out of a previous mockup?”

“was A/B testing done to inform this decision?”

“Is there a competitive product that is designed in a way that users are already comfortable with?”

• Another set of questions I ask is about research logistics — I would ask questions around do we have enough people, time, expertise, and willing victims, er end-users, to gather the information we need to make the best product? The goal here is to set your team up with enough time and resources to do their job, while also time-boxing the work done & setting an expectation for the team.

My Product Manager friend recommends using the time-tested strategy of avoiding things like declaring “I think we should do X!” and instead phrase your feedback as a question that leads them to think the way you’re thinking

— for example, for your exotic online coffee roastery, you wouldn’t say

“this workflow of interrupting their coffee checkout experience with a rewards popup makes no sense, this will annoy customers into skipping checkout entirely!”

you would instead say

“How do you think end customers will like our coffee checkout experience?”

Again, you want to ask these questions to make sure the usability risk is being managed by the team and that they feel ownership, and you want to do this without micromanaging your UX team.

During this question/answer process I also use this opportunity to give the team business justifications on why an ask is important.

So remember to take time to listen and ask valuable questions, give time back to your UX team to get their best work done, and avoid making Danger your middle name by addressing usability risks early in the process.

To ask the right questions and speak the same language as your UX team, you should know what their design process is.

Reid Hoffman famously said “If you’re not embarrassed by your product, you shipped it too late.”

Of course he didn’t mean to blindly ship your product early and hope for the best, what he was trying to get at is you shouldn’t wait to deliver unto your customers a perfect golden goose product after years of development, and instead you should get your product into your customers hands early and often, so you can test product fit and iterate rapidly.

Nothing is worse than spending multiple quarters building something your customers don’t want. The design process is specifically made to prevent this by asking questions, testing with users, and iterating rapidly.

Design Framework — Double Diamond Design

Double Diamond design is a framework used by UX teams to gather many options without pre-judging any of them, and then rigorously winnowing them down to just the few best options. The process is broken into two phases: Discover & Define, and Develop & Deliver.

• In the Discover phase, UX researchers identify real pain points and create use cases for the product.
• In the Define phase, the team narrows down the use cases and pain points, creating an Experience Outcome or User Story.
• In the Develop phase, visual designers develop multiple low-fidelity mockups for the selected use cases.
• The final Deliver phase involves refining the possible mockups down to just one, and creating a pixel-perfect design to be provided to the engineering team.

The goal is to create the best possible design to address user needs.

Note: As a PM, you’ll want to be deeply involved in creating use cases, typically in the form of “As a, I want, so that…”. For example,

“As an end-user concerned about indoor air quality, I want to see what I have been breathing in the past day, so that I can make changes to my homes cleanliness and improve my air quality.”

What happens when you neglect UX research…

Throughout this process you should be continually iterating in front of your friendly customers and subject matter experts to ensure you’re building the right thing.

Skipping this step can lead to a flop of a product… potentially stalling out or killing your product. A perfect example of this is Tesla’s steering yoke design on their Plaid model S.

• If you haven’t seen Tesla’s reimagining of the steering wheel on their Model S Plaid, at first glance the yoke design looks fantastic — giving a clear sightline of the road, is streamlined, truly different, and lets drivers feel like they’re driving an F1 performance vehicle, which is where it’s yoke design comes from.
• But as reviewers started to get their hands (quite literally) on this new design, negative review after negative review came out. Reviewers couldn’t quite put their finger (yes pun intended) on why it was bad but they knew it felt weird to drive, wasn’t usable, and felt like an experiment in form over function.

Well as it turns out their gut feeling was correct. As some internet UX researchers pointed out, In an F1 vehicle the wheel is designed for much smaller and higher precision movements, and usually can only be turned about 200–300 degrees, never having to do a hand over hand motion.

Whereas on traditional cars the full range of motion of a normal steering wheel is about 900 degrees… This means you have to do about 2.5 hand-over-hands.

With a circular steering wheel you will always have something to grab when doing a hand over hand, but with a steering yoke… the tesla product and design team neglected to solve for this hand-over-hand problem, giving us the goofy criss-cross applesauce yoke move you see on the Plaid.

For Tesla they’re making enough money to potentially float this problem, recall cars, or fix it in the next model, but for many startups this could be the death of your product, especially one as expensive as a car.

So how do you head this problem off at the pass and not repeat Tesla’s product team goof up?…

This might seem obvious, but the best way to build the stellar products is to get it in front of users early and often!

A lot of product managers are hesitant to do this because they’re afraid of negative feedback… they think negative feedback is a failure of the product, their team, and ultimately their vision for the product.

Negative feedback is not a failure of the product, the team, or the vision of the product.

• It’s critically important to get over that fear of failure and to get your product in front of customers often, as the best products are forged in fire — used by many customers and iterated on.
• It’s critical to bring your UX team into as many customer conversations as early as possible so they understand customer needs, pain points, and their reaction to the product.

Usability Testing

Sometimes a PM will join and assist the UX team in doing Usability Testing, if you happen to get the call to help, here’s how you would conduct one:

• Typically these interview sessions are structured so you have 2 or 3 people on your team interviewing the end-user, where one person has the role of asking questions, another has the role of facilitating any demos or mockups the end user will see, and the last person will be a dedicated note taker.
• This type of usability study is very valuable to catch explicit challenges your participants comment on, like “so am I supposed to click this checkout button to see my cart?” or “I’m not sure what happened here, was the next page supposed to load?”
• Usability studies also capture end-users implicit pain points, like when you see them moving the mouse often over a price label that they thought would have a hover-over, or are struggling to figure out the next step in a confusing 5 step wizard.

Fly on the wall in Engineering Meetings

Another process I bring my UX team into is engineering meetings, such as scoping or design meetings. I usually set expectations by telling them they can be a fly on the wall — as it’s awesome when UX joins these meetings because they will catch things we didn’t even think of.

I can’t count the number of times where engineering will say something like “well if we can just reduce risk by cutting out this design aspect, like removing the custom time picker, then we can deliver so much quicker!”, and the UX designer will jump in and let everyone know how that will impact the user experience in ways we didn’t think about.

Including your UX team throughput the product process as a valued asset and leader to drive the business forward, is necessary to envision features, to spot gotcha’s, and to piece together the future product holistically. Good designers naturally understand gestalt, that objects are more than the sum of their parts.

So if you want to get to the place where you’re like the product team at VanMoof, where it looks like you’re predicting problems and trends before they even happen, its important you

1. Give your UX team the space and time they need to build the best thing
2. Understand the design process, so you can be empathetic and ask intelligent questions, and
3. Bring your UX team in early and often to get hands on with the customer, as rarely does the product we dream up end up being the thing we ship

Reid Hoffman, Co-founder of LinkedIn, would say you as a PM need to be a Predictive Anthropologist… you need to predict people’s wants in the future, and deliver it to them before they get there.

And with that, you can take away 3 strategies on how to be the PM your UX team loves, if you have questions or need help, let me know!

Reach out to me at gmrysko@gmail.com if you or your team is looking for product consulting & training — I love jamming with folks on PM learnings!

If you had a good time reading this post, why not consider subscribing to Medium or to my YouTube channel. You’ll get access to limitless content that can help you level up your Product Management and business skills — all without burning a hole in your (virtual) wallet.