What nearly five years in procurement taught me about product requirements

I started my career in procurement and supply in 2018, as an apprentice. I worked at Manserv, Autometal, CATA and PKG Brasil before moving into technology in 2023. Since 2024 I have been a Product Owner at NVGO.

When I tell people this, they're usually surprised, as if these were unrelated worlds. But the core job is the same: someone has a need, describes it as best they can, and my role is to turn it into something that can be delivered without surprises.

These are the procurement lessons I use most today.

1. The request is not the need

A purchase requisition says what someone thinks they need, not the problem they want to solve. Reviewing requisitions, I learned to ask "what will it be used for?" before "what's the spec?". The answer often changed the item, the quantity or the deadline.

Product is the same. When a client asks for a button, a screen or a report, the question that matters is what for. That's why the most important part of a user story isn't "I want", it's "so that".

2. Ambiguous specs are expensive, and the bill comes later

In procurement, a poorly described requirement becomes the wrong item arriving weeks later, with missed deadlines, returns and rework. The mistake is cheap to avoid in the spec and expensive to fix at delivery.

In software, the equivalent is the feature that gets through development and is rejected at acceptance. Acceptance criteria are my version of a procurement technical spec: what must be true for the delivery to be accepted.

3. Every team thinks its priority is the most urgent

At CATA, I was the focal point between three sites, Camaçari, Mata de São João and Rondonópolis, for warehouse supply. Each site had its own urgencies, and all of them were legitimate. The job was to align demands and priorities without anyone feeling ignored.

Prioritizing a backlog with several stakeholders is exactly that. You can't serve everyone at once, so prioritization needs clear, visible criteria, not whoever asks the loudest.

4. Negotiation means balancing time, cost and quality

At PKG Brasil, I turned technical and quality requirements from other teams into specifications and negotiated with suppliers to meet them. Every negotiation had the same triangle: you can be faster, cheaper or better, but rarely all three.

Today I negotiate scope with clients and with the development team. Same triangle. The difference is that in product the trade-off has to be documented, so everyone knows what was given up and why.

5. Idle stock is waste too, and a backlog is stock

At Autometal, I managed the stock of non-production items (MRO). Excess stock feels like safety, but it's tied-up money, items that age and space taken.

A backlog works the same way. A huge list of stories written far in advance looks like planning, but many of them go stale before they're built. I prefer to keep detailed only what is close to development.

What the transition added

Procurement gave me the foundation in requirements, negotiation and stakeholders. Moving into technology, with web development, databases, infrastructure and agile methods, gave me the other half: understanding how the solution is built, so I can talk to the technical team as a peer.