agile | Fantblog

juni 16, 2017

The challenge with problem centric product management

Why is it so hard to talk about problems? We recently started to adopt a problem centric approach to product management to help us focus on the right things. This basically means moving away from having the business stakeholders think out features and then ship them to the software development team. Instead we need to start thinking about which problems we have and then collaborate between teams to come up with the best solution.

The concept of problem management over product management is not new. We were very inspired by Googler Jen Granito Ruffner and her outline to why this needs to be the way to do product development. In an organisation, lot’s of people have ideas that they want to communicate and pursue. Ideas are great but they are not focusing on what we want to achieve.

An example: A marketing executive makes a feature request: We have tons of good product videos and we need to put them on the product pages of our e-commerce site.

It’s a clear task. It’s also fairly simple to get done. But is it the right thing to do? This is where we need to understand the problem we are trying to solve. There are methods for this but the best way is to, in a non provocative way, ask why? And if one why is not enough, try four or five times.

Product manager: Why should we add the videos?
Marketing exec: Because we get more rich content!
Product manager: And why do we need more rich content?
Marketing exec: For the customers to understand our products better!
Product manager: Why do they need to understand the products better?
Marketing exec: The drop off rate from our product page is 50%!
Product manager: Ok, and why do they drop off?
Marketing exec: Well, most drop off to visit a price comparison service.
Product manager: Ok, so the real problem is that people are leaving the site to visit a price comparison site. So, what is the best way for us to make people stick around.

What happens here is:

A problem opens up for more people to come in and suggest solutions
We have a clear metric (drop off rate) on what what we want to improve
We can prioritise how solving this problem is more or less important for our business (by comparing with other problem’s metrics).

So why aren’t everybody doing this?

Well for a start we have a global culture of suggesting solutions to each other. What is 2+2? What should we eat for dinner? What should we do with all of these product videos? You don’t go to a colleague and say “Hey, I see a problem, can you help me solve it”. For mangers this is even worse. A manager is really good at coming up with ideas, because you have role were you are expected to always have an answer.

Secondly, if you have an idea, it’s really hard to change our mind about not doing it. It’s your little baby and when someone suggests something else you immediately feel offended that someone might think differently. Even worse, you might have promised someone else that you are going do it and of course you don’t want to go back and say that it’s not happening!

Thirdly, looking for problems is boring and hard. We don’t want to think about problems, we want to generate ideas, have fun and be creative! It’s a cliché but looking for problems is actually about looking for opportunities, and that is creative. Is my team productive? Is the conversion rate of our web shop good or bad? Am I a good parent?…

To formulate a good problem, you need to quantify it with a good metric and assign some kind of value to it. Metrics are hard but some metrics are better than no metrics. A simple exercise to find a good metric is to think about the problem in a worst case scenario.

What’s an extremely bad web shop? Zero customers.

What’s an extremely bad tech team? Zero items shipped to production.

What’s an extremely bad parent? Zero time with the kids.

These are your basic metrics and the problem/opportunity you can focus on.

If we are reluctant to think about problems. How do we make the shift?

My personal opinion is that this mindset boils down from managers (like me) and they need to enforce it. If you ask your team to report on KPI’s then they will. If you ask them to build a process on how to find their key problems, they will. I’m not saying it’s easy. But it’s my firm belief that this can be achieved.

Min final words on this problem centric approach is that if you dare to ask why enough times, then you will realise your purpose as a business or even as an individual. I’ll continue with the product videos example to prove my point.

Product manager: Ok, so why is it important that people stick around on our website?
Marketing exec: Well, we have the best price on products they need, they should buy from us!
Product manager: Why do they need these products?
Marketing exec: Because our products removes the boring stuff from their lives so that they can have a happier life with their family!
Product manager: Ok, that’s pretty cool.
Marketing exec: Yeah.

maj 11, 2016

Konsten att prioritera bland 100 IT-projekt

När jag kom till Tretti fanns det en kort lista på några stora projekt som bara måste genomföras. Till detta fanns det en mängd små projekt, buggar och feature requests. Det fanns ingen CTO eller produktägare på Tretti så mycket av ansvaret för att prioritera mellan dessa hamnade på utvecklarna i synnerhet vår lead.

Kvalitén på projekt och ärenden var väldigt blandade. En kort mening om en ny knapp, en utförlig beskrivning om en ny funktion, ett argt mail om en funktion som är trasig m.m. För att få koll på vad som låg började vi med scrum som metodik och vi fick upp ärenden tydligare på en digital plattform. Det fanns ingen idé att riva upp det som utvecklarna redan jobbade med men nu visualiserade vi vad som kom in och ut från vårt team.

