ReflektionerTips

Saker jag önskar jag visste innan…

Ca 8 minuter att läsa

Innan jag började jobba med produktutveckling så tänkte jag; ”Hur svårt kan det va?”. Förvisso inte så svårt egentligen om man kan och gör rätt saker. När jag började och man kommer in ny så upplevde jag att det är mycket fokus på att leverera. I korta iterationer för att skapa värde till kunden. Det är ju bra och även det vi i slutändan vill, men det är samtidigt inte hela sanningen.

Jag upplever så här i efterhand att mycket fokus ligger på själva leveransen och att man levererar features/funktioner. Men inte så mycket fokus på VARFÖR man levererar det. Och i längden blir det att fokus inte ens är på att leverera rätt saker.

Många företag är i någon form av transformation i den digitala resan. Några ska datorisera sin data, andra digitalisera sina flöden, någon annan automatisera ett redan befintliga flöde. Några ska bara förstå vad det innebär och för många blir det tyvärr också en stress, vilket jag även upplevt på mina arbetsplatser. Är det inte att att digitalisera sina papper så är det att ”digitalisera” sitt arbetssätt på olika visa. Det jag själv stött på är väl framförallt när verksamheten ska gå från en klassisk projektutformad organisation med ”vattenfallsmodeller” till att bli agila. Då hamnar fokus stundtals på fel saker inom organisationen och det blir viktigare att följa scrum än att förstå värdet av leveransen.

Med detta i åtanken började jag för ett tag sen fundera på saker som jag önskat mig förstå eller kunnat bättre när jag kom in som ny inom produktutveckling. Så jag tänkte lista ett par saker (utan inbördes ordning) nedan som hjälper mig ofantligt mycket idag, men som hade gett mig en rejäl språngbräda om jag haft djupare kunskap redan från början.

1. UX & Designprocessen

Bild lånad från: https://productcoalition.com/@sidebench

Många arbetsplatser jobbar på rätt ”vattenfalligt” i utvecklingen. Det är oftast agilt när det kommer till att utveckla och leverera. Men agiliteten finns där inte på det sätt jag själv hade önskat. Jag tror att det till viss del kan bero på att de som ansvarar för produkten (produktägare, affärsutvecklare etc.) inte har förståelse för hur design fungerar. De anser att rätt väg att utveckla en produkt är genom ”feature hell”. D.v.s. den med mest features när den dör vinner genom leverans på löpande band för att sedan tro att det är precis det som kunden vill ha. Bara för att hen frågade om viss funktionalitet. Det är så mycket fundamentalt fel det bara kan bli.

Just design finns det många olika ramverk av som t.ex. design thinking, service design, design sprints eller lean startup. De fokuserar på lite olika delar, då några är mer fokuserade på experiment och hypoteser, medan några är fokuserade på undersökningar och wireframes. Men gemensamt är att de alla utgår från kunden och försöker besvara ungefär samma fråga. Finns det ett behov/problem som kunden har och hur ska vi lösa det? Och vad behöver vi göra för att åstadkomma det?

Det är så lätt att en produktägare eller annan person sitter och beskriver i detalj vad som ska levereras utan någon som helst belägg i vad kunderna faktiskt vill ha. En 100% spec. hur en funktion ska fungera, vad den ska innehålla och vad den ska göra. Så är du i en organisation där du känner igen dig, lär dig mer om designprocessen och gå till din närmaste chef och/eller ditt team och be att ni arbetar på ett sätt som är designat för att leverera värde till kunden.

2. Mindre fokus på verktyg och ramverk

Bild lånad från: https://reqtest.com/agile-blog/how-to-build-your-product-backlog/

I många diskussioner med produktägare, scrum master, intressenter och andra inblandade i utvecklingsprocessen så får jag ofta höra; ”lägg in det i backlogen”, ”har vi något digitalt stöd för det?”, ”det är inte enligt scrum, så bör vi göra så?”. Olika bortförklaringar eller andra orsaker som hämmar utvecklingen positivt. Det bli så mycket fokus på att följa använda ett visst verktyg eller t.e.x utgå från scrum i ur och skur att man glömmer av personen bakom. Det är viktigt och bra att följa ramverk och verktyg, men de ska vara ett stöd i arbetet och inte en lag/regel. Otaliga gånger har det blivit ett hinder i organisationer jag arbetat i när vi vill arbeta på ett visst sätt och visualisera arbetet, men någon/några personer eller arbetssätt i organisationen är så hårt knutna till t.ex. kanbanboarden att den berömda boxen krymper för var dag.

Mitt råd är helt enkelt att se verktyg och ramverk som ett stöd och hjälp. Se vad organisationen och ditt team verkligen behöver och jobba utifrån människorna bakom koden. Ta bort så många beroende mellan system och människa som möjligt.

3. Optimerade team

Character illustration of people holding creative ideas icons

Den ständigt återkommande diskussionen jag varit med om är hur vi bäst ska optimera teamet. Ska det fungera som proxyteam, featureteam, produktteam, resursteam etc. Jag har arbetat i allt från stora team om nästan 15 personer till mindre team om tre-fyra personer och jag tycker att stora team är dömda att ”misslyckas”. Det går att genomföra bra arbete med en större grupp, men att det ska vara ett krossfunktionellt team där alla vet vad som ska göras, vilken prioritering som gäller, att teamet äger ett problem/behov end-to-end blir svårt om det är ett stort team. Det är lätt att saker och ting faller mellan stolarna.

Det är ingen nyhet att mindre team är bättre för mig, men ändå är det en sak jag önskat jag lärt mig mer om i ett tidigare skede för att kunna se de hinder och utmaningar som så lätt dyker upp annars.

4. Tydlig målgrupp

Bild lånad från: https://medium.com/@manjunath2137/how-to-create-the-right-target-audience-for-your-facebook-ad-9b5ed562b35f

Snälla, om du vet med dig att ni arbetar med en produkt utan en tydlig målgrupp. STANNA! Ta ett steg tillbaka och börja om. Vem eller vilka är din målgrupp? Utvecklar ni rätt saker för rätt personer eller famlar ni runt i mörkret? Har ni ett gäng med UX/CX designers i organisation, ryck tag i dom och säg att ni vill ha hjälp. Dom är vår tids trollkarlar! Har ni inte designers i er närhet, anställ en eller börja med att lära dig själv om din målgrupp. Gå tillbaka till punkt 1 så står du på en bra grund sen.

5. Analysera bättre (tydliga metrics och hur ni ska mäta dessa)

Hur vet du att ni utvecklar rätt saker? Har ni gjort en MVP? Grattis, men härnäst? Släpper ni arbetet och går vidare till nästa feature? Eller kör ni enligt Build – Measure – Learn? Det är en grunden inom Lean Startup och ett sätt att göra rätt saker. Genom att bygga små iterationer och snabbt testa dessa mot riktiga kunder så vet du om det är rätt saker som blir gjort, eller om det är dags att skrota eller pivotera.

Utgå från en hypotes och bygg den, mät om du åstadkom rätt saker och lär av det. Och iterera om på nytt. När du ska planera tänker du istället motsols. Börja med att fundera på vad du vill lära dig och hur du ska mäta att du lärt dig rätt saker. Bygg det sedan.

Vad du ska mäta är helt beroende på verksamhet, men ett sätt att få hjälp på traven är att läsa The Lean Startup, skriven av Eric Ries.

0
Dela:

Leave a Reply

avatar
  Subscribe  
Notify of