Success is great. Hands down, 10/10, would recommend.

Past success however can be a different story, because the past success becomes a referance point of what new success must look like.

Multiple times I’ve seen and felt progress slow down because we keep referencing to a past project or a past culture. Like the standard was set in that past, and even trying to interfere with that standard is a misuse of the (already used) costs in time/money.

It makes no sense, yet here we are dwelling over it.

But, what even made that past success a success in the first place?

Well, it’s all a game of momentum.

The game of momentum

Success usually comes when there is momentum.

Momentum can come from multiple things, for example:

• A clear why of what we worked towards
• Great insight from discovery work
• True collaboration within the team
• Great communication from everyone
• Innovation and, importantly, curiosity and open minds
• Experimenting first
• Enough funding and space to keep focus

The momentum comes because a group of people scrambled together to find out what they were building. They probably tested a lot of things, which in the end created something that, in hindsight, was a success.

The team riffed, jived or whatever you want to call it, based on a clear vision.

Bill Walsh, the late football coach, said it best: “The score takes care of itself”.

“You can’t completely control the outcome of a game, but you can control the effort you put into your training, and if you relentlessly focus on improving, you increase your chances of success. Focus on continuously bettering yourself, and the score will take care of itself.”

The thing with momentum is that it comes and goes, and it’s normal for short periods to not have it. But, when it’s there, you must exploit it.

So, don’t be nostalgic. Your ex wasn’t all that and the project that did well had a bunch of flaws.

Instead, follow what the All Blacks rugby team did when they needed change: “When you’re on top of your game, change your game.”

Hey, you made it to the end! 🎉

P.S. If you want to read about momentum, you can start with having your own standards: Winners and Losers Have The Same Goals

P.S.S. You can of course follow me on Medium, and Linkedin or Goodreads.

If you would like more stories like these, check out Failing Forward.

The Paradox of Past Success was originally published in Failing forward book on Medium, where people are continuing the conversation by highlighting and responding to this story.

With an example on how we did it

I used to think that storytelling was about, you know, telling short stories. Like how three arrows are stronger than one or something else. Although I see how those stories can make an impact, it never felt natural to say to the team.

On the other hand, using storytelling to constaly create why’s is the difference between just doing busy work and creating purpose.

Luckily we don’t need an arsenal of memorized short stories to be able to be great at storytelling. We just need data.

They talk about this in the book Product Operations:

“Data tells a story. Well, maybe not the data itself, but in the hands of an experienced product manager who knows how to extract the right data for the right audience, it can be the difference between listening to an improv show, where there’s no consistent theme or plot, and a Best Picture winner at the Oscars.”

Example on data = storytelling

When we started to focus on onboarding, there where many things we could do. With that, we quickly saw three data points that stuck out.

1. In a survey taken on home loan owners, the third reason to not change bank was “too much hassle to change” with 33%.
2. Norwegians are users in 1.7 banks on avg, and the trend is growing.
3. The conversions on onboarded users for 9 key products was lower and slower per month than you’d expect (Of course, I can’t share those numbers)

You can use those numbers alone to create multiple stories. Here’s one:

“Onboarding is one of the most important thing we must focus on now. When home loan owners was asked what was the reason they didn’t want to change banks, the third reason (1), behind good enough rate and didn’t see any reason, was simply that it was too much work to do the change.

And if we actually get them over, the numbers on conversion is suprisingly low (3). It shows that onboarding isn’t something that magically happens, because people have so many options with banking that it has become a battle of the apps (2).

This is why we will make SpareBank 1 the first choise! (2) It’s not important for us to be the only bank, because those days are over, but we will make it so easy to come up to speed that users want to keep taking active choices in the app and stay.

We measure this by:

• Increasing product range (3)
• Increasing activity (3)
• Removing pains (1, 3)”

We’ve used this story over and over and over again both within the team, but also the company in whole and stakeholders in general. It has helped us to create focus, but also a clear why.

Data is everywhere. It just needs it’s story told.

Hey, you made it to the end! 🎉

P.S. If you want to read more about finding data, check out: Everyone can do strategy.

P.S.S. You can of course follow me on Medium, and Linkedin or Goodreads.

If you would like more stories like these, check out Failing Forward.

Using Data for Storytelling was originally published in Failing forward book on Medium, where people are continuing the conversation by highlighting and responding to this story.

That’s why systems matter

Everyone in this business wants to do great. Most of us even want to be a part of something amazing. Something that both users love, something that makes a positive dent in the core business, and honestly, something we can show for as professionals.

But if you don’t have a system, you’re chasing a dream. A few might be able to create that dream with luck, but for the rest of us, we need consistent action to realise whatever goals we have set out to achieve.

A great system is not about techniques or processes in itself. It’s how you take advantage of many efforts that in the end creates a culture within your team (and hopefully outside your team as well).

Bill Walsh, the late football coach, said it best: “The score takes care of itself”.

“You can’t completely control the outcome of a game, but you can control the effort you put into your training, and if you relentlessly focus on improving, you increase your chances of success. Focus on continuously bettering yourself, and the score will take care of itself.”

I’m not there yet that I can say “I” have “a system”. Our teams system has been created as a collaborative, natural process. More organically evolved than built with force.

As time passes however, I do find that I can narrow more down to what I wish for in a system.

• That the people is the business, and people always comes before process.
• That we have a clear why and the whole team has full ownership of what we want to achieve.
• That we’re intense on product discovery.
• That we exploit when we win and we explore when we lose.
• That we always learn and test, both on the product, but also in how we collaborate.
• That our team has many leaders.
• That our team should have fun.
• That we win as a team, and we lose as a team. One team, one dream.

In that sense, it’s important that everyone agrees on the system. That means we can’t have someone wanting to do 6 months analysis when another wants to work iteratively to achieve the same goals. That means we can’t be organised as a project team, when we want to be a product team. That means it’s not about me, it’s about we.

“Success is not a goal to reach or a finish line to cross. It is a system to improve, an endless process to refine — James Clear in Atomic Habits

Maybe I’m being sentimental, but I know team changes over time and what we have now will not be forever.

In that sense, I want to be a part of a positive impact that our team members carry on in new places. A system that can be improved. As James Kerr poetically wrote in the book “Legacy”, which is about the All Blacks, “Perhaps it is because its core idea — of legacy, of leaving the jersey in a better place, of planting trees that we will never sit in the shade of”.

That’s why winners have systems.

Hey, you made it to the end! 🎉

P.S. If you want to read more about what our system is, check out: The secrets sports teams can teach us about building teams.

P.S.S. You can of course follow me on Medium, and Linkedin or Goodreads.

If you would like more stories like these, check out Failing Forward.

Winners and Losers Have The Same Goals was originally published in Failing forward book on Medium, where people are continuing the conversation by highlighting and responding to this story.

In my previous life, it seems like now, I used to work as a sound technician. That’s the people who make everything go loud at concerts. While I have so many good memories and fun stories, it’s easily the most stressful job I ever had.

At one concert a rapper lost his voice, and people started threating me because the vocals where so low (again, the rapper lost his voice). Another time, at a Octoberfest, some drunk person unplugged the electricity so the whole show went down.

One intense memory are from the pictures under. The mixing desk hadn’t been working all day and 1000 auidences started entering the room while the band hadn’t even tested the sound. All of this happened while the organizer screamed beside me, literally crying for a solution. That day I mixed the band live and it would be one of my last shows.

There’s so many things that can happen in a concert. With that, you become good at decrypting where problems are located. In other words, you become good at following the cable.

Take an easy example

On a normal drum set up you have 8 microphones. If something happens, the problem isn’t “it’s something wrong with the drums”.

It’s “somewhere a long these points, there’s an issue getting sound from this microphone”. To fix the issue, you follow the cable by starting at the core (microphone itself in this example) and check backwards to all the points to find where the error is.

This technique is the same for more complex cases like the sound is distorted, monitors aren’t working properly and yes, the mixing desk is dead. Follow the cable.

The reason I’m writing this is that I believe we often need to step away from focusing over “the problem” and rather following the cable on what is causing the problem(s) and fix/improve these.

A problem isn’t a problem

A problem usually isn’t the problem in itself. It’s a summary of several problems that boils up to create that overall problem. (scroll a bit down for an illustration if that didn’t make sense)

It’s far more effective to do incremental improvements on mulitple points leading up to an overall problem, rather than using a lot of time trying to solve the overall problem in itself.

Developers do this all the time. They spot an issue and have to follow the cable to find out where the issue is.

Example from a retro

Take a common statement on “We just keep the lights on in this team”. This is, for now, just a subjective opinion that you may have gotten from a retro (remember when we talked about retros?).

You’re not going to fix this by mirroring the statement and saying “Well gang, let’s build something new & cool 🤙🏼”.

If you start adding the points that leads up to this overall issue, it might look something like this.

What you’ll see is that those points are overall problems for something else again. So the cable get’s longer and you get more points that can be fixed.

If you’re having troubles coming up with points, get an allie from your team and do it together. Five why’s is a great technique for provoking answers or more questions. My son that’s 4 uses this technique all the time.

Yesterday he asked me five times what a shadow is. Honestly makes you think.

Anyway.

Hopefully after doing a good ol’ braindump you’ll have enough to understand what can be the causes for the overall problem.

You’re not going to fix everything, because it’s a process, but you can see more clearly where changes can be made that will make the boat go faster for your team.

As a nudge to the importance of doing incremental improvements on points, I want to add three paragraphs from Atomic Habits (by James Clear) that triggered this post. It’s about the English cycling team and how they turned everything around to become one of the greatest to do it.

Brailsford and his coaches began by making small adjustments you might expect from a professional cycling team. They redesigned the bike seats to make them more comfortable and rubbed alchohol on the tires for a better grip. They asked riders to wear electrically heated overshorts to maintain ideal muscle temperature while riding and used biofeedback sensors to monitor how each athelese responded to a particular workout. The team tested various fabrics in a wind tunnel and had their outdoor riders switch to indoor racing suits, which proved to be lighter and more aerodynamic.

But they didn’t stop there. Brailsford and his team continued to find 1 percent improvements in overlooked and unexpected areas. They tested different types of massage gels to see which one led to the fastest muscle recovery. They hired a surgeon to teach each rider the best way to wash their hands to reduce the changes of catching a cold. They determined the type of pillow and mattress that led to the best night’s sleep for each rider. They even painted the inside of the team truck white, which helped them spot little bits of dust that would normally slip by unnoticed but could degrade the performance of the finely tuned bikes.

As these and hundreds of other small improvements accumulated the results came faster than anyone could have imagened.

You will always have problems. That’s part of what makes this job exciting. You just have to choose where to put the energy so the boat goes faster for your team.

Nice, you made it to the end! 🎉

P.S. If you want to read about how to talk about problems with your team, check out: Great Teams Have Issues Too.

P.S.S. You can of course follow me on Medium, and Linkedin or Goodreads.

If you would like more stories like these, check out Failing Forward.

How Concerts Gave Me a Crash Course in Problem Solving was originally published in Failing forward book on Medium, where people are continuing the conversation by highlighting and responding to this story.

Remember playing Chinese whisper as a kid? That game where messages are whispered from person to person and then the original and final messages are compared? Well, that’s kind of how it is working within a large company sometimes.

Nobody does it on purpose, but stuff can get lost in translation. I’ve experienced many times where we’ve explained what we’re planning to do to someone, only to later receive misunderstandings from other people that has heard about what we are trying to do — or what they thought we were trying to do.

It’s a mess.

Funny game.

Less funny to deal with as a PM.

Part of the problem is that you can’t rely on everyone remembering what you’re (probably great) pitch was. It’s the same as everyone demanding that you remember their (probably boring) picthes — which you of course don’t. You might remember parts of it. The rest you just forget or, worse, sprinkle your own agenda on.

This is where a good description comes in

A good description is sharable either via link or image and goes straight to the point on what change or experiment your team is embarking on, why it’s important and how it’s tied up to the strategy.

Generally you can sum up what should be in the description with these 5 questions.

The 5 questions

• What are we doing
• Why are we doing it
• What does success look like
• How does this relate to our strategy
• When will it happen

Notice I havent used the word “documentation”? We’re not trying to document how everything is working. We are giving a brief description on what we are trying to do, so the discussion stays focused.

When I write a description, I’m vary that it should be actually readable. With that in mind, I try to write in a way so that the reader:

1. Reads the whole thing.
2. Understands everything, without me needing to explain.
3. Being able to repeat what we’re working on, at least the essence of it.

If all of those three things happen, I call it a success.

In 1997 Jakob Nielsen wrote an article on “How Users Read on the Web”. I first read it over 10 years ago, and it’s still relevant today. Here’s a snippet from the article on what’s good, scannable text:

• highlighted keywords (hypertext links serve as one form of highlighting; typeface variations and color are others)
• meaningful sub-headings (not “clever” ones)
• bulleted lists
• one idea per paragraph (users will skip over any additional ideas if they are not caught by the first few words in the paragraph)
• the inverted pyramid style, starting with the conclusion
• half the word count (or less) than conventional writing

Examples of descriptions

I stay away from templates, but use the five questions as guidelines, or check points, to make sure I include the most important information.

I prefer Miro, because that’s what our team uses and that’s what I show stakeholders when we talk. (read: collaborating with stakeholders).

The point of showing these examples are:

1. You don’t have to make it pretty
2. You should’t use any template

The tricky part is that the examples I want to use are stuff we are working on now — which of course I can’t share.

So I had to, eh, blurr a lot of stuff out, but hopefully it still gives some value.

Anyway, here goes.

The example over explains a change we wanted to do for everyone that’s being onboarded to SpareBank 1. We knew this change could be viewed negativily if we didn’t address what “bad” could happen. That’s why we added that to the bottom left corner.

We used this for:

1. Other teams in SpareBank 1 Utvikling that we needed to colleborate with
2. Key stakeholders in the banks
3. Everyone in the alliance, when we’re ready to launch

The second example is an experiment where we’re not 100% where it should be placed, but we have enough data to believe it’s important. That’s why we added four examples at the bottom where it could be put, and where we decided to add it.

We used this description as much as a tool for our team, as it was information for key stakeholders that is doing the experiment on their bank.

As you could kind of see:

• There was no template, because every case is a bit different
• I didn’t use all the five questions. It’s guidelines, not a template
• It wasn’t pretty

Both of these examples gave clarity and focus to the conversations.

Sometimes we also write descriptions in SharePoint, which is easily distributed throughout the alliance. There’s no template here either, just more words based on the five questions.

“But Lasse, do I have to write a description for everything that we’re doing?”

No! That would slow things down. For some experiments and changes, we just write an hypothesis and that’s it. Sometimes if you try to over explain a change, it can feel more complicated or serious for the reciever.

I write descriptions when I know there will be a lot of eyes on what we’re trying to do, and it will potentially needs some explanation.

Meanwhile, it’s been quite popular to mention Amazons One-Pager or Six-Pager, where the leaders of the company don’t use Power Points to look at important decisions, but instead read documents. For that, I enjoyed Danny Sheridan’s article about “How Amazonians share their ideas: 1-pager and 6-pager”.

Hey, you made it to the end! 🎉

P.S. On a related subject, read about Collaboration With Stakeholders.

P.S.S. You can of course follow me on Medium, and Linkedin or Goodreads.

If you would like more stories like these, check out Failing Forward.

On Writing Descriptions was originally published in Failing forward book on Medium, where people are continuing the conversation by highlighting and responding to this story.

