Choice Always Exists

Depending on your organization, and the placement of your product team within it, product leaders can sometimes feel that they lack autonomy of choice. Marty Cagan terms teams that just receive delivery assignments and must churn output as feature teams. These feature teams are beholden to business stakeholders, and often receive prioritized lists of features or projects that must be accomplished. They lack much autonomy in their work and timelines. This is of course in contrast to an empowered product team that is focused on the outcome of solving user problems in ways that create positive impact for the business. 

However, even the most mature product team in a user-centered organization can find itself with a directive, or even just a strong ask, from an influential stakeholder. In these cases, the product team will often say something like, "we don't have any choice". In their minds, there is no way out of delivering what they were asked, and so there is no choice to be made. The request for this feature came from the general manager of that vertical, or everyone knows this is the CEO's pet peeve that must be fixed, or the sales team has already promised it to a high-performing customer. Those are all reasons to complete the work as requested, but they do not preclude having a choice.

There is always a choice to be made, but what needs to be consciously factored in are the consequences. Instead of assuming there isn't a choice, instead think through the scenarios. The most obvious is completing the request as assigned. But what happens if the request is NOT completed? Does someone get removed from the team or worse, lose their job? Or is someone annoyed and good will is lost and a relationship is damaged? What if a different solution was presented - an MVP of the feature, or an A/B test, or a different delivery timeline? Who is affected and to what extent? What are the known consequences and potentially unknown consequences? Will your leadership support you in your decision? 

Often when we say, "we don't have any choice", we mean, "I'm unwilling to accept the assumed consequences". But when we take a further look, mapping out those consequences, perhaps we can think differently. Or at a minimum, we can complete the task consciously understanding the trade-offs. 

---

STAND-UP EXERCISE

With your team, think back to an instance where the team felt they didn't have a choice in completing a project or delivering a feature. Do a retro of this instance. What were the consequences that were avoided at the time? Were there alternate paths with different consequences / outcomes that were not considered? With the benefit of hind sight, would the team have acted differently in this scenario? 

Remember: as with all retrospectives, these conversations should be blameless - this isn't about pointing fingers at people in the past. Focus on the problem and events, not people or personalities. 

Book Club: Impact First Product Teams by Matt LeMay

Impact First Product Teams by Matt LeMay shows you the keys to impact right on the cover:
Define Success.
Do Work That Matters.
Be Indispensable.

Matt’s entire thesis is how it doesn’t matter how well you are “doing product” - you need to be consistently showing business impact for your team to feel stable and valued in your organization. He states, “Simply put, choosing to be an impact first product team means recognizing that our responsibility is ultimately to contribute towards a successful business.” Most organizations are set up to perpetuate low-impact work, but we can break the cycle at the place where the work is getting done - in the product team.

While this can be seen as a bit more of a philosophy book in that it is about changing a mind-set, he provides clear action items on how to move toward thinking about impact first, aligning to company goals, how to estimate potential impact when prioritizing work, and how to work towards cross-team collaboration.

Some key takeaways that would be good to discuss as a product team:

• One of the most powerful questions comes from Chapter 1: “If you were in charge of the company, would you fully fund this team?”

• Has our team adopted ways of working from another company, like the Spotify model for example, or have we purpose-built our own ways of working that help us achieve our own goals in our own specific context?

• What does success mean to our particular business? Thinking about viability in terms of does this create impact for our business model, how do we define viability for our product? How can we keep our team goal as close as possible (one mathematical step or one “why” statement) to our company goals?

• What is the most impact we could reasonably expect from the work we have in progress? Is that enough impact for us to continue the work? If we aren’t sure, are there signals we can look for or faster experiments we can run to better understand if we are going to be successful?

• How can we better frame up urgent requests from our stakeholders as a jumping off point to understand what might be complex or changing circumstances? How can we structure the discussion to learn about shared goals and create alignment?

Matt provides resources for product teams, which also make for good discussion materials. One of the best ways to begin the journey to being an impact-first product team is simply to begin having these conversations.

---

I was fortunate enough to meet Matt at an executive roundtable for product leaders last month here in Chicago, and then won a copy of his book for an up-voted question I posed. In the passing weeks, I’ve much dog-eared the text as I think through and discuss these topics with other product folks. The book is a quick read, but could have very lasting consequences for product teams within any organization. Highly recommend.

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?