Product mindset: purpose, user, and value.

If I had 30 seconds to know whether an initiative is on the right track, I would ask this question:

What changes, for whom does it change, and how will we know it has changed?

When this isn’t clear, what usually happens is that we start with energy, the backlog grows, we deliver things… and a few weeks later someone asks: “okay, and what was this for?” And it’s usually not a problem of effort, but a problem of focus.

For me, a product mindset is not about roles, ceremonies, or tools. It’s about putting the focus on three things before we start building: what problem we want to solve, for whom, and what value we expect to generate.

The most common mistake is starting with the “what.” Early conversations revolve around what needs to be built, expected deliverables, timelines, who does it, and where we track it. These are valid questions. The problem is that if we start there, we risk organizing ourselves around executing something that might not have been the most important thing.

That’s why, before going into execution, it’s worth grounding purpose, user, and value with these questions:

• Why are we doing this? What problem are we trying to solve?
• Who is the real user?
• What improvement do we expect to see and how will we notice it?

If this isn’t clear, jumping into the backlog too early won’t help. This often happens with initiatives that already come framed like this:

• “We need a dashboard.”
• “We need to automate this process.”
• “We want a new screen.”

The risk here is accepting the solution without fully understanding the need. It happens, for example, with requests like: “automate request approvals.” Up to that point, what we have is a solution. The useful conversation starts when you ask: “okay, but for what purpose?” And then the real problem emerges: reducing response times and avoiding errors. From there, you can be more precise:

• User: the operations team managing the requests and the end customer affected by delays.
• Expected value: moving from 5 days to 24 hours and reducing rework.
• Decision: before automating, it might be better to remove redundant validations, clarify criteria, and define exceptions.

The underlying need hasn’t changed. What changes is the quality of the decision.

Product is the combination of purpose, user, and value

When we talk about product, for me there are three elements that cannot be missing: purpose, user, and value. If one of these is missing, it’s easy to fall into a dangerous dynamic where we work a lot but with unclear impact.

• Without a user, value becomes abstract: we don’t know for whom we are improving something or what change we want to create. This also applies when the user is internal. Whether they are in Operations, Technology, Risk, or Finance doesn’t change the core idea: we still need to define who they are, what friction they face, and what improvement would truly be valuable to them.
• Without value, the user becomes an empty description. In this post we won’t go deep into what value means, but when I talk about value, I don’t mean just business value. It can appear at different levels:
  • User value: less friction, more clarity, fewer waits, fewer errors.
  • Business value: more adoption, lower cost, less risk, better conversion.
  • Delivery system value: higher quality, more stability, less rework, fewer artificial urgencies.
• Without purpose, everything sounds reasonable but is hard to prioritize. There’s a useful distinction here that connects with Simon Sinek’s Golden Circle: it’s not the same to talk about the why as it is to talk about the what for. The why refers to the purpose of the initiative. The what for translates that purpose into impact—the change we want to create.

What matters is that something changes in an observable way. If nothing visible changes, we are probably not creating value—we’re just doing things.

A good question to ground this is: What real improvement will the user experience if this works?

How to bring this into daily work

1. Start with the problem and value, not the deliverable.

Before talking about solutions, be clear about what pain you want to solve, for whom, and what improvement you expect. Tools like a well-focused Inception help align purpose, user, value, and how we will know we’re on track.

For this starting point, it helps a lot to write down something as simple as:

• Our objective: we are here to...
• The current problem: today, what happens is...
• Who it affects: this mainly affects...
• What we expect: if everything goes well, it should change...
• How we’ll know: we’ll notice it because we’ll see...

Don’t see it as bureaucracy. See it as a way to align better and prevent the backlog from becoming just a task list.

2. Connect strategy, focus, and backlog.

If an initiative is not connected to a real priority, the backlog ends up full of work—but not necessarily value. That’s why it’s important to connect strategy, prioritization, and roadmap.

3. Translate intention into real tracking.

If you say you’re aiming for impact, you need to review it. It helps to define objectives properly and complement them with observable outcomes, without confusing activity with impact. For this, you can use OKRs, paying attention to their anti-patterns.

Conclusion

Working with a product mindset is about making better decisions from the start. The next time you kick off an initiative, I would pause for a minute on these three questions:

• What specific value do we want to create?
• For whom, exactly?
• How will we know we are achieving it?

Because value doesn’t appear at the end. It’s decided at the beginning and reviewed along the way.

Your backlog shouldn’t prove that you’re working. It should prove that you’re changing something valuable for someone. I’ll read you in the comments! 👇