What actually empowers a team? Despite all the talk about empowered teams in tech, there’s often confusion about what real empowerment looks like.
At its core, an empowered product team is given significant customer or business problems to solve, rather than being handed features to build. But it’s not enough to simply assign problems – true empowerment requires the right environment to succeed.

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.

Dive into the essence of the Product Model, a transformative approach embraced by leading companies for consistent innovation at speed. Explore how this model, codified and championed by industry thought leaders, empowers teams, accelerates innovation, and reshapes organizational success in our dynamic, VUCA world.

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

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.

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

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

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

A couple of weeks ago I started a new hobby. I’ve found a way to combine teaching agile and lean with creativity, art, Lego and Star Wars. Now I love spending time slowly putting Lego blocks together to create scenes. One by one. Very meditative and creative 🙂 The scenes I build I then use

When is a so-called requirement really required? And is it the “right” requirement? The answers depend on many facets: stakeholders, value, planning horizon, and so on. This article explores using options as a means to identify high-value requirements, at the last responsible moment.

My Requirement May Be Your Option

Product requirements are needs that must be satisfied to achieve a goal, solve a problem, or take advantage of an opportunity. The word “requirement” literally means something that is absolutely, positively, without question, necessary. Product requirements must be defined in sufficient detail for planning and development. But before going to that effort and expense, are you sure they are not only must-haves but also the right and relevant requirements?
Continue reading

Here comes a new post from Ellen Gottesdiener who comes to Stockholm to hold her highly appreciated course Agile Requirements Analysis and Planning for Product Success.

In a recent interview in the New York Times, Panera Bread co-CEO Ronald M. Shaich talks about the importance of de­veloping an organization’s “discovery muscle” as well as its “delivery muscle.” Most companies have worked hard to perfect delivery—how they get work done—he says, because delivery “feels rational, people feel much safer with it, and you can analyze it.” But discovery—the activities you undertake to define or change your product, service, or market—is about “leaps of faith. It’s about trusting yourself. It’s about innova­tion.” The key, Shaich says, is for the discovery muscle to be at least as strong as the delivery muscle.

He took the words right out of our mouths. This need for balance between discovery and delivery applies in spades to software development. Our new book, Discover to Deliver: Agile Product Planning and Analysis, explicitly makes the case for equally balancing your commitment to these key ac­tivities. We define the relationship between them: In lean/agile software development, discovery and delivery are interwoven, interdependent, continuous activities (see figure 1). Each feeds the other.

Continue reading