I really like rituals. I mean, regular meetings that remind us to do something that doesn’t happen naturally. Sharing cross teams is is a great example, everyone does agree that it is great to share and inspire each other but it is something that we don’t always remember to do.
In 2022 we started having more of a common ways of doing product discovery at Hemnet. All product teams started using the Opportunity-Solution Tree to visualise and keep track of their discovery work. Most teams were forming a product trio or quad to be able to make faster decisions and put sufficient focus on discovery. I wrote about what we did here.
Product discovery is hard and messy and there’s a lot more to into than you can learn reading Continuous Discovery Habits (awesome read). So also in 2022 we set up monthly sharing sessions for all product teams to share and discuss their product discovery challenges. These sessions are some of my favorite meetings.
Everyone is welcome to join but the usual suspects (and explicitly invited) are the members of our product trios/quads (PM, UX, software engineer, digital analyst), our development managers and our CTO. One hour, usually about 20 people and with myself as a facilitator.
The format has evolved. We started off using a lean coffee format, discussing different topics people care about in smaller groups. Some examples:
What work to do in a product trio and when to involve the whole team?
How does the Opportunity-Solution Tree relate to the team backlog?
How to make discovery work stay alive in delivery-heavy phases?
How to involve outside team stakeholders?
How to set better OKRs?
We ran this format for a year or so, had some great relevant and positive discussions. Attendance was high and attendees really liked the sessions that created a feeling that they are not alone in their challenges and getting inspiration from others. But they were lacking more hands-on examples and more going deep into the sharing parts.
For the last half year or so we have been focusing a lot more on sharing and less discussing. Every session consists of 2-3 parts where people share something they struggled with or tried out, followed by a shorter discussion. It should not be too prepped to have a low threshold for sharing. Like getting a glimpse into one of our teams and their discovery work.
I also post a heads up before and a short summary after for maximal FOMO.
These sharing-focused sessions have been even better. It’s still creating that feeling of ”this is not easy”, we have common challenges and can use each other more. But trios/quads are now also getting more hands-on tools to speed up their value delivery.
Thank you all amazing people for sharing and caring!
Continuous product discovery and empowered teams. Teresa Torres and Marty Cagan. It sounds so good and it really is (if you have the right prerequisites but that is another story). But like any concept, having cross-functional empowered teams with continuous discovery habits working doesn’t solve everything.
In my experience, one big challenge is the scope of product discovery. Even awesome product teams will struggle if the outcome is too big and fluffy and long-term, requiring big strategic shifts. These big shifts often require different mindset than those we usually (not always) have in a product team or trio. The mindset and scope is more what’s best for the whole company and less what is in the team mission.
So, how can we get better at working and aligning on the long-term while still keeping focus on reaching current (half year in our case) goals?
This is a big hairy problem I’ve been working on for some time now. Before summer, I wrote (in Swedish) about our efforts to work on a research roadmap and set up a 360 research team focusing on longer-term, broad research from different perspectives. We did some good and valuable work that gave a lot of new insights but it was a bit disconnected from the overall priorities. Because in parallel with the research roadmap, the different teams and product managers were creating the actual product roadmap.
So during the last few months we are trying a new approach. But first – let’s start with the why.
Why roadmaps?
When I write roadmap I do not mean a fixed plan with specific features or delivery dates (even though this can be a part for near-term initiatives). I mean a shared source of truth that outlines which rough areas/problems we currently think we are going to work on during the future years to drive our strategy and get closer to our vision. It is definitely something that will change as we go, particularly for the areas further into the future.
Our teams and departments are focused on different goals and different aspects of driving our strategy. The roadmap is supposed to be a conversation starter so that we can better optimize for the future. By finding future synergies, conflicting goals or unknowns that we need to start addressing early.
I have not always been excited about roadmaps. They can definitely be a waste of time. Promising too much and too specific stuff too early, avoiding change or creating a feeling that everything is already decided, pushing people to deliver on a set but not necessary deadline.
But done right, the roadmap can enable us to work more together on important future shifts. And help us shifting focus so when we are knee-deep focusing on our shorter term goals, we still spend a little bit of time thinking about what lies ahead.
The improved approach to roadmaps
We’ve had roadmaps for some time but talking to our product (and other) leaders it became apparent that things could improve:
The current roadmap was not really used to talk about the future cross teams
It was updated when needing to show something, sometimes leading to short deadlines and stress
It was hard to find the latest updated version of our roadmap or context around future areas
Some parts of the roadmap needed more investigation or prep work to start working on but it was not clear how to initiate or do this kind of work
Our improved approach consists of two parts.
First off, we want to have a shared source of truth. A place where we keep our roadmap along with the goals they are driving and context like supporting data, intel from peers and user research. We started using a pretty simple Jira board for this, consisting of roadmap items with rough timing and some information like goals and user needs.
Secondly, we need to have someone driving the roadmap work. Supporting the product leaders, the teams and departments with gathering ideas for the future, gathering the knowledge we have of these ideas and when needed do some early research work. We call it the roadmap support team which currently consists of our UX Director (me), User Research Director, Business Developer and Director of Technology. The idea is to have something like a product trio (that we use in our product teams) bringing different perspectives to our broad and future looking work.
We tried this setup for a couple of months and so far helped one of our areas generate ideas for the future. We are also working with all product leaders to generate a ”good enough for now” first version of the roadmap that we can keep iterating on.
Learnings so far
Some challenges and learnings so far with this new approach:
Product leaders and teams appreciated the roadmap discussions that the roadmap support team initiated. They are important and might not have surfaced otherwise.
People have different understanding and attitudes towards roadmaps. It is super important to always be clear about what we mean by roadmaps and what they are for. My new roadmap slogan is ”Roadmaps – makes people talk (about the future)”, a reference to an old Läkerol commercial.
When and how to involve the product teams? We want to avoid doing a lot of work in roadmap support separate from the teams, to avoid hand-offs, because the teams have a lot of knowledge about their domain and we do not want to take away engagement and empowerment. There is a need for a lot of transparency here with what’s being done, and always keep thinking about how to involve in a smart way.
Who decides? Roadmap support sometimes felt like a proxy between PMs and leadership. We need to be more clear about what the decision process looks like, who and how.
How much time to put into roadmap work? If we do too little, it will be too much guesswork. But if we do too much we can risk creating waste since things can change. There is a bias to want to learn more and more and more before deciding what should be on the roadmap and a constant feeling of ”we don’t know enough”. I think a solution is to time box but also to always be super clear that roadmaps are supposed to change as we learn.
This year we did some work on UX skills and sharing to encourage growth and knowledge sharing. We defined and worked with a list of UX skills relevant to Hemnet. Nothing new or revolutionary about this. But I really love the hands-on kind of content hopefully this could inspire someone in a similar process.
Why UX skills?
We have a UX team of generalists where everyone is comfortable with everything from explorative research to UI design. But everyone have their strengths and weaknesses of course. Which makes it important to work together, use each other and do a lot of knowledge sharing.
Also, since the role is so broad it can be hard, particularly for someone new, to know in which area they can grow.
And lastly, the ones of us in leadership roles lead designers in different settings. I work a lot with the settings where all designers work together but see less of what’s happening in our product teams where the designers spend the majority of their time. Our development managers on the other hand are in the team rituals but don’t see what is happening in the UX forums. To help people grow we need some common ground and the idea is to have the UX skills list as an interface between leaders.
Producing the UX skills list
During June this year we had our first ”UX day” – a whole day with the UX team at Långholmen island in Stockholm (which happens to be a nice location very close to my home). Half of the day was dedicated to UX skills, we did a workshop to:
Decide which skills we consider most relevant to us and which ones we should focus on getting better at
After the workshop, I summarized everything in a sheet, wrote a little description for each one and sent to the group for comments. A couple of weeks later, we went through comments and questions and finalized it in our UX forum. Here are the UX skills we defined, grouped into three main areas:
Using UX skills to boost knowledge sharing
So now when we have this (long) skill list, how can we use it?
Market of skills is one of my favorite exercises to boost knowledge sharing. You can find a lot of different articles about it by googling. Basically:
Everyone builds their own ”market” consisting of the skills they have and could share to others, and the skills they would like to learn more about
Everyone presents their skills and their desired skills
Everyone agrees on skills they could share with each other and decides how to do it
We used the UX skills as a starting point for the market of skills workshop. So instead of just listing skills, you could use the already defined UX skills but also list others skills that may not be core to a UX designer at Hemnet. Here are two examples of how the result could look:
We used Miro for this workshop. Side note: I really love the Avataaars feature where you can create quick avatars for yourself which can make things feel more personal and fun. We also use it for user research, create an avatar for each interview person and they will be easier to remember without GDPR issues.
The outcome of the market of skills was a series of knowledge sharing sessions on different topics. When I write this, we are in the middle our regular competence day where we have sessions about both Behavioral design and Workshop facilitation.
What’s next?
We will continue using the UX skills for knowledge sharing but also for recruiting, to define what skills have should focus on strengthening. They are also known by other leaders and will probably help going forward to improve how we work with individual development.
Vi är rätt jäkla bra på research i produktteamen. Våra UX designers är bra på att träffa användare för att förstå och utvärdera, vi gör enkäter och olika typer av experiment för att validera våra antaganden när vi bygger nya och bygger vidare på befintliga produkter. Alla produktteam har en dedikerad UX designer och nästan alla har också en dedikerad digital analytiker som analyserar användarbeteende och experiment.
Men produktteamen fokuserar på att nå sina mål som är på halvlång sikt (0.5-1 år). Den bredare, mer långsiktiga researchen och discoveryarbetet som inte är kopplad till något speciellt team är svår att få till. Vad vet vi och vad behöver vi veta för att kunna prioritera rätt nästa halvår, nästa år eller ännu längre fram? Jag har kallat den typen av research för taktisk (input till våra långsiktiga opportunity roadmaps och kundresor) och strategisk (input till vår övergripande strategi).
Produktteamen och våra product trios fokuserar oftast på den operativa nivån (som handlar om att utforska och lösa våra användares behov här och nu) men gör också en hel del jobb i det taktiska.
Side-note: Tycker egentligen det är svårt att prata om strategiskt/taktiskt och det går inflation i de här begreppen. Men jag behövde något att prata om och det här var det bästa jag kunde hitta.
En liten sak vi lagt till är ett nytt regelbundet möte där alla UX designers delar sin breda (taktiska) research den senaste månaden, och vi tillsammans uppdaterar våra kundresor med kundbehov och problem. Det har funkat rätt bra, våra kundresor är mer levande och vi blir bättre på att dela lärdomar och inspirera varandra att göra bredare research.
En annan sak vi testat för att göra mer av taktisk och strategisk research är att prioritera researchområden och sätta ihop ett litet researchteam med kompetenser från olika avdelningar.
Research roadmap
Vilka är de mer långsiktiga områden vi skulle behöva lära oss mer om? Som ett första steg samlade vi några personer från produktledning och affärsutveckling som idag jobbar mer långsiktigt och strategiskt för att generera researchområden.
Vi utgick från hela vår strategi och försökte hitta områden som dels behövs för att göra vägval kring områden vi redan jobbar med, och dels områden som är ännu bredare och kopplade till trender i samhället och världen.
Vi landade i 12 potentiella områden och hämtade sedan input från våra product managers kring vad de ser som viktigast. Till slut landade vi i en prioritering som vi presenterade för några personer i ledningsgruppen och fick tummen upp på att sätta igång ett litet initiativ kring ett högt prioriterat område.
360 research-teamet
Vi satte ihop en grupp bestående av fem personer från olika avdelningar. UX researchers, affärsutvecklare, affärsanalytiker och säljchef. Gruppen var anpassad till området, den hade sett annorlunda ut om vi hade valt ett annat område och hade t.ex. kunnat inkludera inkludera marknad, teknik eller support. Poängen är att vi ska ha med alla relevanta kompetenser, insikter och perspektiv för området vi gräver i och gräva genom olika typer av research. Som klassisk kvalitativ UX research, affärsanalys, beteendeanalys eller marknadsundersökningar.
Vi avsatte en veckas intensivt arbete (i förra veckan) för att fördjupa oss i området och få in så mycket kundintervjuer och dataanalys som möjligt under veckan. På slutet gjorde vi en liten utvärdering av hur arbetet gick.
Vi gillade alla att jobba tvärs avdelningar och med olika perspektiv, fokuserat tillsammans och vi lärde oss en massa. Engagemanget var högt, alla i gruppen såg verkligen nyttan av det här jobbet och gjort ett fantastiskt bra jobb.
En utmaning var att hitta en vettig avgränsning. Området vi började gräva i hade lätt kunnat bli ett tolvmånaders researchprojekt. Vi lyckades hitta en hel del mönster i data och intervjuer på en vecka men fortsatte lägga en del tid efter för att knyta ihop säcken. Viktigt att från början definiera ett mål som både kan bidra med värde och är realistiskt att hinna med.
En annan utmaning är det klassiska problemet när man avsätter tid för att fokusera på en grej. Annat dyker upp som konkurrerar om ens tid och det är svårt att verkligen fokusera.
Sen då?
Det här är rätt färskt fortfarande och en viktig del återstår. Att kommunicera resultaten och se till att de landar hos de som skapar värde, alltså våra produktteam. Jag hoppas att vi kommer bygga vidare på den här processen, fortsätta göra den här typen av fokuserat researchjobb tvärs avdelningar framöver och bli lite bättre på att bli lite klokare varje dag.
I vintras skrev jag om hur vi skapade en experience vision – en historia om vilket värde vi vill leverera till våra användare på lång sikt. Vi byggde en historia om målgruppen konsument eller besökare, alltså vanligt fölk som köper och säljer bostäder och hänger på Hemnet. Visionen används numera i onboarding.
I förra veckan började vi bygga på en motsvarande experience vision utifrån mäklarperspektiv. Mäklare är en superviktig målgrupp för oss och vi tänker att den kan ge ännu mer värde eftersom alla medarbetare kanske inte har full koll på vad en mäklare gör, tänker på och hur vi kan skapa värde.
Upplägget såg ungefär likadant ut men jag tweakade några saker som jag gärna vill dela, extra mycket eftersom jag hörde att andra företag har läst och använt för inspo till sin egen experience vision. Väldigt kul!
Vad vi gjorde annorlunda den här gången
Vi gjorde på ungefär samma sätt som sist, med några skillnader. Utgick från vår kundresa för mäklare och vår strategi, definierade upplevelsemål för mäklare – vad vill vi att mäklarna ska uppleva när vi lyckats med vår strategi? Vi körde en workshop med några fantastiska människor med en massa mäklarkunskap. Den här gången två product managers, en user research director och en copywriter.
Mäklare skiljer sig väldigt mycket från varandra vad gäller behov och förväntningar på Hemnet. Så för att se till att storyn innehåller en bred bild av alla olika typer av mäklare lade jag till en grej. Jag förberedde ett antal dimensioner som kan påverka hur mäklares behov skiljer sig från varandra. Till exempel hög/låg konkurrens lokalt? hur datadriven är man? hur relationsorienterad? hur lång erfarenhet och hur stor kundbas?
I workshopen fokuserade vi dels på upplevelsemålen och behoven kopplat till dem, dels på dimensionerna. Utifrån dimensionerna hittade vi på två huvudkaraktärer med helt olika behov som speglar hela branschen och olika typer av mäklare hyfsat väl. Personas, alltså.
Sist spånade vi också tillsammans på en story och började visualisera den. Jag märkte att det tog lång tid och det var svårt att dela upp det arbetet utan att historian blev spretig. Så den här gången tog jag workshopmaterialet och började skriva på ett manus på egen hand, i ett textdokument. Det gick rätt snabbt och jag kunde dela manuset och få feedback på hela storyn redan efter någon dag. Jag tror det här blev klart mer effektivt och förhoppningsvis en bättre och mer sammanhållen historia.
Sen då?
Vår experience vision för mäklare är långt ifrån klar men vi har en första version av manus och jag är säker på att det kommer bli skitbra. Stay tuned!
För ett tag sedan skrev jag om ritualer. Alltså inte mystiska trollformler utan återkommande aktiviteter (som en daglig standup). Vi gör dem för att komma ihåg och uppmuntra ett visst beteende.
För knappt tre år sedan började vi med en ny ritual. Vi ville bli bättre på att prata med användare, vi ville göra det ofta och vi ville ta hjälp av varandra att rekrytera eftersom det var jobbigt. Lösningen blev konceptet Feedback Thursday – en dag dedikerad till att prata med användare varannan vecka, för alla designers. Vi satte ett schema för ansvar för rekrytering, och vi hittade på ett sätt att hjälpas åt att anteckna i en gemensam Miro-bräda. Vi planerade inför varje intervju så varje designer som ville kunde få en slot på 10-15 min.
I förra veckan kom vi fram till att pensionera konceptet Feedback Thursday (även om vi behåller vissa delar).
Vi gör mer användarintervjuer än någonsin, men vi sprider ut dem mer över veckan – inte bara torsdag.
Eftersom vi gör så många intervjuer blir det bättre att fokusera på ett område i taget istället för att dela upp varje intervju mellan våra designers. Både för oss och för respondenten.
Samarbetet kring att ta anteckningar behövs inte heller lika mycket – engagemanget kring användarintervjuer hos andra i teamet har ökat så det finns ofta en product manager, analytiker eller utvecklare med som kan hjälpa till.
Rekryteringen går smidigt.
Vi har lyckats! Ritualen behövs inte längre. Beteendet och engagemanget kring användarintervjuer finns där, i våra teams ryggrader. Precis som det ska vara.
My posts usually don’t assume much previous knowledge. This one does, so if you’re not familiar with continuous product discovery Teresa Torres style, then read Continuous Discovery Habits (it’s great) or her blog posts/talks.
Product trio sharing and caring
During the autumn I started hosting monthly product trio sharing sessions with our product trios. The purpose is to share and together get better at continuous discovery. Now when all our product teams are working this way we want improvements not just to stay in one team when they can benefit everyone. Plus I think talking about continuous discovery is strengthening our trios confidence.
We usually start out with some trio sharing an insight or a change they tried out, then we do lean coffee discussions.
Not prioritizing generative research
I want to share what came up in yesterdays product trio sharing session because it was great and I think resonated with almost everyone.
One of our trios shared how they worked during the autumn, doing really great work with solution discovery and assumption testing. In the end of the year 2022 they had come up with a great solution to a real problem and was well on the way to deliver it. But then came the planning process for the next year, where the team were to set their OKRs for 2023, guided by the company strategy. They struggled with this because the focus had been on solution discovery and finding out what works to reach their goals, not talking to users to find opportunities. The team realized they need to work with generative research and finding opportunities all the time, even though this might not necessarily contribute to their current goal. If they don’t, they risk ending up in the back seat and miss a lot of good opportunities that could really help the company grow.
There were a lot of recognition among the other trios. As we have adopted a continuous discovery mindset, we have become really good at assumption testing. We meet users a lot, to understand their needs connected to specific solutions and to do usability testing. But we struggle to make time for the broad and generative research to find new opportunities.
Why does this happen?
There may be several reasons behind this.
At Hemnet we set OKRs each half year and teams are really motivated to deliver on their goals. This is great. But in our ambition to reach the outcome it is easy to forget that after we have delivered, we need to set goals for the next half year which requires us to really know the user and the business. Generative research is not prioritized because we are so keen on delivering on our time-bound goals.
It can also be a problem of narrowing down goals/OKRs too much. If the outcome is almost pointing out a specific solution, there is not much room for generative research. This can become a negative spiral. Management sees that the team don’t really know their users so they suggest narrow goals. The team don’t feel that there is room in their goals to understand their users better so they de-prioritize generative research and it goes on.
How to fix it
Some ideas that came up on how to fix this:
Make discovering new opportunities an explicit responsibility of the product trio – we want to have everyone around the teams to understand that this is something teams do and need to prioritize.
Just do it – do more generative research and communicate the insights so others understand the team knows a lot about their users.
Have more people inside and outside the team prioritize being part of user interviews – so more people see the benefit.
Having a new and separate cadence for generative user interviews (today we have a cadence for user interviews in general, which is mostly assumption testing).
Thank you all teams and product trios for the generous and honest sharing session! You rock.
Jag tror på en hybridapproach till att organisera designers. Dedikerade designers i tvärfunktionella produktteam med ansvar för olika målgrupper/del av användarresan, men samtidigt ett tight designgäng som hänger och gör mycket tillsammans. Men en nackdel med det här sättet är att det kan vara svårt att tänka på och jobba med helheten, tänka på hur vi optimerar hela användarresan och inte bara den del som produktteamet ansvarar för.
På sistone har vi i Hemnets UX-gäng gjort två saker för att hjälpa oss och hela bolaget att tänka mer helhet och användare i produktutvecklingen. Den första saken är att visualisera kundresan för våra olika målgrupper, på en övergripande nivå som alla ska kunna förstå. Den andra saken som jag ska skriva om nu är vår experience vision, en historia om vilket värde vi vill leverera till våra användare i framtiden.
Allt började med inspiration utifrån
Snacka med folk på andra bolag och vara med i nätverk är väldans bra! Vi hörde talas om Kry som gjort en animerad film, en historia om en familj som går igenom olika utmaningar i livet och beskriver hur Kry om något åt kommer kunna hjälpa familjen. Det var stort fokus på situationerna, behoven och problemen. Lösningarna fanns med men väldigt konceptuellt. På slutet av filmen gick den igenom Krys mål för kommande året och knöt ihop dem med exempel i storyn.
Vi träffade Hannes Johansson, då på Kry, fick se delar av filmen och lära oss om vad som var bra och vad som var svårt. Vi blev ännu mer taggade på att göra något liknande och satte ett första scope:
En story som alla på Hemnet kan förstå och få ut något av, med enkelt språk och känslor som går att relatera till.
En story kring målgruppen konsument – alltså vanligt folk som köper och säljer bostad. Vi hade redan visualiserat kundresan och gjort mycket user research. Plus lätt för alla på bolaget att förstå.
Hålla formatet riktigt enkelt till en början – slides med text så vi kan ändra snabbt när vi lär oss nya saker.
Hålla oss borta från lösningsdetaljer så långt det går – inga wireframes.
Så gjorde vi
Vi hade som sagt redan en kundresa visualiserad för konsument, som blev en bra utgångspunkt. Den består av de fem faserna Researcha, Köpa, Sälja, Flytta och Äga. Varje fas består av mer detaljerade aktiviteter med behov, pains och touchpoints. Men kundresan är ett nuläge, så hur kan vi definiera hur vi vill att upplevelsen ska se ut i framtiden, utifrån vår produktstrategi?
Vi utgick från produktstrategin och definierade övergripande upplevelsemål. När man till exempel köper bostad, hur vill vi att upplevelsen ska vara om några år när vi har ”lyckats” med vår strategi? För varje fas i kundresan formulerade vi ett eller två upplevelsemål i form av en one-liner. Vi bad om feedback från CPO och itererade dem några gånger.
En dag i oktober samlade vi hela UX-gänget (plus Magnus från marknad) för att skapa embryot till vår experience vision för konsument. Så här såg workshopupplägget ut:
Gå igenom vår produktstrategi, faserna i kundresan och upplevelsemålen.
Utifrån varje upplevelsemål, definiera de viktigaste behoven och vad som hindrar användaren från att nå upplevelsemålet idag. Här delade vi in oss i smågrupper utifrån vilken del av kundresan man har mest kunskap om.
Brainstorma idéer på karaktärer och scener som skulle kunna vara med i storyn. Vi började gemensamt på en whiteboard, sedan körde vi smågrupper där varje grupp fick en fas i kundresan och började skapa slides med scener.
Den här workshopen blev så himla bra. Alla var dunderengagerade och vi kom en bra bit på vägen med att bygga en story. Som en liten fin sidoeffekt tror jag vi alla lärde oss en hel del om våra användare.
Efter workshopen tog jag allt material, snyggade till och förfinade presentationen. Vi hade stor hjälp av vårt otroliga illustrationsmanér som Veronika Luganadisko tagit fram.
När den första versionen såg hyfsat bra och begriplig ut skickade jag till flera stakeholders som har bra koll på vår strategi och partnerrelationer, fick en massa bra kommentarer och itererade några vändor. Jag lade också till en del på slutet, där vi beskriver vår produktstrategi och hur den hänger ihop med olika delar av storyn.
Några bilder från den ”färdiga” (den blir aldrig färdig) storyn:
De här bilderna innehåller (medvetet) ingenting om Hemnets roll men det är förstås fokuset i den fullskaliga historian.
Du kommer aldrig tro vad som hände sen!
Vi spelade in slideshowen med en voiceover och presenterade för hela företaget på vår strategidag några veckor senare. Det blev en 12 minuter lång ”film” som numera också är del av vår onboarding för nya kollegor. Tanken är också att den ska användas i idégenerering och innovation, när vi vill ha en snabb och lättillgänglig bild av vår strategi utifrån ett användarperspektiv. Och det finns planer på att göra en story utifrån andra målgrupper, som mäklare och bostadsutvecklare.
Vi har fått en massa fin feedback. Den vanligaste är att det här är ett bra och lättillgängligt sätt att kommunicera produktstrategin på, ett bra komplement till ”det vanliga”. En konstruktiv feedback är att den är svårt att veta vilka delar av upplevelsen vi är bra på idag och var det finns mest smärta och potential.
Det vore väldigt kul att höra om andra företag som gjort liknande saker och hur det gick. Skriv till mig på LinkedIn eller kommentera här!
This is my first post in English on this blog. I like to write in Swedish but there are so many concepts here that are better not to translate. Feedback is welcome!
Last week, we hosted a meetup on product discovery. My colleagues Wiktor Holmberg and Niklas Fischerström talked about how it’s done at Hemnet and they did an awesome job. Maybe this post can be interesting if you missed the event or want some more details.
Currently, we have six cross-functional product teams all working with continuously exploring and deciding what to build next and at the same time delivering what has been decided. The way we work is very inspired by Teresa Torres’ Continuous Discovery Habits book. All teams define their overall goals (outcomes), talk to users continuously, visualise discovery in an Opportunity Solution Tree and use some kind of product trio/quartet to speed up decision making.
So what have we done to get to where we are? Let’s deep dive a bit into this.
What we already had
First, since context is king. Context. Each company is different, and what needs to be done varies according to where you are. For us this has been a long journey and there is not really a before and after. But in general, we have had the following for a long time (4+ years):
Leadership does not want to micromanage.I believe this to be perhaps the most critical prerequisite for successful discovery work. Our leaders have realised that teams that can get to know their domain and users and make decisions themselves are the most effective. This is about trust and about taking responsibility for your area as a product team. When teams show that they want more responsibility and that they can handle it, leaders will let them have it. But it only works if leadership does have that mindset and that is something we are lucky to have.
Cross-functional teams. Usually developers (web+app), UX designer, digital analyst, product manager and development (people) manager.
Generalist UX designers who are dedicated to their team.We have hired UX designers that can do a lot of different work which is critical when you are the dedicated designer in a product team. They should be able to drive discovery processes, do user research, communicate and facilitate. But also actually do the design work, even at a detail level. These kinds of people are pretty hard to so recruitment can be slow, but I don’t see how we could get this far without these kinds of super heroes/unicorns.
Teams organised by user group/customer journey. For example we have one team focusing on value for real estate agents and another one focusing on the finding a property part of the consumer journey.
Teams that are expected to set their own goals. We started working with OKRs on a company and team level about 4 years ago, for many reasons. Some were improving alignment, transparency and innovation.
A culture of transparency, feedback and psychological safety. We have had well-functioning open demos where all teams share learnings and progress every second week. Our forums, open sessions for sharing knowledge, and feedback sessions are open to everyone. Development managers are focused on the team culture and safety, which is critical to honest and early sharing and caring.
What we did
A lot of what we have done relates to the points above and where we already were. Protecting our awesome product team culture from being eaten up when we grow. But we have also done things to improve.
We made user research faster and easier
This is something Niklas talked about last week. To make product discovery work work, we have meet users all the time. We need to uncover new opportunities but also to do assumption testing when it comes to things like usability or understandability. Briefly, this is what we have introduced:
Simplified recruiting. We recruit ourselves using an on-site survey (in HotJar) and a calendar tool so respondents can book their own timeslots. We used to use Calendly but have moved to the Google Calendar appointment schedule.
User research routine. Every second Thursday, the UX group talks with users. We do it together, helping each other to take notes and we divide the recruiting responsibility between us. Anyone at the company is welcome to listen in. The interviews are listed in a shared calendar.
Collaborative note-taking and analysis. We use a shared Miro board for taking notes so that we can do a quick analysis. It is very similar to the one presented in this article.
Research repository. We collect all research sessions with some meta data in an Airtable repository. Here, we also collect customer requests.
We established a common vocabulary and concepts
Some of the Hemnet teams have been working with product discovery for a very long time but it’s been done in various ways and using different tools and vocabulary. There is nothing wrong with using different tools. We encourage teams to try to find their preferred ways of working and don’t be afraid of adapting new ways without asking anyone for permission.
But making some things official has really helped us to scale discovery to more teams and to support each other. Nothing is mandatory, really. We like the concepts of product trio, opportunity solution tree and assumption testing and these are part of onboarding. The rest, how teams prioritize opportunities and assumptions or which routines they have, is up to them. When a team comes up with a new way of working that can help others, we make sure to share it. As of last month, we also have a regular monthly product trio sharing session.
I think the most critical part, though, is having a shared vocabulary so we mean the same things when we talk about things like product discovery, outcomes, opportunities or assumptions. There’s now less confusion and we are able to help each other.
We supported teams hands-on to get started and improve
Several teams that are new to product discovery have got support from others within the UX/research group. They’ve had help setting up and improving their opportunity solution tree and integrating it with research efforts. When teams have something up that they have built themselves it is easier to keep running.
What’s next
Of course, everything can be improved. These are some areas I think we will work with going forward:
Having the full picture while in a product team. Within a product team, the team members and the team goals are the closest and it can be difficult to see synergies with other teams or product areas. Everyone needs to understand the full picture. Both when it comes to users, business, and technology. It is impossible to know or think of everything, so this needs to be at a higher level of abstraction.
Involving the extended team. We have a lot of competence in the product team and enough to do a lot of awesome work. But we don’t know everything and need to be better at knowing when to involve other departments or teams. And how.
Jag har länge haft en fri roll. Det finns en rollbeskrivning men inget facit för vad en UX Director på Hemnet ska göra eller hur man ska vara. Det finns ingen annan UX Director. Oftast har det varit kul, för jag är intresserad av det mesta och älskar att upptäcka nya områden där jag kan lära mig och bidra. Men ibland har det varit jobbigt och bland har jag haft känslan av att jag inte fokuserar på rätt saker.
För ungefär ett år sedan gjorde jag en förbättring som hjälpte mig i det här. Jag avsatte 30 minuter varje fredag till reflektion och uppfann en reflektionsmall som jag använt sedan dess. Den består av följande rubriker:
Gjorde
Kände
Lärde mig
Kunde gjort mer/mindre av
Att fokusera på nästa vecka
Att skriva för att reflektera funkar bra för mig (det är också därför jag skriver den här bloggen) och veckoreflektionen har hjälpt mig på flera sätt:
Jag är mer medveten om hur jag spenderar min tid och prioriterar. Det blir lättare att skifta fokus om jag hamnar på ”fel” spår.
Jag kan tidigare upptäcka att jag har för mycket att göra och hantera det.
Jag är snällare mot mig själv och bättre på att ge mig själv återhämtning och pausa i intensiva perioder.
Jag har lättare att känna att jag bidrar och skapar värde.
Jag rekommenderar verkligen alla att prova att avsätta tid för reflektion.
Helt Sonika 