Skip to main content

Dear Scrum Team, Does Your Product Make Your Users Happy? 6 tips for more customer focus.

July 28, 2021

Every company has customer focus in its vision or mission statement, but is it really?
As an employee of a development team, how do I know if this is the case?
How do I know we are are customer obsessed company?
How do I sense it? 

These are the questions we want to explore in this post.
Let's start with a simple question for the team:

The Customer
The Customer


How many people are between the user and the development team?

Typically, you see something like this:

People between the team and the customer


Often there are project managers, business analysts, requirements engineers, deputies, steering committees, usability experts, testers, or QA teams between the team and the user.

I see the user(s) as our most important customer, because if the user is not happy, no one will pay for the product (sponsor), nor will any other market participant be interested in it.

What can the Product Owner do to improve this situation?


I have collected 6 tips for this:

1. Invite the User

Instead of focusing on the perfect requirements and investing an extreme amount of time there, I would recommend bringing the user closer to the team. Do we ever want to invite a user to the sprint review? Or to the team room and show how we work and ask him for feedback on the current feature?

The Customer in the Sprint Review

What can I do to detach myself as a Product Owner even more from this system and focus more on the product strategy instead?


2. Merge Teams instead of splitting them up

Instead of splitting teams into specialized silos, such as a test team or a QA team, which then pass on work to be able to develop more "productively" themselves, I would recommend bringing teams together.
Too often I have seen "bug ping pong" between teams and never found it to be efficient.

I would strongly recommend bringing teams together, pairing or mobbing or ensemble programming and completing and finishing (Definition of Done) features (Product Backlog Items) together.

Read the blog "5 practices that help with agile software development" for more information.



3. Introduce Feedback Moments

Instead of accepting or "rejecting" Product Backlog Items, I would recommend as a Product Owner to look for a different way of collaboration. For example, "feedback moments" go in this direction, which allow to bring the user directly to the team and let them give feedback.  Feedback moments can empower the team, to whatever they need and confront them with the user problems instead of delivering pre-chewed solutions. This also helps with motivation.

Product Owner rejects a PBI
A Product Owner rejects a feature


PS: Accepting or rejecting also implies a hierarchy, which we don't want to have in a Scrum team. So call it feedback moments.



4. Celebrate added Value instead of busy KPIs

Instead of celebrating Velocity, Utilization and "Feature Completeness", we should define success as Impact for the user.
What in the user's world is made better by our product?

Empathie for the User

How does the team get more empathy for the user?

More ideas on this in this Twitter stream from me.

5. Break down large features into smaller goals and bites

Instead of working through big features (large batches) over multiple sprints, I would recommend working in small steps. How can we break down the big product vision into actionable sprint goals?
Into daily goals that we can celebrate and measure as a team?

It's counterintuitive to work in small batches, but progress and discipline bring faster successes and allow the product to become deliverable faster.

6. Delegate Sprint Goals

Instead of doing everything myself, I think about what I can delegate as a product owner.
Can I delegate the entire sprint goal to a department?

Thought example: "For the next 2 sprints we are working on features for the internal marketing department. Please talk directly to Stefan from the department and just keep me updated. I will always be present at the Daily Scrum."

In other words, I delegate the responsibility about the content of the product to another person and just get more information for decisions when I need it.

Alright... 6 experiments to try and let me know of 😀.


Could you stay quiet as a product owner and let the team run on its own for the next two sprints?

Why not?
How far away is the customer from the team?


What did you think about this post?