Nästa steg för mig var att skapa en heltäckande backlog för allt som är efterfrågat och prioritera detta. Lättare sagt än gjort, men det gick att få ihop allt som var liggande. Som en första sortering utgick jag ifrån en ganska grov modell impact matrix som skulle fokusera på maximal värde för affären.

För system som påverkar slutkunden mappade jag in projekt efter hur många kunder ändringen påverkade och hur ofta. För interna system såg det ungefär likadant ut men där antal kunder var utbytta mot en skala av medarbetare. Det finns fler parametrar att ta ställning till när man prioriterar, men detta gav en grov bild som funkade.

Jag har testat lite olika metoder för att göra detta. Det som fungerat bäst är att visa alla avdelningschefer vilka projekt som deras team efterfrågar och låta dem sätta prioritet som grupp — att skapa en kultur av produktägarskap. Jag har både testat att låta dem prioritera all ärenden på listan i ordning eller helt enkelt välja ut två-tre ärenden som brinner nu. Det senare fungerar bäst enligt min mening. Jag har också smugit in lite frågeställningar som hjälper dem att välja utifrån impact.

Det vi jobbar på nu är att se över hur ärenden kommer in och hur vi kan automatiskt kan få den som rapporterar ärenden att värdera dem utan att sätta en prioritet. Det tar helt enkelt för lång tid att ta in allt och processa det genom en egen impact matrix.

Inom agile finns det en del som hävdar att s.k. impact mapping (inte samma som min lösning ovan) är det bästa sättet att värdera projekt på. Istället för att sätta roadmaps och deadlines så jobbar man alltid på det projekt som ger mest värde. Det är en intressant tanke och jag tror att nyckeln är att man får med hela organisationen på tåget om det ska funka. Tack till Marcus Hamrin (Agile project manager på Ooyala) för bra intro till detta.

###

Denna post är nummer 57 i en serie av 100 poster i utmaningen #blogg100 där jag fokuserar på hur vi skapar Trettis nya sajt. Alla åsikter är mina egna.

april 27, 2016

Hur vi jobbar med Agile inom e-handel

Vi kör Scrum för våra projekt på Tretti. Vi har gjort det i lite över ett år nu och har lärt oss en del om vad som fungerar och inte fungerar. Jag tänkte ta denna post att reflektera och förhoppningsvis inspirera lite om hur man kan jobba agilt inom e-handel.

För dig som inte är insatt i de agila arbetsmetoderna så innebär de kort att man sätter upp en projektmetodik som stödjer en snabbrörlig affär där kraven på vad som är viktigt kan ändras av interna eller externa faktorer. Agil betyder just lättrörlig. Det innebär inte att det är lätt att kasta in saker från sidan kors och tvärs. Tvärtom kräver det en organisation som är extremt medveten om sina prioriteringar och vad som skapar affärsnytta varje vecka.

Med Scrum jobbar man vanligtvis i iterationer om några veckor. Vi har valt två veckor. Sprinten börjar med en planeringssession där hela IT-teamet får presenterat för sig vilka projekt/problem (s.k. User story) som behöver lösas. Där uppskattar vi hur lång tid det tar att lösa detta. Hur man ska uppskatta har vi testat i omgångar. Nu är vi inne på halvdagar som minsta möjliga uppskattning. Efter den grova uppskattningen prioriterar vi projekten och ser hur många som får plats i denna två veckor långa iteration. Sen bryter vi ner varje problem i olika tasks. Detta gör vi för att det ska bli lätt att följa hur stor andel av problemet som är kvar dag för dag.

Sen startar vi med utvecklingen. Varje dag kl 9.00 börjar vi med en kort stående möte intill en vägg där vi satt upp alla user stories och tasks. Varje medlem i teamet rapporterar till resten av teamet tre frågor:

Vad gjorde jag igår?
Vad gör jag idag?
Är det något som blockerar/distraherar mig från det jag ska göra?

Väggen med tasks har fyra kolumner som representerar olika statusar som en task kan ha; todo, in progress, test/merge request, done. Vi kanske kommer att ändra vilka statusar vi har, men just nu är de dessa. Varje teammedlem flyttar en lapp med en task på till den kolumn som den hör hemma. Alla utvecklare har en eller två lappar i “in progress” hela tiden. Efter varje möte visualiserar vi mängden jobb som är kvar i sprinten med en burndown chart, en graf som förhoppningsvis slutar på noll när sprinten är klar.

Under utvecklingen lanserar vi kod till staging-miljö för test och sen i produktion. Detta gör vi ett par gånger per dag med hjälp av s.k. continuous integration där hela lanseringsflödet är scriptat. Jag kan återkomma till det i en annan post, för det fungerar riktigt bra.

