1

Note: ​This is a teaser of our internal Product Management 101 Handbook (referred to as PM101). This document contains a number of extracts
from the actual book to give you a short introduction of Product Management at Klarna.

Introduction

Part I What we believe about Product Management

1 Good Product Manager vs Bad Product Manager

2 Customer obsession

3 The product vision

Part II How we do Product Management at Klarna

 2

Introduction
Product Management 101

This book is like Product Management. Iterative.

It contains our current best thinking around best practices for Product Management at
Klarna. Its purpose is to create a common language and understanding of Product
Management, and to align everyone with our core mission: to build products that solve
real customer problems.

Here, you will find knowledge and learnings collected from 10 years of product
competence at Klarna. Some of the best practices described reflect our current ways of
working, while others reflect the way we aspire to work. We want—and expect—the way
we work to evolve. And we want to stretch and move ourselves in the right direction.
After all, there is no steady state— we know this to be true just by observing how much
our thinking has evolved since we wrote the last version of this book. We will learn and
adapt, and we aim to exemplify this ethos throughout the book.

This book is divided into three sections. In the first section, we summarize the beliefs
and principles that influence the way we approach Product Management at Klarna. The
second section explains what our working process looks like. And the third section offers
a series of practical How-to Guides to help you navigate some of the most common tasks
and challenges you will face as a Product Manager.

Given that the purpose of this book is to create alignment among Klarna Product
Managers, each of us is expected to read, reflect upon, and integrate its guidance into
our daily working lives.

That being said, don’t settle for this book alone. It’s perfectly fine to ask, Why? And to
challenge its contents (this will only make the next version better). You should also take
steps to cultivate your own views on Product Management. Actively read, explore, and
try new things. And please, share what you learn with the rest of the team.
 3

The beliefs and principles influencing the way

we approach Product Management at Klarna.

The way we approach Product Management is very much aligned with the way we work
at Klarna. We believe that teams who own problems, not features, will develop a deeper
level of expertise.

We are here to solve real problems in ways that customers love. To succeed at this,
Product Managers must become the leading experts of their own problem space, build
knowledge on what works and what doesn’t, have the ability to drive a product towards a
long-term vision, and practice good Product Manager behaviors in the process.

At least this is what our beliefs about Product Management look like so far.

We’ve come a long way since Product Management was first introduced at Klarna in 2011.
We are constantly learning and evolving when it comes to the way we think and act as
Product Managers.

Over the years, we’ve been influenced by various thought leaders, a great number of
books, and the many Product Managers who have walked through Klarna’s doors with a
diverse collection of insights and experiences.

But, for the most part, we have learned through trial and error.
 4

Chapter 1
Good Product Manager vs Bad Product
Manager

We can’t talk about our beliefs and principles of Product Management without first
addressing the behaviors which, in our experience, produce the best results—as well as
those that produce less optimal results.

What follows is a list of what we consider to be “good” and “bad” Product Manager
behaviors. The original version of ​Good Product Manager/Bad Product Manager​ was
written by Ben Horowitz and David Weiden in 1996, at a time when Ben Horowitz was the
Director of Product Management at Netscape and needed to communicate his
expectations with the Product Managers on his team. We like this format because it
provides an easy way to spot the differences between good and bad behaviors, without
leaving much room for interpretation.

These behaviors should be viewed as signposts, not commandments. Follow the good
ones, watch out for the bad ones. And, keep in mind that few Product Managers will
actually live up to every one of the good behaviors at all times. That said, we do hope to
inspire you to be more conscious of adopting good behaviors which are most likely to set
you up for success.

Good vs bad Product Manager behavior at Klarna

Good Product Managers​ always make decisions in favor of the customer— even when it’s
hard or uncomfortable. Bad Product Managers don’t put their customers first.

Good Product Managers​ create a long-term vision first, then deliver incremental value
towards the vision. Bad Product Managers don’t have a solid vision and, instead, deliver
short-term value.

