Home → Part 18

Product Owner: The Person Who Says No, Not a Ticket Writer

Monday, 29 September 2025, 09:40, sprint planning. Our PO, Gizem, opened her screen. Under the title “Priorities for this sprint” there were 7 items, and all seven were P1. “Which one first?” I asked. “All of them,” she said. “Three different people made promises.”

Sertaç Yıldırım · 8 March 2026, 21:00 · 10 min read

From the field: seven P1s and three promises

Gizem had joined the team two years earlier as a business analyst. A year later her title became Product Owner. The only thing that did not come with the title was authority. The customer’s operations director did not tell her what he wanted. He told our general manager. The sales team gave dates during new contract talks. The customer’s accounting team wrote directly to developers. Gizem turned all of this into tickets and marked all of them P1.

This was not weakness. Gizem had tried to say no twice. Both times, the person who asked went one floor up, and a message came from the general manager: “Squeeze this in.” After that, she stopped trying. A PO whose “no” is overruled above her head learns to say yes.

Part of the mistake was mine. I asked Gizem for good tickets: acceptance criteria, screenshots, edge cases. I judged her by ticket quality. When the sales manager came to me directly, I did not send him to Gizem. I said, “We will look at it.” So I was also one of the people who skipped her order.

After that planning, I looked at the last six sprints. Between July and September, 45 stories had entered the sprint. 30 of them, or 67%, came in because of a request “from above”, not from Gizem’s own order. The backlog had 212 items, and 64 of them were marked P1. One in three P1s was more than a year old.

My three weeks as stand-in

The worst line in this picture was the one I wrote. From 11 to 29 August, Gizem was on leave, and I was her stand-in. As tech lead, I had a list of work we had been postponing for months. It included cleaning up logs, removing an old reporting module and automating the test environment. At the planning on 18 August we took 9 items into the sprint. 4 of them were technical work, and they took 15 of the 33 person-days: 45% of the sprint.

At the review on 29 August we had four small changes to show the customer. The operations director looked at the screen and asked: “Is this what came out for us in two weeks?” All of the technical work was necessary. But the ordering decision was not mine. I had used the stand-in role as a chance to move my own list to the front.

What is a PO for?

The Scrum Guide defines the PO with one accountability: maximizing the value of the product. In practice, this means the order of the backlog. The team pulls the next item from the order. The person who sets the order decides what the team will produce in the coming weeks.

Everything else turns around this decision. In Backlog Refinement, I wrote that filtering is the product side’s job. In Grooming, I wrote that the PO’s job is “why”, not “what”. Both are true, but both depend on one condition: the PO’s filtering and ordering decisions must really count. If someone else can overrule them, filtering and sharing context both lose their meaning.

The Scrum Guide says this clearly too: the PO is one person, not a committee. Anyone who wants to change the order tries to convince the PO. The organization must respect the PO’s decisions. That last sentence was missing in our company.

How it should work

1. Put the authority in writing

On 9 October, Gizem, the operations director, our general manager and I had a 45-minute meeting. First I showed the 30/45 number. Then I made one proposal. A one-paragraph email came out of the meeting:

The most important step in the whole process was the general manager replying “approved” to this email. The first challenge would go to him, and it did.

2. Remove the P1 label, use a rank number

A priority label hides competition: seven P1s all look equal. A rank number makes competition visible: 1 and 2 cannot be in the same place. We removed the labels and ranked the first 30 items of the backlog from 1 to 30. The rest stayed “unranked”. An unranked item does not enter the sprint.

By the end of November, the backlog went from 212 items to 87. Gizem closed 125 items with the note “we will not do this”. In the next three months, 4 of them came back. So only one in every 31 closed items was work that someone really wanted.

3. The shape of a no

I described saying no at the strategic level in the no list in Technical Strategy. That is a choice you write once a year. A PO’s no is daily: an answer to one request at a time. Gizem and I wrote four answer patterns for this:

The second row became the most used one. “Which one do you choose?” gives the decision back to the person who asked. Most of the time, that person withdraws their own request. In the first month, Gizem said “not now” or “no” to 23 requests. 2 of them came to the Thursday meeting as challenges. In one, the director changed the order. In the other, he stood with Gizem. The channel for challenges had changed. It was no longer the general manager’s door. It was a calendar invite.

PO and tech lead: where is the line?

My mistake as stand-in showed me that I had to draw this line. The tech lead knows best why technical work matters, but the tech lead does not own the order. The PO knows best where the value is, but the PO does not decide how the work is done. Confusion starts when one steps into the other’s area.

In practice, the second row gets the most discussion. We do not keep a separate list for technical work. It goes into the same order. My job is not to tell Gizem “this is important”. My job is to bring numbers: “Every story that touches the old reporting module needs 1.5 extra days of testing on average. We touched it 9 times in the last six sprints.” With that sentence, the reporting cleanup became item number 4. With “this is technical debt, we need to do it”, it had stayed unranked for months.

The stand-in rule also came from here: a stand-in follows the order and does not change it. The stand-in helps the team understand the next item. They postpone acceptance decisions or make simple decisions about the next items. New ordering decisions wait until the PO is back.

4. Change the PO’s calendar

Giving authority on paper was not the end. Gizem’s week also had to change. In early October we looked at her calendar together. About 20 hours a week went to writing tickets and collecting requests. She had no regular time for ordering, which was her real job. The order was decided on the evening before planning.

We changed two things. First, ticket details are no longer a document Gizem writes alone. She and the team write acceptance criteria together in grooming. Gizem brings the “why” and the limits. Second, Tuesday and Thursday mornings each got one “ordering hour”. She reads new requests, picks one of the four answer patterns and sends the answer the same day. Time spent on tickets went down to 8 hours a week. Most of the free time went to watching how the customer really does their work.

How it breaks

What changed?

The 4 stories between November and January were not really out of order either. They were items the director and Gizem moved up together in the Thursday meeting. The difference is this: they were now exceptions, and everyone knew whose decision they were.

Checklist

Conclusion

On the morning of 29 September, the seven P1s on Gizem’s screen were not one PO’s order. They were the orders of three different people. Gizem did not lack skill. What was missing was one paragraph saying that her decision counted.

Writing that paragraph took 45 minutes. The hard part was following it afterwards. I had to send the sales manager to Gizem and leave the order alone as a stand-in. I also had to defend technical work with numbers, not favours. The first person who failed to follow it was me.

Anyone can learn to write tickets. What makes a PO a PO is that her no counts.