Hey Reader,

It's a new week, and I'm here with a new email for you with some thoughts and insights I had over the last week. I'm trying to get on a schedule and send you regular emails.

So this past week I have just finished a big product, and so it opened up new opportunities. Or more like, it opened up new spaces in our product backlog.

Of course, that means new ideas, new wants, new projects.

And it makes me think of all the teams that experience this flow of new stuff every day when their priorities change.

What I definitely learned while building many different products for you, is that Done is better than... anything really.

It's better than a well-defined idea. It's better than the hype created around that feature. It's better than perfect!

It's usually better to finish one thing and see how it does, rather than start something new because it might be better.

And I also learned that sometimes what we think customers want is not at all what they want, and what we think is a stupid idea turns out to be exactly what customers need.

That might be one of the reasons why many teams struggle with constantly changing priorities. Because... does anyone really really know what's gonna bring the most value in the end.. (that was a rhetorical question)

Ok, so how do you decide what to build then?

What I saw in my business is - trial and error.

Sure, with initial user research and insights, you may make a couple of decisions and then see how it goes.

You gotta start somewhere.

And here's where I believe many teams and companies fall into a trap - a trap of believing that they figured out what their customers want.

And this comes to the concept: past success cannot guarantee future success.

Whatever you are building, however much success you had in the past, you should always validate what value was realistically delivered.

What I mean by that is simple and hard at the same time:

• You make decisions about how to order the Product Backlog (well, your PO does) based on estimated value for the customer.
• When the thing is delivered, you need to validate whether your value estimation was correct.
• Use that analysis to make decisions on what to build next: build things that work, stop building things that don't.

Now a question: how many teams have you seen doing it?

I'll share a secret - I don't think that I've truly seen this done to the extent it needs to be.

I think where it is usually done the best is when a team is working on a customized product for a specific customer.

Then they would usually have very tight communication with that customer, so they would be able to show it and get feedback.

By the way, by validating the value I don't mean showing it to key stakeholders, and basta.

No, no, no. I mean - validating with end users.

If you are selling something, even if your customers say that would love it, the real test is when it hits the market and you look at your sales.

It happened to my products multiple times where customers would be asking for something, and I would spend time creating that product, only to find out that people don't really want it.

I think the prime example of that is my Jira online course. This is definitely something a lot of people were asking, but in the end it is not the most successful launch yet.

The thing is - it's a new type of product, so I had to validate my assumptions.

Now if we talk about the Product Owner Guide, I'd say it was a moderate success and I am not surprised.

The reason for that is the success of the Scrum Master Startup Guide. I know now what customers (you) really need - practical tips and usable tools. This what brings value.

However, even if a similar product was a success, I cannot assume that any other will be a success by default.

That's why that validation step is important.

And, of course, not to forget the step AFTER releasing something - validation of your assumptions.

This is the step that will help you get a better (not perfect!) understanding of your customers' needs and make decisions for what to work on next in your Product Backlog.

Ok, so after this looooong rambly email, let's think about what you can do today to help your team prioritize better.

Are you collecting metrics after the release? What could help you understand whether what you built brings value? Who could be the right person to provide feedback?

Think about the process you can set in place to facilitate the collection of these metrics.

The first easiest step, of course, is the Sprint Review. And I talked about that a couple of times.

But you need to be more intentional with it during the Sprint Review. I share some new advice in the PO guide.

By the way!!! For the full launch of the Product Owner Guide I'm offering a special discount for you but ONLY until the end of August.

Use the promo code PRODUCTOWNERLAUNCH to get 25% OFF.

The offer is only valid for the next couple of days, until August 31st end of day EST.

I hope this email gave you some new insights that you can bring to your team today.