Good Product Managers​ are responsible leaders. They understand that their behavior
sets the standard for others. Bad Product Managers fail to recognize mistakes—or come
up with excuses—and, thus, don’t learn from them.
 5

Good Product Managers​ embrace the concept of empowered teams and work with their
teams to deliver on the vision. Bad Product Managers want to run everything themselves,
viewing themselves as the sole decision makers (and creating bottlenecks as a result).

Good Product Managers​ take all the steps necessary to give their product the best
possible chance of success. They are aware of what they know and why they know it, as
well as what they don’t know. They go to great lengths to ensure nothing falls between
the cracks and enjoy the accountability. Bad Product Managers leave things to chance
and don’t attempt to fill knowledge gaps.

Good Product Managers​ measure success based on KPIs that put the customer
experience first. Bad Product Managers don’t know why their product isn’t performing
and fail to recognize the value of user experience details.

Good Product Managers​ spend their energy solving problems. They are curious and
always start by looking for information independently. Bad Product Managers come up
with a problem and ask for a solution. They don’t investigate or try to collect information
on their own. Instead, they call for meetings to get data presented to them by others.

Good Product Managers​ are brave and report any flaws they discover in a product. Bad
Product Managers don’t speak up because “it doesn’t fall within their area of
responsibility” or “ isn’t their problem.”

Good Product Managers​ have a system in place to ensure they always have enough time
to meet with customers. Bad Product Managers fail to plan their time, don’t delegate
work, are always busy, and “don’t have enough time” to meet customers.

Good Product Managers​ take immediate action following a discussion and/or conclusion.
Bad Product Managers allow questions and/or discussions to remain unresolved and
keep falling back into the same discussion.
 6

Good Product Managers ​take responsibility for their outcomes. They can articulate what
value and contribution their product generates for both our customers and Klarna. Bad
Product Managers fail to correlate outcomes with generated value and struggle to
communicate the business model of their product.

Good Product Managers​ balance qualitative insights with quantitative insights. They
validate hypotheses with users before building. They have a strong vision that guides
their decisions until the product is live and can be improved with real data. Bad Product
Managers say, “We can A/B test” to determine the direction of a product without taking
their vision or qualitative insights into account.

Good Product Managers​ master written narratives and put customer value, important
arguments, strategies, and plans into clear and concise documents. Bad Product
Managers have trouble getting their thoughts out on paper and either fall back on
presentations and verbal arguments, or present lengthy pre-reads that never get to the
point.

Good Product Managers​ let the product speak for itself. Bad Product Managers need to
explain why their product is good or how to use it.
 7

Chapter 2
Customer obsession

Klarna has always been a customer-obsessed organization. So much so that we’ve made
“Customer Obsession” our first Klarna Leadership Principle. Being a customer-obsessed
company requires constant and dedicated focus on our customers. We believe our
customers are loyal to experiences, not to discounts or tradition. They’ll leave us in a
second if we fail to serve their needs with the best possible experience. For this reason,
we can never ever let our focus slip.

Maybe it sounds easy to be “customer-obsessed” but, in reality, it’s really hard. A

customer views Klarna as a single entity while we are, in fact, hundreds of teams. The
most important thing is to give our external customers a holistic experience— one that
goes beyond any team or scope.

If anyone’s obsessed with customers, it’s Product Managers

It’s easy to spot the difference between a Product Manager who cares about their
customer, and a Product Manager who ​really​ cares about their customer. You’ll notice
that a Product Manager demonstrates care by how frequently they meet with their
customers, how they show empathy, and the way they handle tricky situations— such as
friction-generating product changes. A Product Manager who truly cares about their
customer will always make decisions in their customer’s favor.

Being customer-obsessed is about putting ourselves in the shoes of our customers and
viewing an experience from their perspective. It’s about understanding their needs and
the problems they face. It’s about knowing what will trigger them to either adopt or
abandon a product. And, it’s about understanding what makes them praise a product
and share it with their friends.

