The Product Mindset: Your Secret Weapon is Value

Written by Jason Scherschligt

On March 18, 2021

This is the third in our series of posts on The Product Mindset. See the first post in the series here: The Product Mindset.

As we’ve explored throughout this series, a surefire way for companies and teams to improve their value to their customers and align their own priorities, mission, and working cadences is to cultivate a product mindset.

This is the set of attitudes, beliefs, and behaviors that is concerned with building your business by building great products in response to the needs and desires of your customers or other users. A product mindset prioritizes outcomes, learning, understanding of users, and total system health. It’s an approach that pairs neatly with agile development models.

My SDG colleagues and I have had the pleasure and responsibility of working with teams and customers across industries and contexts. One observation I’ve made is that working teams at the ground level are generally willing to try new methods and approaches, like a product mindset.

But even the most willing and progressive team may be fighting hidden forces. These forces can hinder good product practices for even the most collaborative and productive product team. In effect, the team is paddling against a current, and it may not even know it.

The hidden, internal forces

It looks like this: teams of engineers, product managers, and designers might be excited about product-led, customer-centered, learning-driven approaches. They are happily collaborating to shape a compelling vision, break that into its key themes, align discovery and development work to those themes, and build a measurement framework that connects their daily work to their business performance. They’re excited to pursue value and satisfy their users.

And yet, someone on the team, maybe a scrum master or a mid-level product manager, will utter sentences like: “uh, no, I don’t think we can prioritize that valuable thing, we are committed to this other thing instead” or “we’ll never get that approved ahead of this.” It’s as if something is keeping them from working in the productive, customer-driven, agile way that they want to work.

In my experience, more often than not, the problem they’re running into is at the uppermost levels of approval and investment within their own organization.

To understand this, consider the way many companies govern the work of their technology teams. Usually, there are executive systems that control which technology projects are even started. These processes often happen at annual planning and budgeting levels, on relatively long (quarters to years) cycles. They look like an estimating, budgeting, prioritization, and approval exercise, all designed to ensure the right work gets funded. Requirements, estimates, and rationale are made into a business case, complete with costs, usually by a sponsoring executive. And then a leadership team decides which costs are worth incurring. The decisions are based on estimated return on investment (ROI), and on which sponsor makes the most compelling case.

If the work is approved, the product team is then on the hook to deliver the thing it promised during this funding and approval cycle. But some people on the team may not even realize this origin story, and the obligations this system puts on the product team.

When working with executive sponsors who might be gathering information for planning & funding processes, don’t focus on the things you’ll make. Instead, focus the conversation on value you’ll produce.

Change the conversation to value

To be clear: no one running these budgeting and planning processes wants to hamper a team’s ability to deliver value. Usually, these systems involve astute leaders, often at the helm of the organization, who are charged with ensuring the overall success of the company. I have no doubt that they want to make good choices. But they may have backgrounds and motivations that emphasize certainty over a product-driven, learning-driven attitude. Such leaders can be instrumental in helping a product team succeed, but they also need to manage a whole host of executive concerns, like investors, sales performance, regulatory affairs, PR, competitive threats, which aren’t necessarily amenable to your product mindset.

And that’s OK. As a product leader, you’ll do well to recognize this dynamic, and to navigate it with maturity, clarity, and communication.

Our best suggestion: when working with executive sponsors who might be gathering information for these planning & funding processes, don’t focus on the things you’ll make. Instead, focus the conversation on value you’ll produce. Here are some specific techniques.

Involve leaders in developing a well-articulated product vision and value proposition. Share your vision early. In fact, ask your leaders to help. Many executive leaders are quite skilled at writing vision statements and articulating value propositions, and their vision will be instrumental in the success of the product. Then use their vision to shape the deeper work of the product team. By doing so, it’ll be easier to explain your choices and recommendations upward, since the leaders already have the context of the value proposition.
Design and track metrics tied to your vision’s themes. Ask executives: what customer behavior or metric would make you feel good about our technology products? Then, connect your product work to those metrics. Don’t fixate on “building a portal”; prioritize “improved customer engagement,” for example. The portal might be just one way to do this. By doing this, you’ll move beyond questions about feature delivery to conversations about the value of those features.
Reinforce your product-driven approach. Explain how you’ll drive those metrics through relentless discovery of functionality and experience. Reframe their desire for certainty about deliverables with a focus on uncovering what’s meaningful to customers and the business. In such a dynamic, the teams — not the executives — are then responsible for producing value through functionality and for reporting back results. Explain that effective teams might run multiple experiments, shut down things that don’t appear promising, accelerate things that do.
Celebrate small successes. In some organizations, becoming product-led may take years of work and change. Don’t get discouraged if all you’re able to do during this cycle is, for example, get the IT delivery manager to build time for discovery into the project plan. That’s progress!
Commit to clear communication. Above all, promise your leaders that you’ll regularly report on the results you’ve achieved, in the language of the metrics you’ve prioritized and the value proposition you’ve agreed to. Then, keep that promise.

One last thing — and this might be a bit dangerous. Even if your company’s annual planning cycles seem committed to prioritizing and approving certain projects, with specific deliverables, remember that these projects usually aren’t what your senior leaders really want. They want the outcomes represented by those projects: revenue, growth, satisfied customers, competitive differentiation. They want value.

So even if they have approved and funded a project or a feature — say, “build a new portal site for managers” — what they really want is the outcome, the value that the feature expressed. If you can translate those items to value, you may be able to get away with delivering something else, like, in this example, creating a new manager view for an existing site.

With good communication, and perhaps a bit of charm (one of the most important soft skills of a product leader), you’ll satisfy your leadership, start paddling with the current — and, more importantly, delight your users and build a great product.

Photo credits:

Kayak paddling upstream photo by Tim Foster on Unsplash
Opening door photo by Jan Tinneberg on Unsplash