When helping teams and companies shift towards the product model, one of the key concepts introduced is practicing product discovery. Prior to this shift, a typical scenario starts with a stakeholder—someone up top—sharing detailed requirements on what to build. This approach leaves the so-called “feature team” with very limited opportunity to influence the solution. Now,

A few days ago I was asked an interesting question by a product team coach at a new client that I want to share with you. Q: – What can I do to help my team practice discovery? I understand it for customer experience facing teams, but my team is an enabling platform team. What

Dive into the Product Model’s key insights (focus on outcomes), and core idea (the empowered engineer) to re-invent your teams to become Empowered Teams.

Joakim’s Note: Spotify is an exceptional company, the best I’ve ever worked for. When I left the company after more than six years, I wanted to help other companies become more like Spotify. However, I didn’t believe companies could merely copy the organizational structures of tribes, chapters, and squads that have come to be known

Where are we heading? What’s the future going to look like for our product? Let’s pause here. There is a sad truth. Most companies don’t answer these questions in a meaningful way. Being fortunate to meet many diverse companies in the world, the top struggle is direction. Commonly, talking to individual contributors, managers, and senior

Q: What is the best way to get customers and empowered teams closer so they could understand each other? And keep up with it so it is not a one time thing. In our organization we have done a few experiments with customers, but we have been struggling to make it a regular and deliberate

Q: How can we get better at throwing away ideas that our teams have already started to develop, but do not see market traction from? In our organization we often miss out on the discovery part of building products. We often have a sense of urgency to get on with it and start to develop

The following is an excerpt from the recently released book by Martin Christensen and me titled Holistic Product Discovery. It’s been a 3-year journey that started with a 20-page draft. Numerous iterations later, here we are. Thank you to the fantastic community of readers for your invaluable feedback. Let’s begin. A story about a product

This week I presented the Holistic Product Discovery framework at an Airtime webinar hosted by its CEO Akos Kiss-Dozsai. Here are some concepts that I went through: Some uncomfortable statistics relating to product development Principles that could help you in Product Discovery The Holistic Product Discovery framework A risk mapping technique to kick off Product

How to successfully drive initiatives, objectives or opportunities that require several squads (or teams) to succeed? How to do this in a way that respects the agile mindset without falling into the command-and-control trap? Today, this problem is more complex than it seems. We’ve designed and built our squads for self-organization and autonomy in the

This is the second article in my series on integrating discovery and delivery. In the first article I outlined some common challenges I have seen holding organizations back from benefiting fully from both.

In this article I will introduce some patterns that will help you integrate product discovery and product delivery in a way that works. These patterns have all been field tested in practice.

Most organizations that I meet in my work are struggling to integrate product discovery and agile delivery in a simple practical way that works.

I will illustrate what I mean by giving you examples of a couple of very common issues.

The room was packed. Erin, the Product Manager, had called for an emergency meeting. The product they had just launched wasn’t meeting expectations. Erin stated with a determined voice: “We need to do more Discovery”. The room went quiet.

With confused looks, the team glanced at each other: “What does she really mean?”. “What does she mean by ‘Discovery?’”.

Perhaps this scenario resonates with you. A situation where the term “Discovery” is used, but it’s difficult to discern what it actually entails.

To be fair, the term Product Discovery is ambiguous.

My intention with this article is to try to demystify what Product Discovery is and to give you two Playbooks you can use.

Design studios are useful for helping a group of people converge on an idea. This post provides a PDF presentation for facilitating a design studio workshop, including an additional optional section for refining ideas when the desired result is to generate multiple ideas. The general pattern is:

• Generate ideas
• Present
• Get feedback
• Refine and converge the ideas

In my prior blog, I shared that the Product Canvas is a tool anchoring a shared understanding of your product. Part 1 of the canvas provides contextual and strategic information. Part 2 summarizes the key compositional element of your product requirements using the 7 Product Dimensions.

Continue reading

What is your product?

If you ask your product development team members, product managers or owners, colleagues in finance, service or operations, marketing, sales, compliance, and all the other departments and teams that make up your organization, would they agree?

It might surprise you to realize that for many organizations, not everyone has clarity around something so fundamental. I’ve developed a Product Canvas to address this issue. The canvas also helps product managers or owners proactively steer their products.

Continue reading

I guess you, like the most of us, have a problem breaking work down to small but still valuable pieces and that your MVP (minimal viable product) is more or less the same as the project scope. If you recognize yourself in this than keep reading.

Continue reading

As a product owner, your job is to make assumptions, or hypotheses. (Hypothesis-driven product discovery, anyone?) You assume that your priorities will be the best outcome, the shortest time to market or something else. But how good are your assumption when it comes to reality? Did that sale increase occur and was it thanks to your great mind or just pure luck? Do people around you understand and help you with your assumptions? Impact mapping is a lightweight tool that helps you with quantifying and communicating your assumptions.

Continue reading