Despite all the measures us Product Managers take to prevent problems for our cus-
tomers, sometimes, we fail. But it’s in these situations that our true customer obsession
shows. Just look at the lengths we’ll go to in order to put the customer first— even when
it’s uncomfortable for us. Or how we can turn a negative incident into something that’s
positive for the customer. It’s all about building trust, and never losing that trust.
 8

Chapter 3
The product vision

A team is born at Klarna whenever we recognize a new problem space and someone
begins to wrap an ambitious vision around it. That someone is often a Product Manager,
and the first thing they are responsible for is developing a vision that articulates the
future state of their product.

However, setting a vision is not something a Product Manager does apart from the team
and ​then reports back on later. It is crucial that the team takes part in the process of
setting the vision in order to achieve a full buy-in from each member.

What’s a product vision?

A product vision describes what your product will be in the future and why we are
creating it in the first place. It describes the purpose behind the product and what it
aims to achieve for the customer. A product vision should be grand, covering a 3-5 year
timeframe with 6-9 month prototype development "sprints" to help visualize the future
state of the customer experience in slightly more detail. It’s the big audacious goal
guiding all of us as we strive to create value for our customers. It’s the reason we show
up to work each day. It inspires the whole team, and reminds us why we are doing
something— on good days and bad. It needs to be powerful enough to get everyone to
buy into “the why” (the problem the team is solving, and for whom.) And clear enough to
create alignment around the future state of a product. So think big, then bigger, and
always think long-term.

Why you need a product vision

Without a solid view of where you are heading, it’s easy to lose focus and jump from one
idea or opportunity directly into solution mode. Without a vision, it’s likely you’ll end up
feeling scattered as you attempt to account for all the needs of your stakeholders. Or
you’ll get caught up weighing features against cost/value, create a backlog of features
and turn into a feature factory. This is a short-term way of thinking. And, it might evolve
your product in the wrong direction, resulting in huge opportunity costs and waste.
 9

As Product Managers, we set high ambitions, and believe that we can only achieve them
if we can see our vision clearly. This ensures that teams can work towards a common
purpose, identify what’s important or not, and stay focused. A vision also serves as a vital
source of inspiration, getting everyone excited about what we are creating together and
catalyzing action.

Understand the problem space first

Before you can set the vision, you need to have a good understanding of the problem
you are solving. If you are new to the problem, you will need to invest time in
understanding it before attempting to set a vision. Developing a vision is not an exercise
that can be completed within a few days or during one or two workshops. A well-defined
vision is an important investment that can support the team for the next couple of years
or more. It creates a common understanding of the problem space, which—in the
grand-scheme of things—is very valuable.

To borrow a seed of wisdom from Jeff Bezos, founder and CEO of Amazon, “Be stubborn
on vision but flexible on the details.” If we pivot on a vision, we either haven’t defined and
aligned with it well enough in first place, or we are giving up too early.

Visualize the future state of a product

A vital step in the creation of a vision is visualizing the future state of your product. It’s
one of the first things you should do whenever thinking about a new product or bigger
feature. Here, the goal is to illustrate your vision and make it real. It shows what you want
to create and why you want to create it. Visualizing the future product state is a helpful
technique for getting to the core of your product, and will force you to think ahead and
imagine what it will look like once it has launched.

When considering the future state of a product, you need to think big. The two main
rules of big thinking are:

1. Know what challenges your customer is facing

2. Think BIG
 10

When familiarizing yourself with customer challenges, dig deep. We want to get down to
the root cause of the problem and solve that, rather than just treating the symptoms.
Then ask yourself: What if there’s an even bigger solution? If you go through the process
of asking yourself this question a few times, you will likely land at an ambitious idea.

The audience of the future product state isn’t only your team, peers, and stakeholders,
but also anyone in the organization who might be interested. That’s a wide range of
people and, therefore, the future state needs to illustrate exactly what problem your
product is solving, the benefits it will bring to the customer, and why the product is
needed in the first place. This format requires you to be very crisp about what success
looks like. The goal is for everybody to understand the customer value of your product.
Remember: If the receiver doesn’t get it, or doesn’t see the value, then there is more
work to be done.