One of the greatest misconseption is that great teams don’t have issues or problems. If you believe that, you might also think you’re absolute trash at leading teams — because your group has problems and issues.

“Why am I born under this unlucky star??” you scream, in silence.

The secret is that every team, almost always, has some sort of big or minor issues that should be talked about. If not, then you got a flatline-team, and I would actually say this is worse and potentially more difficult to fix.

A passionate group with issues and problems has greater potential to be steared in the right direction compared to a “ded” group. Because with a “ded” group, you need to first fire them up, only to then start working on issues and problems that will come up.

Remember the whole thing about psychological safety? You need dynamics to create trust. In other words: you want issues and problems, so they can be fixed.

Why focusing on psychological safety as a solution doesn’t create psychological safety in your team

The key difference between an OK/good team and great is that great teams communicate. They have issues or problems, but they actually talk about them — let alone deal with.

Talking about things that’s uncomfortable to talk about

Firstly, if your group doesn’t talk about things, shit will not magically get better. It will linger on the surface, only to one day explode.

It’s like a toxic relationship where both sides tries to kind of ignore the giant turd in the living room. Like, wtf, there’s a giant turd in your living room. Talk about it — let alone do something about it.

When you’re building a great team, you’re building relationships with the people within the group.

But, talking about things can be difficult. A lot of issues within in a team can be very nuanced or subjective. Some examples can be “The designers don’t talk to us developers”, “we only keep the lights on with our products” or “I dont feel a place in this group or goals”. It can also be “I dont like the jokes in the office”, “you eating apples at the desk is really annoying” or “No one wants to join when I try to do something social”.

For a person to raise these questions naturally within the group, out of the blue, would require a) a person that’s not sensitive on feelings, b) someone coragues c) true trust within the group.

If you’re a team that doesn’t talk about the real stuff, you might have a or b, but you don’t have c.

The positive thing is that it’s completely fixable.

You just need a system that provokes discussion.

Retrospective: The system to talk about things

There’s multiple ways to talk about things, but Retrospective (retro) is the way I’ve been taught at SpareBank 1 Utvikling and continued to carry on.

In a retro, you look back one month (usually) as discuss what was good and what can be better.

First I’ll go through how I recently held a retro for a team that’s on a journey to have full ownership of what they want to achieve.

Second I’ll go through how our team does retro. A team that I consider a great team.

Before we head on, here’s some questions I tend to get:

1. “Should the retro be mandetory when I send the invitation?” Yes.
2. “But, not everyone has time to come” That’s part of the problem, because the team always comes first. See question one.
3. “How long should it be?” 1.5 hours is a good starting point. Everyone’s brain will be fried after this. Don’t recommend longer than that.
4. “Should it be a recurring event?” Absolutely! You will not fix everything in one retro, and it’s important to constantly communicate. Most people say have it at least every 4 weeks, but I would be more aggressive and say every 3 weeks.
5. “Should it be done digital or analog with irl post its?” I can write a whole article on why digital retro is better, but do what flows best at your company. If in doubt, do it digitally with for example Miro.
6. “We don’t want another meeting” If the team has too many meetings, it should be said in a retro and be worked on later. Hopefully with focus, the team will have less meetings, while retaining the retro.

1: Holding a retro for the first time

Welcome, you’re doing a retro with a team for the first time. As you can see under, there’s essentially three steps in the retro. You don’t have to do the first one (we don’t anymore), but it’s a positive start (we loved it when we did it)

If you’re really nervous about holding this retro, or know there is a lot of big issues to talk about, consider having a person with experience hold the meeting and retro. That way you can focus on what people are saying and your own post it’s.

I’ve made a simple retro board in Miro you can copy and use. I’ll use that as an example under.

First task — Writing highlights last month:

• Task: Have everyone write positive things that has happened the last month. This can be everything from launching something, getting good data to everyone getting ice cream that one day. Make them try to but it ca where it should be on a timeline.
• Why: Both to warm up people, getting them used to miro and post its, but also reminding people that a lot of positive things happens.
• Timer: 3 min

At the end, you justt read them out loud for the group. Use max 2 min on this. If the team struggles to put much on the timeline, that’s something that can be written as a red post it.

Second task — Writing positive and negative posts:

• Task: Everyone takes green and red post its and finds a corner for themselves. You want to encourange clear and direct post its. Everyone should understand what is ment without it being read aloud.
• Why: This is where everyone can say what they feel. Remind the team that if things aren’t brought up in the retro, no one can complain about the issue afterwards (unless it’s a complicated HR issue).
• Timer: 3–8 min
• Rules: 1) No talking during this session, unless it’s your time to talk. This is one of your tasks to stop people from talking. 2) Write the notes outside the main area. Everyone will drag them in later.

After the timer is done, one after the other will go through both their positive and negative points — dragging them in to the main area. Let everyone talk, but don’t be afraid to nudge people a long if they take too much time.

If you’re 10+ people, consider doing max 3 positive and 3 negative post it’s per person. You can say this after they have written everything, so they don’t limit their mind from the start.

I would also recommend staying away from long discussions happening. If everyone jumps on one of the first post its, you might miss valuable insight from the person last in line. We discuss everything at the end. If you need a line to say, try something like “This is a great conversation, but let’s keep on going and see what everyone else has written”

Advice to you as a leader: For your own notes, please, don’t be cute with your post its. Don’t try sounding smart and all political. If you want everyone else to open up and be direct, essentially being vulnarable, you must lead by example.

“If you wish to improve, be content to appear clueless or stupid” — Epictetus

Third task — Choosing which actions to prioritise:

Once everyone has talked, hopefully everything has been kind of grouped together. Nonetheless you have probably seen something that has been mentioned multiple times.

If it’s something you can focus on, you write these as a black post it to be worked on. Because, you will not fix everything in this meeting.

If there’s too many black notes at the end, have everyone in the team talk about what they think is most important, and what is secondary. Prioritising, babyyyyy.

Advice to you as a leader: It’s vital that between this retro and the next retro (because you remembered to already book that next one, right?), the black post it’s gets worked on. If they don’t, the team will lose trust in the retro and eventually the team. “Why should I stick my neck out with things I see wrong, if nothing get’s done?”. You don’t have to do everything yourself, but you have to see that progress is being made — if it makes sense to do it. Not working on the issues after a retro is a classic mistake.

If you do all of this, you’ve done your first retro.

Easy peasy.

2: Setting up continues retros for a great team

Our team currently do a 15 min retro every Tuesday before the check in.

• Every week is so often that we can easily skip a week
• Since we have it so often, rarely is there any lingering issues for us
• Still to this day, things come up at retros that wouldn’t have come up otherwise
• Our team consist of 7 people

Our retro board is in our Commitments board in Miro.

Writing positive and negative posts:

We set a timer on 3 minutes where everyone writes their posts. Since we have it every week, we don’t need to hold more time than that.

Once timer is gone, everyone takes their turn to add their “What’s working” and “What can be improved” notes.

We’re not strict that there’s no talking, but all of us has had enough retros to know that everyone needs to be able to talk, and that we will talk about things later.

Choosing which actions to prioritise:

Once everyone is done, we choose what should be focused on/fixed until next week.

Usually I make the black post it, but everyone can do this.

We add a black action notes on top of the board so it’s easily visible, and then we remind ourself throughout the week that we wanted to focus/prioritise that particulary action.

For each week, we usually land between 2–5 black post its.

Nice, you made it to the end! 🎉

P.S. If you want to read more about teams, check out: The secrets sports teams can teach us about building teams.

P.S.S. You can of course follow me on Medium, and Linkedin or Goodreads.

If you would like more stories like these, check out Failing Forward.

Great Teams Have Issues Too was originally published in Failing forward book on Medium, where people are continuing the conversation by highlighting and responding to this story.

My career path on becoming a leader of products, and therefor leader of people, has been a series of coincidences and focus, fails and wins. I’ve actually tried and failed so much that I’m now very comfortable being uncomfortable — which is a corny flex, I know.

Being outside of your comfort zone is very useful. You grow exponantially in experience, but it’s also, you know, very uncomfortable. Your insecurities and potentially negative traits get’s exposed, naked for everyone to (maybe) notice.

And, to be honest, most of us in our industry are out of our league in one way or another — at some point. No one admits it, but most people will feel it. To be at the level we are, you will need to do things you’re not sure how to do, but you kind of have to fake it anyway.

You can always try and take courses, read books or gain experience from others, but eventually you will have to stick your neck out and try stuff out. And with that, you will fail at a lot of things, and win at others.

This is positive in terms of that exponantially growth in experience, but it can also create a cettle of emotional pressure and potential depression, if you don’t create an outlet for your thoughts.

The opposite of creating an outlet for your thoughts is ignoring it, and that is the underlying problem. The mental tension of not showing weakness is a toxic culture.

Mental health has no boundries on gender, but it does however hit statiscially different on the potential effects. The misconception that men should appear more emotionally stable than women, for example, potentially contributes to alarming statistics: men, though comprising 50% of the U.S. population, account for nearly 80% of suicides. Even in Norway, 75% of all suicides in 2021 was men.*

What‘s important here is that there is an emotional spectrum of where your mind is health wise. It doesn’t mean you’re suicidale if you have negative thoughts, but if you don’t do anything about it — ergo having an outlet for your mind — you can tend to stay stuck where you are at or get worse.

If you find yourself in a period where things seems more dark, know that:

• You are not alone
• It is OK to feel whatever you feel right now
• It is also OK to have shitty days
• It is also OK to do something about it

Robin Sharma said it best with: “The mind is a wonderful servant, but a terrible master.” So don’t be a slave to the mind.

The mind needs an outlet

People are different, and there will be different ways to create outlet for your mind that works for different people. Here is a list to get you started.

1. Talk to someone — Either someone you trust or someone you pay. Easier said than done, but talking about your feelings and thoughts helps put logic from the cloudy mind.
2. Excersise — It’s proven that excersising creates endorphins that is very good for the mental health.
3. Write journal — Start writing in a journal. Much like talking to a therapist, writing down your thoughts helps put logic being the thoughts. It simplifies the complicated. The Daily Stoic has created a great video on getting started with journaling.
4. Measure your success backwards — Instead of meausering your success compared to others, mesaure on where you have been. Read the book “The Gap and The Gain”.

You can’t control what happens in life, you can only control how you deal with it.

Number 3 and 4 has been especially important for me personally. The thing with journaling is that by writing things down, you’re actively forcing your thoughts on paper. It becomes less clouded and scary, and just what it is: words on paper.

*If you have suicidal thoughts, talk to someone. If not family or friends, Google “suicide” in your language and you’ll receive multiple organisations you can contact for free.

You made it to the end!

P.S. Perfectionism can be a cause to depression. If you want to read more about that, you can check out Helping People from the Pressure of Perfectionism.

P.S.S. You can of course follow me on Medium, and Linkedin or Goodreads.

If you would like more stories like these, check out Failing Forward.

On Pressure, Depression and Healthy Minds was originally published in Failing forward book on Medium, where people are continuing the conversation by highlighting and responding to this story.

A short story on how we accidently were strategic, and how you can too.

Strategy was always this intimidating thing for me. This thing that, for whatever reasons, other people seemed to be really good at. Maybe it was just me. Maybe it was just complicated. Maybe it was the shitty Power Points. Who knows.

But, here I am, momma!! I read a book and I learned that, damn it *dramatically slaps knee*, our team were strategic this whole time.

“What was the secret?”, you whisper in my ear?

We problem solved on things we saw was most important. We prioritised by gathering loads of problems and oppurtuinities (insight) and staggered them against each other.

It sounds stupidly easy, I know, but it takes a lot of work and few actually do it.

What is strategy, really?

Richard Rumelt, author of Good Strategy/Bad Strategy, can sum this up in 2 min.

So, strategy is problem solving. To solve a problem however, you need to understand what the problem(s) are. To prioritise what the most important problem is, you need to prioritise against multiple problems.

For our case: when we looked at onboarding, we saw that it was multiple things we could do, but some issues stood out more than others. They stood out in both effort needed and potential results (or input vs outpot if you want to sound fan$y).

How do I get started?

Great question.

First, gather insight.

What’s good insight, you might ask.

The answer, at least in the start, is everything.

The more insight you get, the easier it is to stack up things against each other.

Once you start gathering insight, it’s extremely important to have it in a place where it’s easy to see everything at once. I’ve written another article about this, but tl;dr version is use Miro:

From Chaos to Clarity: Why Miro is the Ultimate Tool for Organized Product Development

A tip from experince: Don’t hop on the first thing you see that looks interessting. It will be tempting, but continue to gather insight. Other things might come. In order to work on a problem over time, you need enough trust that the problem is actually important.

Secondly, once you’ve started to collect all the insight, problems and oppurtunities will hopefully appear. We didn’t use any elaborate teqhnique to look at all the choices.

We did however constantly discuss what we were looking at, and then eventually we could kind of categorise them.

This shifted the whole conversations within the team from “The onboarding needs to be better” to “The most important thing WE can do, right now, is to make it easy for the user to transfer money to us so they can quickly use us as a banking service”. We knew there were other problems too, but getting the user up to speed was most important at that moment.

Two major keys here:
🔑 We created a why within the team, with a clear story to tell others
🔑 We went from something needs to be fixed, to WE need to fix it

Seeing that the people is the business, I firmly stand behind Roger Martin’s “It’s your team, stupid!”, that should own the strategy (with you as a product manager in lead, of course)

Your product will never reach it’s full potential if the team is only asked to execute your ideas and actions. — Marty Cagan in Empowered

A tip from experince: I talked with stakeholders every other week about our insight. All we did was go through our Miro board (still do to this day). It created a much better conversation, because we could include them in our why, our story. I’ve written about that too.

Collaboration With Stakeholders

Thirdly, once you’ve choosen a problem or oppurtunity, you can create an Oppurtunity Solution Tree (OST) that dives more in on what we as a team can do.

Under is an example of one OST we have. The text has been removed, I know, but it’s secret juice.

Essentially, you start with:

• A barrier: % of money in first month is low because…
• Yellow squares are for barriers we have seen from insight. One can be for example “Too much hassle moving bank”
• Green squares are “therefor we should”. For example, if a barrier is “Too much hassle moving bank”, a green note can be “make it easy to fetch money via PSD2”
• Pink squares are actual experiments (hypotethis) on this we should test. For example, under “make it easy to fetch money via PSD2”, you have a pink note that say “Fetching money in onboarding”
• On top of the yellow squares are some choosen insight that we can link to the barriers. It’s not everything, but some extra interessting insight.

Even in the OST we prioritise what to do next. As you can barely see from the picture, some post it has stars and some around marked with a grey circle.

OST is great for many reasons, but two are:
🔑 Everyone can see all the things you could do, which makes it easier to prioritise
🔑 It forces you to not only fix the obvious thing (ergo: make it easier to fetch money), but other aspects that can help the user journey.

If you want to get smarter at OST, I recommend following Sonja Sarah Porter.

A tip from experince: UX and PM might set up the actual OST, you don’t need the whole team for that, but the whole team decides where the focus should be.

Another tip from experince: Don’t go in a meeting with the team talking about “now we are going to be strategic”. It sets an unessecary pressure on the conversation. I’ve tried. Don’t do it. Just talk with your team on the things we can focus on (which in the end is taking strategic decisions)

Wrapping it up

Essentially, you start wide with insight, only to go hyper focused on one or multiple problems or barriars.

If you got to the end, damn… Thanks. This post got way longer than expected and there’s so much more to talk about.

Last tip from experince: Everything sounds easier in hindsight — and I think that was my biggest issue with strategy. My example with “money in” is a year old, so of course it’s easier to say baddabim-baddabam just do it! We work with other things today, but it’s so fresh so it’s harder to easily explain our decisions in an article. Because, even though we bath in insight, strategic decisions is in the end a chance you take. A risk — being it big or small.

So, if it doesn’t make perfect sense for you know what your team is doing, don’t worry. It will probably in some months. And if you take big risks, you should get nervous. That’s why it’s a team effort. More heads. Better decisions. Clearer why.

I am no “expert in strategy”. I do know however that our team is taking the right pivots and decisions, based on the path explained over. With that, we get the results to show for it.

In that sense, I’m content.

P.S. Thanks for recommending Good Strategy/Bad Strategy Ida Aalen & Thomas Allan Nygaard

Hey, you made it to the end! 🎉

P.S. If you want to read about how to create trust in a team, check out: Why focusing on psychological safety as a solution doesn’t create psychological safety in your team

P.S.S. You can of course follow me on Medium, and Linkedin or Goodreads.

If you would like more stories like these, check out Failing Forward.

Everyone Can Do Strategy was originally published in Failing forward book on Medium, where people are continuing the conversation by highlighting and responding to this story.

Feel free to send this to an perfectionist

Everyone want’s to do great work, but sometimes our insecurities leaves us to overcompansate. Some people mask this as perfectionism.

Perfectionism can some times be glorified as this pressing kettle of soon-to-be artistery brilliance. The reality however, is that it’s more often than not a subjective highway to depression (imo).

The question of “what is perfection?” is the main issue, because as soon as you go in to discussions on what state a product needs to be perfect, it’s typically subjective opinions on things that the person that has the opinion can themself control. Or worse: the aspiring leader who demands “perfection” from their subjects.

How do we end up being perfectionist?

Well, one thing can be because of the paradox on time & effort vs pressure built.

The more time and effort you put into something before it’s launched, the more pressure is added on what the perceived quality of the finished work should be. That in turn makes it harder to take decisions that’s best for the product. Essentially it’s a shitty snow ball effect of insecurity.

Especially if you’re working alone or in a team that hasn’t build up true trust, it’s very easy to always use more time on something.

Of course, perfectionisme is the easiest thing to give advice about:

• “We can fix the rest after launch”
• “No one will notice”
• “Is this really important?”

It’s easy to give advice about, because it’s not you who put the time in the creation. There’s no emotions built up to the effort.

Even this article has been re-written many times. I know there will be people I admire who read this. I re-write, partly, because I’m insecure if I actually bring value, when there are way smarter authors out there. Like, does the Internet really need another white, straight guy giving out advice on Medium.com?

Sometimes we need help to get out of the destructive tunnel vision and focus on what we want to achieve. Or as Robin Sharma once said “The mind is a wonderful servant, but a terrible master”.

For me, I have to constantly remind myself that I write these articles primarly for myself. It pushes me to articulate the unfinished thoughts and opinions I have in my head. I become better at what I do, because I’m forced to use hours janking whatever is in my mind down to these words. That means my articles doesn’t have to be “perfect”. Perfect is just another subjective opinion from the terrible master. I just have to be happy enough with what I’ve written down before I go fuck-it-we’re-going-live mode.

So, how can we help make progress for the product, leaving people inspired while not giving shitty advice? Here’s three suggestions.

1— Creating focus

The word perfection is often used when people really mean focus. Focus however, is a very different thing.

Where perfection might focus on achieving an unatainable “umami”, focus prioritises what’s the most important thing we have to do now, so the users loves the product, ends up using it more and the company can grow.

By having a strong focus, you’re saying no to 90% so you can get really good at the 10% that brings most value. Both in feauteres, design and strategy.

For example, when we focus on improving onboarding new customers in SpareBank 1 Utvikling, we didn’t talk about:

“Making it easier to become a customer i SpareBank 1”

We focused on what was most important in that time (quarter). Usually it’s a stepping stone from a larger, fluid strategy.

“We’re drastically making it easier for new customers to get started fast by enabling them to move all their money from their old bank to their new. We do this because the average bank connection a Norwegian has is 2, and it’s vital that we can get them up an running fast”

Does that mean we solely focus on moving money? No, but in that quarter that’s our biggst focus.

That elevates the discussion from “is the design cool enough” to:

• What do we want to achieve with this experiment?
• What’s our best guess on conversion rate on the experiment?
• Do we need to remove something to launch this faster?

What we build needs to be focused and precise, but not at all perfect. That’s because we never know how a solution will play out, we can only make educated guesses and test it out.

That’s why you need to measure.

2 — Measure what you do

The more experience I get, the more comfortable I get saying “I don’t know how this will work out. We just have to measure”

That’s because time and time again we’ve made stuff that we think is great, but end up being a fail with what we set the hypotesis to be. The beauty of a hypoteshis is that you can’t really lose, because:

• If the new solution converts better = great, we made something better
• If the new solution doesn’t do better = great, we learned something

We did an experiment a while ago where we tried to increase % of new users who a) ordered a VISA card right after becoming a customer and b) increase % who transferred money from old bank right away.

We did this by taking away a seperate page in our onboarding for VISA card, and added a switch on the first page. The theory was that the user would be more in motion to order a card since it was relative to getting a new bank account.

