Product Vision

A product vision aligns the product team to the change you want to see - driving strategy, priorities, and execution. For teams where the product is the transactional item or service, this is likely an obvious one-to-one with the business or corporate vision. However, for those product teams working on internal tools or enabling platforms or secondary offerings, a specific product vision will need to be crafted.

A product vision statement should be:

1. Centered on the problem to be solved

2. Descriptive of a tangible end state you can visualize

3. Meaningful to you, and to the people you intend to impact

In Product Leadership, the authors describe, “A vision isn’t a poster on the office wall or a weekly newsletter to the team. It’s a concept of what the future will look like with the energy to back it up and something that should be regularly communicated to the team.”

A good vision statement should answer four questions, according to Radhika Dutt in Radical Product Thinking.
WHO - whose worlds are you trying to change? Who has the problem?
WHAT - what does their world look like today? What are they trying to accomplish and how are they doing that?
WHY - why is the status quo unacceptable? Why is it imperative to solve the problem? (Make sure that it is.) What are the consequences of not solving it?
WHEN - when will you know that you have succeeded?
HOW - how will you bring about the change? (This creates the actionable part of the vision.)

Those questions can be thought of in terms of a fill-in-the-blank vision template.

While a vision statement can include more, this template is a great place to start. Then, with a vision in place, you can support it with a set of guidelines to filter decisions/prioritization, and be confident your product team is aligned on what success is and how to get there.

---

STAND-UP EXERCISE

Work with your product team to brainstorm answers to the 5 questions above (who/what/why/when/how). Use consensus to translate those answers into the vision template. How does this statement compare to previous/earlier vision statements that might exist? Does this statement need to evolve to encompass more needs or users? How can you make it most useful to the team as whole?
Once complete, place this statement within your artifacts - add it to your roadmap, put it at the top of your Confluence, create a Teams background. Make sure it is often seen and referenced.

Technical Debt

It is a rare a product that does not carry some technical debt. Trade-offs and compromises are made - to meet deadlines or work within other constraints. Some of those decisions have consequences that do not age well over time, and that is technical debt - the implied cost of additional work caused by choosing an easy or limited solution (instead of the more desired approach that would take longer / cost more / use additional resources.) It is similar to financial debt - you take it on because the value of having the item now is more important than saving up to purchase it when you can afford it. Eventually the debt must be paid down, and similar to financial debt, sometimes that comes with interest owed.

Not all technical debt is bad. Product teams must balance the business goals and outcomes with technical solutioning and implementation decisions. The key is to take on the debt responsibly. Part of doing that is identifying when you are making a decision that is not ideal. Thinking through - or at least acknowledging - a future fix at the time it is implemented can be valuable.

Additionally, categorizing your debt can be a helpful exercise, to better understand the trade-offs on your product and to help in the debt remediation phases.

Some categories of technical debt are:

Secure Coding - issues or vulnerabilities discovered within the code, through audits such as OWASP Top 10
Accessibility - issues addressing digital accessibility, at a minimum meeting compliance with WCAG 2.1 level AA or AAA
Code Efficiency - Maintainability, testability, performance, and scalability of code
Architectural Integrity - Best practices for code, security, data, and architecture
Business Risk - Documentation, audit controls, SOX compliance, etc.
Up-to-Date Technology - Ensuring the latest versions of IDEs, frameworks, libraries, servers, databases
Automated Testing - Increase coverage, resolution, alignment, and optimization of automated testing framework

The best approaches to technical debt focus on thoughtful decisions about when to take on the debt, and careful tracking and planned remediation.

---

STAND-UP EXERCISE

As a product team, identify the categories of technical debt that your product does/could encounter. Is there a way to track these categories on your tickets / incidents? Discuss how the team could systematically remediate technical debt. Is it best to focus a percentage of every sprint’s points toward one or more of these categories? Is it better to use one or two sprints a quarter to completely dedicate toward eliminating debt? Is there a way to coordinate with other teams, if you have reliance or dependencies with them? Create a plan for your team, and revisit it - as well as your tracked metrics - on a regular basis as your team and product evolves.

The Drama Triangle vs. The Empowerment Dynamic

Within product teams, between product teams, and with stakeholders, there can be conflict. In the 1960’s, an American psychiatrist named Stephen Karpman mapped out three roles that people play in conflict. He created a model that illustrates destructive interaction, and called it the Drama Triangle. (Karpman loved the dramatic arts, and found these archetypes to be roles we play, or masks we put on, in conflict scenarios.)

The Hero