När sprinten är slut har vi en sprint demo där vi går igenom olika saker som vi byggt. Ibland missar vi detta, men vi ska bli bättre på det. Det är viktigt att fira sina segrar.

Lite av utmaningarna med jobba på Tretti är att väga utvecklingen av ny sajt med de vanliga småprojekt som kommer upp. Det kan vara konverteringsoptimeringar, interna verktyg som ska uppdateras eller nya payment integrationer. De projekt som tenderar att dra iväg är de där vi är beroende av en part utanför Tretti, exempelvis en integration. De projekten flaggar jag med hög risk för försening redan innan de startat.

Agilt till nästa nivå för oss

För ett par veckor sen fick vi tillskott av Marcus och Hannes som exjobbare från KTH. De fördjupar sig inom agila utvecklingsprocesser och hur man hittar en process för att hela tiden bli bättre på det vi gör. Vi skriver redan bättre user stories och har en mer disciplinerad burn down. Nästa steg är att involvera hela organisationen i samma tänk.

Igår hade vi även en kort presentation av utvecklingschefen på Qliro, Björn Wahlberg som har en bakgrund inom utveckling och som agil coach. Han gick igenom deras process för att skapa så mycket värde som möjligt i utvecklingsprojekt genom att jobba med både kravställning och hur man bryter ned utvecklingsprojekt i små delar som ändå skapar värden i sig.

Agile inom e-handel skiljer sig inte nämnvärt från något annat teknikbolag. En viktig skillnad är dock hur många system som IT på Tretti hanterar. Vi bygger inte bara en app eller en sajt utan även vidareutvecklar lageroptimering, fakturahantering m.m. Vi håller ihop hela maskinen och ser till att alla kan göra sina jobb på ett optimalt sätt.

Jag tar gärna frågor kring detta då jag vet att det är ett ämne som berör många.

###

Denna post är nummer 47 i en serie av 100 poster i utmaningen #blogg100 där jag fokuserar på hur vi skapar Trettis nya sajt. Alla åsikter är mina egna.

september 10, 2013december 5, 2014

Product managers need the User Pain Story

You are not building a product. No, you are not.
You are not building a service. No, that’s not what you do.

So what do you? You are helping another human being to be really great at something! (I’ve touched on the subject before) I’v been planning to write this post for a while, and now I will dig into practical advice on how to maintain true customer centric product development, and how to explore: “purpose”.

This is no revolutionary new idea, but it is really hard to do. In my experience a company has a Product manager or Creative director that is responsible for knowing what kind of features the software developers should be working on, based on customer needs (hopefully). It’s usually the features that is the main topic of discussion at the company meetings – how they should work and what constraints we need to consider (yeah, we do it at Osom too). Nothing wrong with that, except when the features loose touch of purpose.

So how can we make sure all product development is actually making the user kick ass at something?

The Scrum methodology deals with purpose somewhat by stating a user story with a clear business reason. The user story is usually described like “As a X, I want to accomplish Y, with business reason Z”.
Example: As a customer I want to list all my previous orders so I can print them for my accountant. This story is fine and the featured needed is fairly easy to estimate by a dev. The problem here is that it mostly describes activity and not purpose. We need another layer before this that evaluates that this is actually the best way to solve the customers problem.

Introducing: the User Pain Story

The User Pain Story: My accountant hates me because he has to wait for me every month to get a summary of our expenses and I don’t have the time to give it to him.

Suddenly there are lots of ways we can solve this pain story! We could get the accountant access to the previous orders listing or send him an automated monthly email with all the information he needs.

The pain stories are crucial to being a product manager. You don’t need to discuss pain stories in company wide meetings but you need to reflect on them personally or within a small group of product managers. You should gather information by talking to customers, doing user testing and comparing your product with competitors. With this intel you can formalise the vision of the product and develop KPI’s that makes sense to monitor your progress. The pain stories will help you determine the best cure for a customer problem, from a range of options.

Hidden Pains

Note that pains are rarely expressed explicitly by a user. You need to dig deep to find what is bothering them. A root cause analysis can take you pretty far when you talk to a customer.

Watching a user using your product and listening to them is the best way to collect valuable intel.

The first impression lasts. What does your tool do for a first time user. Can they accomplish the most important task within X minutes without training?

What’s the users work environment like? Any bosses or clients that depend on the activity performed by the user?

What is the most important pain killer to a major customer problem and is it intuitive to see why your tool will be the best cure?

Is there a part of a common work process that takes a significant amount of time?

Is there a way your product will redefine how users work in their organisation?

The product development process

Most well designed tools come from a developer’s understanding of the user’s pain and she therefore accepts the reason why a feature is proposed by the product manager. By using the Pain story as an example you will get a solid feature foundation and more clear discussions around a feature.

Find your method of collecting user pains
Write them down and discuss in a small group
Come up with 2 or 3 solutions to each pain. Pick one
Use the pains to plan and validate your feature backlog
Go build amazing tools that serves a purpose.

december 11, 2012april 14, 2015

Why Agile Business Development is more effective

http://www.flickr.com/photos/rossbeane/965314248/sizes/n/in/photostream/

Ever tried to find a partnership to help grow your customer base? Well, that’s one of the most important tasks for a business developer. This post focuses on that task and how to improve it by using inspiration and tactics from the world of agile software world.
Enter Agile Business Development.

To explain what agile business development is all about I’ll refer to the man that coined the term and presented it during an interview with Mixergy; Harley Finkelstein. He is the Chief Platform Officer at Shopify and has found great ways to use the analogies from the agile movement and apply them to building partnerships and business development.

Agile is about reacting to change and new business needs. Done is better than perfect and focus on collaboration over negotiation. If you haven’t watched/listened to the interview do it after reading this blog post. There is a link at the bottom.

What problem is Agile Biz Dev solving?

Usually partnerships can be a massive project that takes time and resources to come together. What agile does is to work in smaller steps, finding out if a relation works and if two partners have something to gain from each other. It gets something going fast. Finkelstein uses the metaphor “the teenage guy who tries to score on the first date” as the problematic methodology most commonly used in non agile biz dev. Use the following tactics to get more agile.

Stop wasting time. What are the objectives?

Skip the company presentation slides. You can send them in advance or after the meeting. Finkelstein describes a typical agile biz dev meeting as cutting right to the chase and trying to understand each other’s needs – “Here is my objective for this meeting. What is your?” Of course this can seem intrusive or aggressive at first but briefly explaining that this way has worked before (for Shopify) and that you don’t want to waste the other persons time.

Not every partnership is obvious on forehand. By stating the objectives you will develop a deeper understanding for your partners business.

Finding the centerpiece

The centerpiece is the beautiful vase or object that stand in the middle of the living room, which everybody can enjoy and talk about. It’s a common interest that makes us feel comfortable and more eager to work with each other. In Finkelstein’s example Gary Vaynerchuk was publishing his book “The Thank you economy” about the same time as Shopify was launching. As there were many key points in the book that also tied in with entrepreneurship and launching an e-commerce store, there were obvious gains in making Vaynerchuk one of the front heroes for the Shopify vision. This centerpiece was about evangelizing for entrepreneurship and increasing sales on both ends.

Finding the centerpiece is about doing research to find something that is going on right now, but also finding the passion and the driving force behind an individual or a company. It’s about identifying needs/passions, removing pains and increasing growth for others. Good examples are product releases, political stand points or in this case, a book release.

Start small and iterate

By suggesting collaboration around a small test run or a proof of concept, you gain tons of knowledge. It’s a low commit in time and money on both sides which is often key. If you perform well on the test your can use it to back a bigger project. Also, if the test fails or if your partner tries to screw you, you will have lost little compared to a situation of greater volume.

Leverage loyalty

Finkelstein refers to this point as a new type of “Greed”. He means that if you find people that are your fans you should encourage them. An Australian blogger that were sending Shopify lot’s of paying customers got a call from Finkelstein and a paycheck. They paid him retrospectively in cash according to their affiliate agreement to make him a loyal follower for the coming decade.

I don’t agree with Finkelstein on the payment reward. I think just the fact that he got noticed and contacted was worth so much more. By paying your contributors you turn them into employees and changing their incentive on why they want to help. Make sure to build partnerships with fans that last by making them feel special.

Don’t forget about timing

If you try to sell yourself on the same day as your potential partner is stressed out over a product launch, is leaving on vacation or just having a crappy day you are less likely to succeed. Your timing can be improved by simply following the news, monitoring when companies are likely to release new products or when authors are about to release books.

Relations, rejections and rebounds

This ties in with the Timing issue. If you catch your potential partner at a bad time it is likely that your will be rejected with no way to comeback. By offering a way out of your proposal without the partner loosing face, you can come back at a later time and be more successful.

The basic layup:
”I know you are super busy. I’m in town beginning next week. It would be great to meet you, but if you can’t that’s fine too”.

This works well for media relations too. You might have a strong PR message that you want to reach out with that is not a 100% relevant for one certain news site. Just offer a way out without destroying the possibility of future talks.

“I hope this is relevant. If not, I still hope I can buy you a beer on conference X this fall. “

That’s it. That’s the basics of agile biz dev. Please comment and add more discussion to this subject.

Mixergy link: http://mixergy.com/harley-finkelstein-shopify-interview-2
It’s probably behind a paywall but it’s worth paying for mixergy!