In the talk I gave at Agila Sverige in June, I brought up misconceptions about UX I’ve encountered during my years in the IT business. One of these is that it’s only the UX people (and possibly the PO) who need to meet the users. In this post I’ll discuss why this not true, but also how meeting the users can make a real difference in focus and motivation for the team.

Continue reading

Adapting to accelerating change

In a world where the speed of change seems to accelerate almost exponentially, it is only natural that an organization’s way of working must be constantly challenged and improved – especially in the highly competitive media business.

This text, which was inspired by winning an award (we will return to that), is the outcome of a joint effort between Michael Göthe, Agile Coach at Crisp, and Jens Abrahamsson, Agile Coach at Telia Company’s TV & Media Backend department. In it, we describe parts of the always-ongoing journey towards a more lean and agile way of working at the Telia TV team.

As always when looking back at a complex change process it is not possible to copy what we did but our intention is to share useful learnings, practices, and tools that can inspire you on your change journey, in your context.

Continue reading

Today I met a crowd I do not bump in to all that often; project managers. I decided to share insights from Agile projects, stretching from Hospitals to Digitilization, how they simplified and speeded up their pre-studies. Learning how to do so well, helps avoiding the “we have to speed up implementation, to make up

I recently attended a course (the excellent LeanUX course held by my colleague Martin Christensen) and again the topic of what a MVP is or is not came up in a discussion. In the Lean startup-world an MVP is defined as the smallest thing you can make to validate a hypothesis which helps you decide if you should continue developing something or if you should stop. For more information about this, I suggest you read Eric Ries’ blog post on the topic. However, in (very) many companies and organisations the term is used to describe the first version of a product released to the end customers. This “version one release MVP” usually contains as little functionality and features as is possible without making the end customers too upset, disappointed or unwilling to pay.

Another colleague of mine, Henrik Kniberg, wrote a quite thorough and lengthy blog post about MVPs a while back where he touched upon the point I’m about to make. While quite a few people see the different uses of the word MVP as problematic, I see it as a symptom of a need for a better word for describing at least one of its currently used meanings, i.e. the “version one release MVP”. Luckily enough a good friend and coworker gave me the answer to that need a few years ago: He called the first release of the hardware product we were working on at the time the “Minimum Loveable Product”.

Continue reading

Karlstad sjukhus har i flera omgångar byggts om och byggt ut. Samtliga hus har levererats på tid, budget och med en fungerande vårdverksamhet från dag 1. Sjukhuset har sparat 300 miljoner åt Värmlands läns landsting. Lösningen? Effektstyrd upphandling med Agila kontrakt och Partnering. Vad skapade förutsättningarna för att lyckas? Vi intervjuade Lars Nilsson, som ledde upphandlingen av Karlstad sjukhus.

You’d think the topic of value would be straightforward when it comes to agile product management and ownership. After all, early and continuous delivery of value is the first principle in the Agile Manifesto and product backlogs need to refined based on value.

And yet, value is not easily defined, qualified, quantified, or agreed upon.

With many smart, experienced folks together at the Agile Product Open last month, I decided it would be informative to propose the topic “Value: The Whats, Whys, and Hows” in the marketplace of ideas.

To start the conversation, I offered my favorite definition, borrowed from the Value Standard: fair return or equivalent, in goods, services, or money, for something exchanged. From there, our conversation grew richer and deeper.

Continue reading

Hi! I recently did a podcast together with Dennis (CIO Nordnet) on #slowtofast. I walked into the podcast thinking it was going to be about Kanban and Enterprise Agile. Right! 🙂 Dennis hit me with these simple questions.. The essential elements of proper Product Management The management principles of an Agile leader How the Swedish culture is

Continuous discovery means an open backlog where everything is considered speculation and hypothesis. Continuous validation means that the user experience is validated for each release, rather than up front. This may sound like big budget to you, but let me give you a case study, about how a single team accomplished it on a tight budget.

A small team with a small budget has the advantage of not losing its head with big ideas from experts in different fields, be it architecture or user experience. The budget constraint sharpens your effort in a way that could be healthy even to a larger team.

Continue reading

Do you, a developer, have a feeling that the user stories your product owner is but a list of ideas prioritized on gut feeling only? That the relationship between them and their purpose are vague? Impact Mapping is an agile conversational tool by Gojko Adzic that may be primarily for product owners but hey, a developer needs a purpose too!

Continue reading

For  this year’s Stop Starting conference, we asked ourselves three questions: How do you develop awesome products? How do you bootstrap a successful mega project using Agile contracts? How do you use Agile and Lean thinking to turn a stagnant company around? We then picked the brains of people from real companies who have been

Just back from Hookedfest – a conference for product people. It’s refreshing to see and discuss product development from a market and product perspective, in contrast to the “what can we build” perspective we all to often resort to as engineers. It was interesting to see other speakers (for example the Google guy) share similar experiences on

My new book – “Real World Kanban” is now available. Here’s the plot in a nutshell: What happens when Kanban is used in real projects? Kanban has few rules, but an infinite number of strategies. What seems easy in theory can become tangled in practice. So there’s nothing like learning from real world cases. Learn how