The Hero (also called the Rescuer) wants to save the day. But the action is often a quick fix that makes the problem go away, not a long-term solution. The Hero is motivated by wanting to be right. And this can result in acceptance and praise from others, but their heroics are limited in effectiveness and don’t address the underlying issues. Often a Hero might jump into the middle before knowing all of the facts, so a true solution wouldn’t be possible.

The Villain

The Villain (also called the Persecutor) wants to place blame. They want to figure out who is at fault and throw them under the bus. Occasionally they blame themselves, but more often they point the finger at someone else. Many times the blame goes to an undefined “they”, in the form of blaming “management” or “engineering”. When you are speaking with a Villian, it can often feel like gossip.

The Victim

The Victim is driven by fear. They pursue personal safety and security above all else. Victims can list many reasons why they are the real victim of a person, circumstance, or condition. “I was never trained on that”, “There’s not enough time”, “Nobody is helping”, “I’m not allowed to talk to customers”, etc. The Victim operates from a place of powerlessness and helplessness. Victims will seek help, creating a Hero to save the day, who often perpetuates the Victim's negative feelings and leaves the situation broadly unchanged.

Note: In this model, Victims are acting the part, they are not actually powerless/being abused. But accusing someone else of “playing the victim” and gaslighting them is a classic Villain move!

In 2009, a way to distrupt these interactions was published. David Emerald created The Empowerment Dynamic (TED*) which stops the reactive nature of the Drama Triangle and empowers new roles.

VICTIM > CREATOR

Victims stop thinking “poor me” and become Creators. Victims are reactive - focusing on scarcity, considering themselves powerless, and not seeing choices. Creators, however, claim their own power in a situation and focus on possibilities. Creators take responsibility and look for what they can do to alter a situation.

VILLIAN > CHALLENGER

The Villain stops blaming and becomes the Challenger. Where the Villain points finger about the present situation, Challengers bring new perspectives to others through positive pressure in a way that creates a breakthrough. The Challenger inspires and motivates, a kind of teacher who points the Creators opportunities for growth.

HERO > CoACH

The Hero stops trying to save the day and becomes the Coach. The Coach is a support role, helping others create the lives they want and evoking transformation. Heroes take over and micromanage. Coaches facilitate and encourage. A Coach leaves the power with the Creator, not taking it for themselves.

Shifting to the empowered roles instead of the sabotaging ones has to be a conscious move, but one that can be implemented within a team that has good trust and psychological safety. Conflict and tension will always be present to some degree, but we can better manage it and our reactions to it.

---

STAND-UP EXERCISE

Present The Drama Triangle and Empowerment Dynamic to your team. Use this 3 minute video to help illustrate. Talk to your team about what roles they most often play, and in which scenarios. One person might always choose the same role, or they may play different roles based on the people or circumstances involved. How can your team support each other when they see the drama roles surfacing?

Signaling Decisiveness

As a product leader, you’re often navigating a space where formal authority doesn’t exist. Your influence is built through relationships and the respect you earn from your team, stakeholders, and peers. In this dynamic, how you carry yourself—what Sylvia Ann Hewlett describes as "gravitas" in Executive Presence 2.0—plays a significant role in how others perceive and respond to you.

Hewlett breaks gravitas into four essential components:

1. Projecting intellectual horsepower.

2. Displaying confidence and credibility.

3. Signaling decisiveness.

4. Maintaining grace under fire.

I’ve explored the topic of projecting intellect and expertise before, but we’ll focus on a less-discussed aspect of executive presence: decisiveness.

Decisiveness in Product Management

As product managers, we make decisions daily—about priorities, feature trade-offs, user experiments, and future research. These decisions shape the product’s trajectory and, in turn, the success of the business. To confidently communicate these choices to stakeholders, we must have self-assurance not only in our judgment but also in our ability to make those decisions quickly and effectively.

We’ve all experienced the pitfalls of indecision. When we delay making a choice, the situation often forces a default outcome upon us—typically not the one we’d have chosen. Avoiding this requires mastering the ability to make swift, informed decisions.

Gaining Confidence Through Information

One key to fast, confident decision-making is having access to trusted information that you can quickly digest and apply. Everyone processes information differently, so finding your ideal method for gathering insights is critical.

Some ways to gather the necessary information to confidently decide your product’s next steps:

1. Qualitative User Feedback – Mine your existing user feedback or lean on your UX team’s insights. Understanding the real-life experiences of your users is vital to making informed choices.

2. Internal or Quantitative Data – Build a strong intuition around user behavior by analyzing the numbers. Metrics often reveal truths that anecdotes can’t.

3. Experience with the Product – Use your own product like a customer would. Understanding the user experience firsthand gives you an invaluable perspective.

