Christian is joining us from the lands of the Muwekma Ohlone Tribe.
"Why is a product manager telling me what to do?"
Christian was being recruited for Yahoo in their platform design team — what happened was one of the PM's passed on him because he was too senior and wouldn't do what the PM wanted.
He ended up taking a job as a pattern library designer.
But he left scratching his head about how you would work with PM's.
He went on to release a book, and move on to Patch, ClousOn, AOL
When working in the tech companies Christian often played a role of upskilling the organisation to newer ways of working.
He ended up travelling to New York to project manage the new Patch project
Doing this product work Christian was lit up and exhilarated working in product
He got sick of AOL and bureaucracy and moved on to a start up CloudOn, making a document editor for tablets.
Sold the company to dropbox, and felt way closer to shipping and being closer to delivery.
7 cups was his next start up, where he took on the VP of product and grew it to a profitable company.
Then 2019 came out as a consultant to help companies build their product practices and build their teams.
Then wrote a book during covid — and has another one in the works
Christian worked on an MIT project for a non surveillance oriented covid tracking solution.
He then went to Californian Government to help with their covid website.
They were trying to figure out how to visualise the variant data — they used usability testing to find out people only knew how to read the line chart — which they brought back to leadership and shipped.
Christian is now the Product Lead for the Office of Data (something :|) for California on a project about reproductive health which he can't share at the moment.
What comes to mind is a mid 20th century mass manufactured physical objects
@davegray The product metaphor has it's value, but it can be a bit confusing.
Product Managers sometimes like to use this venn — it can be helpful, sometimes they do deal with these things.
@davegray The problem with that is that everyone has their discipline at the centre with everyone around them.
This is Christian's favourite meme about his profession.
@davegray Peter Merholtz has been using this diagram — it's a bit better, but UX and PM's aren't doing the same tasks.
Unless you're in a company with not enough people!
Christian's favourite diagram is Joff Redfern's
Most people start off in one of these corners but not fully rounded in in all these. For a PM to be good they need to head toward the centre to balance the perspectives.
Sometimes PM's are spoken about as Decision Makers.
Generally PM's don't have the authority to make all the decisions. They often after to build consensus.
They often sit at the centre of the decisions so it's important for them to find the people who need to make the decision.
As Christian's grown he's learned he needs to let the team make the decisions and trust in their expertise.
Sometimes you do have to make decisions, and not all decisions can be correct, so you hope to learn from making them on smaller problems!
Where ever you start in the cycle you're going to go round and round.
There isn't a lot of time actually dedicated to learning a lot of the time :D
PM's have to manage a lot of engineering decisions and be accountable for whether it can be done or not.
UX people can often have more room to step back from the end decision.
PM's are responsible for keeping the project on track and delivering. It can be really hard not to explore the tangents and exciting new items.
PM's aren't a lot of people's bosses, so they spend a lot of time persuading and being diplomatic.
To find out what the focus should be and then get everyone aligned on that focus to get the job done.
So where are the pain points working with PMs?
Struggle to influence product direction
Flow and definition of requirements is contentious
Design and research work can feel like speaking different language
Prioritisation is opaque or disjointed
The reality of work doesn't often match the ideal needs
We all have unexamined assumptions about each other's roles
The lack of thorough alignment leads to friction in day to day work even when leadership supports cooperations
We haven't had enough conversations delineating the different roles and how they're actually functioning in a project.
There's often not enough process in companies to help clearly define these roles.
The work of designing how we work is very important, and people don't often want to focus on it. It keeps changing. It will always change.
If you change people's role titles you need clearly define why the change has happened, and what it means about the way they work, or help work through a process to help the team define that themselves.
[end bummer bit of Christians talk]
He gets a lot of people at conferences come to him a bit gutted about the new PM role overshadowing the work they were doing.
Christian remembers when UX came up and replaced IA, then turned it into a small part of a new process. The same now with Product Design and UX
So what are your superpowers as a UX designer, and how can you use them to creatively solve problems.
We have a huge amount of techniques we can lean on to change how other people understand and shape a vision in a way that is understandable and exciting.
Our research, synthesis and systems thinking — our Information Architecture and Content strategy — our ability to gather the what and the why of our contexts — prioritisation and contextual framing are all ways we show up as expert problem investigators!
UX design are very good at focussing on granular details and huge systems all mean figuring out how we can work together is amazing.
There's a very grey area about where the 'line' is for PM and design work — you have to have some lines or you step on each other's toes.
The tasks need to be done, and it's healthy to know who's taking care of them.
The people who've figured this out, have done it for their team, and it often needs to be redesigned when teams change or when you move companies.
The behaviours need to be explicitly spoken about and know who gets to make the final decision.
Get those assumptions out in the open!
Christian often does a card sort with teams to identify where the different tasks sit.
The places you disagree on are where the hard work has to happen.
You don't have to agree on everything.
The best thing about agile is having the team reflect on how they worked and what they could change next.
The most controversial area is user research and customer understanding.
There's a lot of potential for being at cross purposes for research. It's important to work through it and compromise where you can.
If you can create an alliance piggy backing off each others research and try and help each other.
Being able to visualise models and concepts are incredibly valuable artefacts for teams to debate and use for deep conversation.
Define and clarify the content that comprises 80% of the UI and the surrounding concepts
Christian doesn't like 'Data Driven Design' he wants 'Data Informed Design'
Use it to steer, don't take it without any context. People project reasons for why data exists and think they're truth.
If you're in UX you've done prioritisation.
They built a feedback page, then added it to the design library so other people can go from zero feedback to page specific feedback.
Productising tools for other people is a lot of work
This was a quick a dirty roadmap exercise
Use your skills on how you DO the work.
Think of the PM's as your customer, and try figure out their problems, and how you can fix them.
We don't have to do it all, but we can definitely use our skills to help our teams!
Always reflect on how you're thinking about the people you work with the closest.
Notice whether anything has changed, even if it hasn't that's super interesting!
@corey_tutt@DeadlyScience Corey's presentation may contain images and voices of people who have died.
@corey_tutt@DeadlyScience Deadly is a form of slang that Aboriginal and Torres Strait Islanders use to say things are cool, so when you hear deadly science think cool science but better.