Product Taste Can Take Years to Build. Product Style You Can Test on Tuesday.

While we are busy coaching our clients’ product management teams, we run into the individual contributor who is working on a mature product.

Let’s imagine for a moment that this individual has a week filled with refinement sessions, user stories, and stakeholder sync meetings (let’s sprinkle in some production support efforts as well).

While all this is happening, leadership reminds the team to “Be more strategic.”

Your week is refinement, user stories, a stakeholder sync, and a production ticket someone escalated on Monday.

Leadership keeps saying “be more strategic.”

You’re not wrong to wonder how you can do that when the role seems so tactical, but it is in these calendared moments where you already have everything you need to practice being strategic. The existing meetings are the lab where you can test!

Here is the thing, the chances of you fixing your full agile process within the quarter are low. Also, let’s be honest, you’re not always going to get handed a greenfield build (a brand new idea that hasn’t been done before that you get to craft from idea to production so you can really build it right this time).

Right now, the work is user stories, delivering, executing on what’s already been decided. Fine.

You can still test things within your approach, your artifacts, the narrative, how you start the meeting, how you structure the agenda.

You can still innovate and iterate beyond just your product. You can focus on your process, your style, your product mindset.

Test your mindset by crafting your style, through testing

Your product mindset is how you think: whether you start from the problem or the solution, whether you see a ticket or an outcome, whether pushback reads as a marching order or an opportunity to get curious, just another dot to collect (ABCD so you can ABCD, if you know you know).

You can’t see a mindset directly. What you can see is your style, which is how that mindset shows up in the work. The way you write a user story, and whether you have a habit of including given/when/then or always providing the risks and assumptions section (proper user story hygiene).

Your mindset shows up in how you sequence a narrative. It shows up in how you start the refinement meeting to base the conversation in user outcomes and expectations. Now we get this very observable mindset on display, or Product Style, which means it’s testable, and testing it is the fastest way to build the mindset underneath it.

Product taste is judgment about what’s good: what’s worth building, what the quality bar is, when to say no.

Taste is real and it matters, but it takes years to build (months with Product Protégé :) ).

It mostly shows up in the decisions you make, and you rarely get a clean read on whether a given call was right.

Product style is how you work: the repeatable way you run a meeting, frame a problem, or structure a story.

Style shows up every week, in the meetings you’re already in, with people who react in real time. You can even practice a new approach by running a “test.” Change your style on Tuesday and get feedback by Thursday on whether it landed. Build the style deliberately and the mindset follows. Taste comes later, on top of both.

So test the way you write user stories and see if refinement goes smoother. How many stories are you actually getting through in a session, and does that change when you write them differently? Test a new way of using AI in your workflow.

Be proactively curious about this. Run the test, watch what happens, keep what works. It takes some effort, but it’s how you figure out how to work smarter instead of harder, and everything you need for it is already on your calendar.

Product gives you more chances to build your mindset than almost any other role.

Most of us assume that because we work on a mature product, or spend half our week on production support, we don’t get that chance. Psst… you do!

Here are five tests to try this week.

1. Every Epic gets a pitch deck

The concept of a pitch deck can be a loaded one. Think of it as stating what the opportunity is, but starting with a problem statement and why it’s a problem, in a few slides or a single page, sitting above the Epic before any stories get written. If you can’t write the problem in five minutes, that’s the test telling you something. The stories underneath are going to be messy because the problem is still fuzzy.

Yes, even if you don’t have a new epic or feature spec to write, utilize one that you are currently working on, even if it’s already been refined.

Watch for: how many clarifying questions come up in refinement compared to last sprint, and whether your co-creators in engineering and design reference the problem when they push back on scope.

2. Add an outcome to your requirements

Take the user stories you’re already writing and add one line at the bottom that highlights what changes for the user, or the business, if this ships. I’m not asking for a KPI dashboard. Just one to a few sentences. “When this works, the support team stops getting the Monday morning duplicate-invoice tickets.”

Watch for: whether refinement moves faster because people can see the point, and whether anyone on the team starts asking “does this story actually get us that outcome?” That question is gold, especially if it comes from your co-creators who are as close, if not closer, to the product than you are! It means they’re thinking above the ticket, and thinking of the ticket as an asset, not just a piece of work.

3. Start the narrative with the strategic pillar

Next time you’re presenting work, open with the strategic pillar it sits under and why that guardrail matters. Then name the trade-offs and risks the guardrail creates for this specific piece of work. The goal is to invite your stakeholders into a curiosity conversation and to see if anyone has an idea that keeps us inside the guardrails of the strategy. This is important: you are not asking for a decision, simply giving people a frame to think inside, which in itself is a way to influence how they decipher the context of the problem at hand.

Watch for: whether the ideas that come back are on-strategy or scattered. Scattered means the pillar didn’t land. Focused means you just turned a status update into a working session without adding a meeting.

4. Job to be done before story refinement

Before you open the backlog in refinement, spend the first few minutes on the job the user is trying to get done. What are they doing right before they hit this feature, and what are they trying to accomplish after? What would their demographic typically be thinking of, or what environment are they in when trying to get the job done? Then go into the stories.

Watch for: how the conversation changes. Does the team catch a missing edge case because they were picturing the user instead of the acceptance criteria? Does someone suggest a simpler version of the story? Count how many stories you get through and compare it to a session where you skipped this.

5. Tell the human outcome in a stakeholder meeting

Pick one stakeholder meeting this week and practice telling the story of the work in layers.

The human outcome, thinking about who’s better off and how. The first-order outcome, like what changes right away when it ships. The second-order outcome, or even a lagging indicator, what that makes possible next quarter. And what we hope to learn either way. This is a great chance to practice product storytelling with real stakes, and it does two things at once. It strengthens your relationship with that stakeholder, and it sharpens your presentation skills in a room where the feedback is immediate.

Watch for: what the stakeholder responds to. Did they lean in at the human outcome or the second-order one? Did they connect it to something on their side you didn’t know about? That reaction tells you how to tell the story next time.

Why this matters

None of these require a new product, a new process, or anyone’s permission.

Run one test, watch closely, keep what works, try the next one. Your style changes first. Your mindset changes because of it. The taste shows up later, and you’ll have earned it. We need to continuously iterate not only our product, but our product style.

If you want to go deeper, our clients have access to the Protégé Library, where each of these is covered in video walkthroughs along with the templates, playbooks, and guides behind them, like the Pitch Deck Playbook, the Product Narrative Guide, the Stakeholder Management and Influence Guide, and Product Protégé’s Product Empowerment Pyramide, which is the framework for connecting the stories at the bottom to the vision at the top. But you don’t need any of that to start. You need one test and a week.

Until next time!

Jason