4. External Market Trends – Keep an eye on competitors, industry shifts, and broader consumer patterns. This will help you predict what’s coming and position your product accordingly.

5. Financial Modeling – Work with your finance or business partners to evaluate how various decisions might impact the bottom line. Long-term success often hinges on understanding the financial ripple effects of today’s choices.

6. Prototyping – Create mockups, sandboxes, or prototypes. Experimenting with different solutions can help you see how they perform in practice and make more informed choices.

While it’s impossible to cover all of these areas for every decision, pulling information from a few can lead to a decision that’s "good enough" to move forward.

The Role of Intuition and Circumstance

Of course, decision-making isn’t purely an intellectual exercise. As product managers, we juggle competing priorities, unpredictable constraints, stakeholder politics, and shifting business goals. Sometimes, our choices are influenced by factors beyond the data—like gut feeling or external pressures.

Even so, when you’re grounded in reliable information, you can navigate those complex variables with greater confidence. Decisiveness becomes less about bold assertions and more about informed, thoughtful action.

Leading with Influence, Not Authority

At the core of product management is the need to lead through influence. You don’t have the luxury of positional power; your authority comes from the expertise and trust you cultivate. Decisiveness is a key part of that influence. When your team and stakeholders see you making informed, timely decisions, it builds confidence in your leadership.

---

STAND-UP EXERCISE

Discuss with your team how they typically make decisions, or how they might feel forced to make decisions. Of the methods discussed above, which ones are applicable to their learning style, the product, and the business. What other ways might they collect information to make better informed and quicker decisions?

Bonus: Learn about the framework of one-way door and two-way door decisions. Jeff Bezos explains the philosophy in this video.

Book Club: Transformed by Marty Cagan

At MillerKnoll I lead the Product Guild, a group of digital product folk from across the organization that meets at least twice a month in service of driving forward the adoption of a product-focused mindset across the enterprise. We support each other, developing and unifying our core competencies within product, and it is also an opportunity for me to harmonize everyone on prioritization, intake, roadmapping and best practices. This summer we did our first book club. While it might feel like a large guild is a better setting for this conversation, I encourage you to do this within your individual product teams - the discussion was illuminating.

Transformed: Moving to the Product Operating Model is the third in the series by Marty Cagan, but if you haven’t read any of them, you should make it your starting point. All of these books make for great professional book club fodder, as Cagan’s writing is very conversational and easy to consume, but also very structured. He tells you what he's going to tell you, tells you (including case studies) and then summarizes the key points. It is a perfect set-up for a group discussion.

Transformed teaches the reader how companies can move from their current approaches to the product operating model. It teaches the principles of the model, convinces you that it is possible, and inspires you to get there as an organization. This book particularly was written to appeal to those outside of Silicon Valley.

Transformation dimensions

• How you build - small releases, analytics, monitoring (product delivery)

• How you solve problems - assign problems to teams, let them find solutions (empowered product teams)

• How you decide which problems to solve - product leaders need a vision and insight-based strategy (product leadership)

Competencies

• Product Manager

• Product Designer

• Technical Lead

• Product Leaders

Product Model Concepts

• Product Teams - empowered with problems to solve, outcomes over output, sense of ownership, collaboration

• Product Vision - the power of an inspiring product vision, insights, transparency, placing bets

• Product Discovery - assessing product risks, embracing rapid experimentation, testing ideas responsibly

• Product Delivery - small, frequent, uncoupled releases, high-integrity commitments, instrumentation, monitoring, deployment infrastructure, managing technical debt

• Product Culture - principles over process, trust over control, innovation over predictability, learning over failure

---

DISCUSSION QUESTIONS

1. Where is our team and organization falling short in the three dimensions of the product operating model? Where is the most friction between this team and the organization?

2. In which areas have we become too rigid to the process and it is no longer serving us? How we should go back to our product operating model principles instead?

3. Which are the least relevant principles to us as an organization?

4. Do you think of the leaders of design and engineering as product leaders? More or less than the product management leader? Why or why not?

5. Have you previously used the technique of a high-integrity commitment?  Is this a possibility for the next time a stakeholder asks for a date?

6. Have you needed to address objections to the product model in the past? Was that successful? Do you think the scripts provided by the book will be helpful in future conversations?

7. What can you do in your role (individual contributor, manager, leader, etc) to forward the product operating model and transformation in our organization?

For more discussion questions, visit the SVPG site.

---

As part of the Chicago product community, I was thrilled to be able to hear Marty Cagan speak last week at an event sponsored by Mind The Product. It was great to hear his candid and relatable answers to the crowd, and glean encouragement on how we can all make advancements, even as we work toward the large transformations. And I was able to fan-girl a little and get a selfie with Marty.