We where happy with the solution, but since we’re comfortable with experimenting, we didn’t throw away too many hours on it. We didn’t know how this would turn out, but it was an interessting experiment.

The results of the experiments were dead even with the original:

• 1.5% increase in VISA card orders
• 1% decrease in money transferred from old bank
• 2% improvement in drop off on page 1

We ended up trashing the experiment and going back to the original version, because having a seperate page for VISA card was too valuable compared to the minimal gains we got.

Now imagined if we didn’t have an experiment-first mindset and poured hours and hours to perfect the new version?

This experiment is a typical poster child of why we need to meausere what we do. All of us thought the new experiment would convert better, but it didnt — so we learned.

Rapid product development sets a demand that all of us must park our ego and go from “me” to what “we” want to achieve.

3 — Going from “me” to “we”

Perfection can come from insecureties. Some of these insecureties will heal with experience, but to create good products over time you need trust within a group.

It’s a process where everyone goes from mini-ownership (“my design, my code”) to “our solutions”. In other words, going from “me” to “we”.

This starts with you and the support you give to your teammates. Someone has to put their neck out and back up those who show of what they create. If you disagree with what they’ve done, it shouldn’t be about your personal taste, but questions or suggestions on how you think something will convert better based on what the focus is.

I’ve already written in depth about building a team from “me” to “we” which is called “The secrets sports teams can teach us about building teams”.

So, to conclude:

• Have a clear focus
• Measure what you do
• Support each other

And yes, I spent way too many hours flicking on this article.

No one is perfect 🤷🏻‍♂️

Howdy, you made it to the end! 🎉

P.S. Sometimes things goes too far, and people end up with depression. For that, I’ve written a short article On Pressure, Depression and Healthy Minds.

P.S.S. You can of course follow me on Medium, and Linkedin or Goodreads.

If you would like more stories like these, check out Failing Forward.

Helping People from the Pressure of Perfectionism was originally published in Failing forward book on Medium, where people are continuing the conversation by highlighting and responding to this story.

What you can’t do is ignore it. Or, as Yoda probably said to Luke in a 1:1 “Ignore stakeholders, you can not”

In my situation, SpareBank 1 is an alliance of 12 banks that are stakeholders to what we (SpareBank 1 Utvikling) do. This is of course massivly simplified, because there’s internal sections, departments yadayada but that’s not the point here.

The point, or rather the goal, is dead simple: You want your team to have full aunotomy of what is prioritised. Not just for a period of time, but it to be a constant.

To achieve this, you need to collaborate with the stakeholders, because:

• They also want success
• They usually have a lot of good insight and experience

The unsexy truth on collaborating

I don’t think there’s one way of collaborating with stakeholders, because there’s so many types of stakeholders and products. However, I have worked both in agencies, with my own company and now here and I’ve tried multiple ways of working with stakeholders. With that, I’ve found this set up to work really well — for the needs of my team.

Every other week, I have three seperate 30 min meetings with a contact in three of the largest banks.

In those meetings, we usually go through:

• What are we focusing on now and why?
• In what we are working on, what are the upsides and what are potentially pains?
• What are we not focusing on now, but we think will be smart in the future?
• How are our experiments going?

There is never any power point slides or polished pitches. Usually I simply share our Miro board and we go through the points over.

In those meetings, the stakeholders will get full transparancy on:

• Insight into all our solutions
• Data on what works well and what can be improved
• Pains and barriers we have
• All of the things we can do, and what we choose to do

What we get from this is:

• Way better and honest communication, since we have full transparacy
• Great insight that the bank(s) can provice
• Great sparring sessions
• The contact person becomes an advocate for our joint mission in their bank
• More focus for the team, because we don’t get any random orders

That’s it...

No sexy framework for collaboration.

Just consistent communcation — every other week for 30 min.

It’s just people, man

The word “stakeholder” is used so often that it’s become an entitiy of it’s own (much like the word “silo”), when it’s actually just people. Individuals who wants success just like you, so the product get’s better.

The major difference is if you’re working for or collaborating with stakeholders. The latter is obviously what you want.

Conflicts can happen when there’s not a joint agreement or understanding of what success actually looks like. And, even if everyone agrees on the goal, the road to get there can also be filled with subjective opinions.

The key to fix that, and to any good collaboration for that matter, starts with clear and honest communication.

The major key is consistency

If you need a multiple hour workshop to “work with the stakeholders so everyone is aligned”, you’re really trying to fix a problem that has gone to far.

Sometimes it’s necessary to gather key people in a room, but often it’s a political move. An illusion of collaboration and movement forward.

I’m not hating on all workshops, but I have sat in my fair share of grueling workshops where you’ve spent 2 hours too long in a conference room, waiting to hang up your obvious post-it notes, only to have all the work whisk away in the wind. Those workshops, I hate.

So, to sum up:

1. Collaboration is communication.
2. Stakeholders are people.
3. Communicate more with people.

Nice, you made it to the end! 🎉

P.S. On a related subject, check out On Writing Descriptions.

P.S.S. You can of course follow me on Medium, and Linkedin or Goodreads.

If you would like more stories like these, check out Failing Forward.

Collaboration With Stakeholders was originally published in Failing forward book on Medium, where people are continuing the conversation by highlighting and responding to this story.