Drew Barontini

Product Builder

Issue #38
7m read

Product Mindset

For the second time in my career, I’ve felt the shift from service work to product work.

The first time was while working for a consultancy that created a startup. While part of the company worked on billable client projects, part of the company built features for a software product that taught people how to code online.

I still remember the first feature I worked on.

The memorable part wasn’t the feature itself, but how I received the requirements for the feature. I rolled over to a senior engineer’s desk, he handed me a sticky note with a list of requirements, and provided a two-minute explanation of what we needed.

That was it.

There was no discovery meeting, no user stories, and no direction other than that single sticky note. Instead of being handed a map, I only had a compass to make decisions while uncovering the work. But that’s the real truth about work: it’s discovered, not imagined.

The best skills to develop are the ones that help you adapt in real time. While I like to plan, I’m under no illusion that the planning will affect the outcome more than the work itself. Planning helps prepare, not predict.

In a services world where you work for clients, you breathe planning—discovery meetings, kick-offs, and alignment over contracts rule the day. Then, when the work begins and constantly changes, it turns into a game of managing expectations. You start with a map (their map), and work with the client as you navigate your way through it. But at the end of the day, you’re simply helping meet expectations. The final decisions rest with them, not you. Trust matters—and your expertise important—but the signed document underscoring the relationship always lurks in the shadows.

In the product world, this is inverted. The focus is on rapid execution—working directly with your users to deliver valuable solutions to their problems. If you don’t, they leave. The only thing keeping them using your product is by solving their problems. To do so, you need to deeply understand and empathize with them. You need to have a finely tuned product sense to make the right decisions. You need to think like a scientist and diligently test your solutions.

I’m watching this shift happen again in an entirely new company. It’s a new environment, but the underlying tensions are the same. That tension requires a change in mindset, moving from a Services Mindset to a Product Mindset.

That shift starts with one thing: curiosity.

Curiosity about the problem. Curiosity about the person. Curiosity about why one solution feels better than another.

The Heart

In the Services Mindset, the client often acts as the proxy for people using the product. They’ve done the translation work of problems into solutions, and now you take the scope of work and deliver it.

But here’s the thing:

You can’t create great solutions if you don’t understand or care about the problem, or the people experiencing it.

It starts with *empathy—*truly understanding the humans experiencing the pain you’re solving.

This is what I call The Heart.

The words “users” and “customers” are sterile, hiding the rich tapestry of the human experience—the nuances you uncover when you look past the data point on a screen.

To truly know the people using your product is to know all their rich context. It’s not just the data or the person as they use the product. It’s everything outside of that. Understanding the context is how you make great decisions.

The Product Mindset stems from this understanding. More than that, it comes from the care placed on knowing the real people. That knowledge, that care, delivers real impact.

To grow The Heart:

The Compass

In a Services Mindset, problems are often translated from stakeholders (the client and users) verbatim. This is what they said they wanted, and here’s what we built for them. But people often prescribe the right solutions to the wrong problems. They may think this solution will solve their problem, but you better trust they know how to articulate their problem.

The Product Mindset requires intuition, a natural sense for discerning quality, and for knowing how and why something is good.

This is The Compass.

When I received the sticky note, the decisions were mine to make. I had to determine how to approach the work, what tasks were needed, and how to answer the inevitable unknowns.

With the rise and evolution of AI, intuition is more critical than ever before.

While AI is exceptional at producing outputs with rapid precision, it requires taste to review its outputs and refine them. Intuition is the primary mechanism of critical thinking, which is the foundational skill everyone should cultivate to succeed in this new world.

Developing a Product Mindset requires translating problems articulated by people, placing them in context, and converting them into real solutions. Intuition is the way.

To refine The Compass:

The Lab

In the Services Mindset, work is prescribed in advance—or so we like to believe. I’ve sat through weeks of collaborative scoping in overly detailed spreadsheets just to watch the work unfold completely different than originally expected. It’s all guesswork until you do the work. And the only way to learn is by doing.

When working with clients, it’s difficult to build trust in an environment ripe with unknowns. This is why RFPs, scopes of work, and elaborate spreadsheets are so prevalent.

But a Product Mindset requires testing, feedback, and iteration to achieve the right outcomes. Iteration is the connective tissue between speed and quality.

This is The Lab.

A Product Mindset is an Experimental Mindset (Issue #15), driven by a relentless curiosity to continually refine the fidelity of solutions.

Once you understand the problem deeply (The Heart), and have a sense for the direction to go (The Compass), you can design low-risk tests to capture feedback iteratively (The Lab).

When I began work on the sticky-note feature, I intentionally engineered tight feedback loops. I may have done this unknowingly at the time, but my intuition steered me. I made small changes, demoed the work, and captured feedback. Do this enough and you have a high-fidelity solution in the end. And if you do this directly with people who use your product, even better.

Before we released our online coding courses in the startup I mentioned earlier, we held live betas with real people. We’d cater food and walk around while they tested our course and provided real-time feedback. This method hit on all three pillars of the Product Mindset:

  1. We used The Heart as we watched real people encounter issues.
  2. We used The Compass to mentally triage what to change and how.
  3. We used The Lab (the betas) to capture feedback in real time.

To design The Lab:

Curiosity

A Product Mindset has one clear thread tying together all these parts: curiosity.

Curiosity drives you to ask real people questions about their life and worldview (the context).

Curiosity drives you to understand what makes something work and why.

Curiosity drives you to test ideas in low-risk environments to capture feedback and improve.

Curiosity is a force for good in every facet of life, even within a Services Mindset. But curiosity can also be limited by the contract, the client, or your own innate interest in learning more.

Curiosity can be deferred.

But not with a Product Mindset.

In order to solve real problems effectively, curiosity is the fuel, the engine, and the machinery necessary to grow The Heart, refine The Compass, and cultivate The Lab.

The right mindset is everything.

Clarity Codex Value Creation

Enjoying this issue? Sign up to get weekly insights in your inbox: