PITA 027
TOPIC 1: How do you keep user research work & product management work aligned?
Shared artefacts & conversations
Join each other’s ceremonies
Avoid terminology - shape the language deliberately
Focus on the why
Teresa Torres - weekly interviews & share interview snapshots
Force x-functional teams to ensure shared context
Review the tests/hypotheses/experiments and learnings openly
Delivery teams should observe research so they might have insights into what is actually actionable, and UR should help story writing in something like gherkin format to get them to start being more actionable
TOPIC 2: Scaling up a product team from 1 onwards, any experiences or tips?
Domain-driven design - one PM per domain/team
Make sure there’s an OKR (or similar) for each
Figure out how to manage dependencies/not get in each other’s way
Don’t just hire another ‘Mary’ - don’t get more of the same, figure out who should do what, and what the org actually needs
3/6/12 months from now - what’s working better with this person? What is the problem that needs to be solved by this hire?
Make sure they own a whole problem
You’re going to start making decisions as a team - what are your product principles? Who owns what? How do you work together? What tools do you use?
Hire for culture/experience ADD
Make sure they can do at least one thing better than you can
TOPIC 3: Any ideas on how to kindly coach people who have been used to working in certain ways, that there are benefits in exploring new ways of working? - collaboration being considered a new way of working
Success breeds success- get a small win
Solve the problem that they perceive - why will they want to change otherwise?
SHOW the benefits, not just talk about them
https://www.productboard.com/blog/change-management-5-principles
Be able to articulate WHY the change is good
There’s also a change canvas I built in Miro that you can use with a team in a workshop: https://miro.com/miroverse/change-canvas/
Canvas support in the problem people’s teams
Exec support can be key - positional power
For there to be meaningful change there needs to be first trust and rapport
Think about how to break inertia
Look for reward incentives that are at cross purposes - or that you can change
Sometimes people that act as blockers have to go
Put a boundary on how long you’re willing to invest in this
How can you change the rules so that the way they are currently working will inevitably make them fail or break the rules?
TOPIC 4: What killer thing do you do in the first two weeks of a new gig/project/stakeholder?
Talk to a lot of people, Ask a lot of questions
Do ALL the 1:1s
Ask: what’s the 1 thing we should be discussing now?
Get a list of key people from your manager
ASK: what can I do to make your life easier? And Who else should I talk to? And what can they teach me?
Don’t give any opinions at this stage
Another good read on this topic is the First 90 Days
I also asked each person on my team 1:1 to score themselves 1-5 (5 high) “Do you feel Respected | Engaged | Challenged | Inspired” and why. This was very eye opening to the culture and to the individuals.
+1 remote onboarding has been a very different experience and so much longer than being able to walk round the office and see who’s who… but also has meant richer conversations
Make a stakeholder map - and review it with your boss (etc)
Try to have the 1:1s in a different environment (where possible)
Listen in on other people’s meetings
My favourite question: If you could change one thing, what would it be
Prioritisation of questions - figure out the most important things you need to learn
Ask if your understanding is shared
Digest the research
Map the user journeys
Make an investment in the emotional bank account of everyone you meet
Variants of “Walk me through what you did last week?” Is a question I’ve found super revealing when onboarding to understand folks' context.
TOPIC 4: Any tips on working with remote engineering teams in multiple time zones?
Can you split team priorities by time zone?
Go async wherever possible - minimise meetings
Find the golden hour of overlap where people can talk, and use it well
Don’t overdo JIRA or similar to try and impose control
Board of borards is bad
If they don’t have rules/agreements around asynchronous communication, I’d set up a document around that with agreements. Basecamp has some good resources around that.
+1 on a team agreement around comms. Other tips & advice in here