When the time comes to illustrate the future state of a product, combine the written
word with a visualized experience— it’s the strongest way to show the future state of
your product. Use the “Imagined Press Release” or “Customer Letter to the CEO”
formats, complemented with a mockup of what the user interface and user experience
will look like. For a backend team, you can also add a future API spec as an alternative to
a mockup.
 11

What our working process looks like - from

product hypothesis to usability testing to launch.

Building products is not a linear process. It’s an iterative one. In the first edition of
Product Management 101 (released in 2018), we distinguished between three different
phases of product development: Discovery, Delivery and Launch. Describing them as
phases might have come across like we work on Discovery for some amount of time, and
once Discovery is complete we move on to Delivery, and once we are done with Delivery,
we Launch. And that’s that, we are done.

This sort of triphasic mindset limits us by attempting to force activities into each phase
and, worst of all, it sounds like we are done when we launch something. Which, as we all
know, is never true.

In this second edition of the book, we will not talk about phases when outlining our
working process. Instead, our starting point will be the cyclical and iterative process that
can be found at the core of product development at Klarna: ​Build, Measure, Learn1.

There will always be some trial and error in the product development
process
We need to acknowledge that regardless of how much we prepare for a new product​—​or
strive to maintain an existing one​—​there will always be new learnings once we get the
product out to real customers, and there will always be a certain amount of trial and

1
​Eric Ries described the idea of Build-Measure-Learn in the book ​The Lean Startup
 12

error before we reach the right solution. For this reason, we need to optimize to generate
learnings as fast and cheaply as possible, and leave room to adapt our plans with new
insights.

The earlier we can learn, the sooner we can adapt. If we can learn something already
when we show a prototype to our customers, that is far cheaper than having to build a
product first. An important part of this is focusing on the outcomes we want to achieve
instead of the features we are going to build. When we talk about features, it’s easy to
trick ourselves into the perception that launching a feature is the goal, while the truth is
that we “hope” that the specific feature will solve a particular need. We’ll never know if
we were successful until we actually launch and watch the consumer behaviors change.
So, launching a feature is just one step towards reaching the outcome we want. Either we
see traction in the metrics and continue to iterate on the solution, or we learn something
new and start over.

It’s only when your hypothesis is validated by customers that you can
truly know if you are on the right track

We can’t fully understand our users if we don’t spend time with them— preferably face to
face. Validating our hypotheses with customers is a vital part of the product
development process at Klarna. Hypothesis validation can be achieved through
techniques like user research and usability testing, and it allows us to get early feedback
on ideas, concepts, and features from the people whose opinions matter most.

“Instead of thinking of a product as a series of features to be built, Lean

UX looks at a product as a set of hypotheses to be validated.”
Laura Klein
Author of ​UX for Lean Startups: Faster, Smarter User Experience Research and Design
 13

Books we like
and refer to in the PM101
Creative Selection: Inside Apple's Design Process During the Golden Age of Steve Jobs,
by Ken Kocienda

Escaping the Build Trap: How Effective Product Management Creates Real Value, by
Melissa Perri

Good Strategy Bad Strategy: The Difference and Why It Matters, by Richard Rumelt

Inspired: How to Create Tech Products Customers Love, by Marty Cagan

Principles: Life and Work, by Ray Dalio

Project Retrospectives: A Handbook for Team Reviews, by Norm Kerth

The Lean Startup: How Today's Entrepreneurs Use Continuous Innovation to Create
Radically Successful Businesses, by Eric Ries

Thinking, Fast and Slow, by Daniel Kahneman

UX for Lean Startups: Faster, Smarter User Experience Research and Design, by Laura
Klein

Product Management 101

Second Edition
Copyright © 2020 Klarna Bank AB (publ)