Product and Engineering: The Same Table, Not the Other Side

From the field: the 3 March demo

The work was a screen for buying and selling investment funds. Our brokerage’s mobile app had stocks and derivatives, but no funds. Customers bought their funds at other firms. The product manager had presented this gap to management as the main goal of the quarter. The strongest slide in that presentation was the recurring purchase order: “buy 2,000 TL of this fund on the 5th of every month”. That was the feature that would keep customers in the app.

I had not seen that presentation. All I had were seven stories in Jira. On the evening of Wednesday 4 February the team and I made a rough estimate: 6 weeks. It did not fit into 4. The next morning, instead of going to the product manager, I made a plan in my own head: I would remove the most expensive part, and we would finish the rest with some overtime. The most expensive part, at 2 weeks, was the recurring purchase order. The scheduler, failed payments, low balance, cancellation — each one a separate problem.

I removed it. I did not tell anyone, because I thought this was an engineering decision: “I know what we can deliver.” The team worked two weekends. On the morning of 3 March the screen went live: fund list, buy, sell, audit log. From a technical point of view it was a clean release.

At 11:00 there was a demo for management. The first question from the deputy general manager was: “Where is the recurring purchase?” The product manager did not know the answer. They found out in front of the screen, in front of everyone. After the meeting they sent me one sentence: “You needed to tell me this four weeks ago, not in the demo.”

They were right. But I also thought I was right: the date had been given without asking me. We had both made the same mistake, just from different directions. They had answered my question: “when will it be done?” I had answered theirs: “what do we give up?”

Who answers what

Two days after the demo the product manager and I sat down for an hour. We wrote on one page who answers which question. Once it was written, it was surprisingly simple. The hard part was not writing it. The hard part was following it under pressure.

The first two rows are the split everyone knows: what and why, how and how long. The real fights happen in the last three rows, because there the two answers depend on each other. The date depends on the estimate. The scope depends on the date. The estimate depends on the scope. One person cannot answer all three. Whoever tries will decide in the wrong place, like I did.

In the grooming post I wrote that product’s job is the “why”, not the “what”. The split here is not about one meeting. It is about two roles. Ceremonies happen every two weeks. These questions are asked every day.

Who drops the scope?

This was my mistake, so I will spend the most time here. Cutting scope looks like a technical decision, because the trigger is technical: the work does not fit. But choosing which part to cut is a decision about value. Product knows what each feature means to the customer, what was promised to whom, and which sentence sales uses. I did not know any of that.

After the demo we put the same seven parts into a table. Together we played out what would have happened if we had opened this table on 4 February:

part                         value (product)  cost (eng.)
-------------------------------------------------------------
fund list + filter           must have        1   week
buy order                    must have        1   week
sell order                   must have        0.5 week
audit log                    FLOOR            0.5 week
recurring purchase order     very high        2   weeks
fund comparison chart        medium           0.5 week
return calculator            low              0.5 week
-------------------------------------------------------------
total                                         6   weeks

what I cut       : recurring purchase   (most expensive, -2 weeks)
what product cuts: chart + calculator   (least valuable, -1 week)
product's choice : 5 weeks left, move the date 1 week: 10 March
                   no overtime, main feature included

I cut the 2-week part, squeezed the rest into four weeks and finished it with two weekends of overtime. The product manager would have cut two parts worth one week in total and moved the date by one week. And they would have told management right then, on 4 February: “recurring purchase is in, the date is 10 March”. We would have discussed a calendar change instead of a demo.

The rule that came out of this: engineering names the price, product does the shopping. Engineering says “this part is 2 weeks, because of these risks”. Product says “then I take this one and leave that one”. If engineering does the shopping itself, it fills the basket without knowing what the customer wants.

The two answers to “when will it be done?”

The other half of the incident was the date. Where had the product manager found 3 March? When I asked later, the answer was simple. In December, someone from the team had said in the corridor: “The fund screen? That is a month of work.” That sentence was not an estimate. It was the shadow of an estimate. But it went into the management presentation as a date.

So now we give two separate answers to “when will it be done”, and two different people give them:

An estimate is a measurement. A commitment is a promise. Whoever makes the promise lives with the result, so product gives the outside date. But a date given without seeing the estimate is not a promise. It is a hope. I described the same idea at the sprint level in the sprint planning post (“commitment, not estimation”). Here the scale is not a sprint, it is a quarter.

The trade-off conversation

Date, scope and quality: one is fixed, one is chosen, and the third is the result. Quality is already fixed, so the conversation always comes down to one question: is the date fixed, or the scope? Product answers that. Engineering then says what the other one will be.

Two sentences break this conversation. Both come from engineering: “no” and “we will do it”. The first one ends the conversation. The second one hides the cost. Instead we use one sentence pattern: “It fits, but in return this comes out” or “It does not fit; if we take this out, it fits.”

In practice this is 30 minutes a week. Monday at 10:00, the product manager and me. The agenda is always the same three items: has the estimate range changed, has anything come into or gone out of the scope, and is any date we gave outside at risk. The scope table lives on one page that we can both edit. When someone changes a row, they add the date and one sentence next to it.

The shared goal: an outcome, not output

Before the incident we looked at two different numbers. I looked at the number of stories delivered. The product manager looked at the dates on the roadmap. Both are output. And each one could go up at the other’s cost: I could close stories by cutting scope, and they could make the roadmap look full by giving dates.

Now we both look at one number: active recurring purchase orders on the fund screen each month. That number depends on the part I cut, so cutting it is now a loss for me too. I wrote about the traps of shared metrics in the engineering metrics post. Here there is one rule: a number that both sides can move, and that neither side can escape.

What to track

What did not work for me

• Giving the estimate as a single number. On an earlier project I had said “6 weeks”. The product manager heard it as a date and passed it to management that way. A single number always turns into the most optimistic case in the other person’s head.
• A hidden buffer. For a while I quietly added 20% to every estimate. When the product manager noticed, they started taking 20% off all my estimates. In a relationship where both sides correct each other’s numbers, nobody’s numbers are real. The buffer is now a separate row in the table, with its own name.
• Keeping product out of the “how” conversation. I thought technical details were not their business. They were: someone who does not know why the recurring purchase takes 2 weeks cannot weigh its cost. Now I add a three-line “why this long” note next to every estimate.
• Talking only through Jira. Comments, labels, field changes. None of that is a conversation. In the four weeks before 3 March, the product manager and I did not sit at the same table even once. The whole relationship lived in the ticket history.

Checklist

Conclusion

At the 3 March demo, two people were wrong and both thought they were right. The product manager had given the date without asking me. I had cut the scope without asking them. The date was engineering’s question. The scope was product’s. We had each answered the other’s question.

The recurring purchase order was planned as separate work. The estimate was between 2 and 3 weeks, and the product manager told management 3 weeks. It went live on 24 March, in two and a half weeks. Nobody asked anything in the demo, because everything worth asking had already been discussed in the Monday meetings. When I wrote this, only two weeks had passed. My evidence is one project. But in that project, the number of surprises was zero.

When product and engineering sit on opposite sides, each protects its own question and answers the other’s. When they sit side by side at the same table, they both look at the same sheet.