It’s easy to say “no”, it’s more valuable to boldly lead a company towards a new way of doing things.
Over the past few months I’ve had many conversations with our product teams about the frustration that arises when someone comes running to the product team with a new “great idea” that needs to be built “as soon as possible” because it is an “urgent priority” for “the business”. Product teams become annoyed or irritated because they just want stakeholders to understand the true value we bring and our way of doing things. And, truth be told — as a product organization, we want stakeholders to respect the flow and understand the value of a truly agile discovery and delivery process.
We’re at a point in the history of big corporations and established institutions where stakeholders desperately need strong product teams to lead them towards a new future. This doesn’t mean that product teams bow to every stakeholder ask — instead, it means that companies need teams to boldly lead a new way of thinking.
My challenge to tech product teams inside of corporations: Instead of a “no” or a [begrudging] “yes” team, be a “Yes, AND” team. In an ideal world, product teams would be fully agile in discovery and development. If you’re read the book Inspired by Marty Cagan, you’ll probably pick up on the same conclusion I did … the current state of most product teams is that they are agile in development but not truly agile in discovery within a broader company culture. The tension often comes when product teams aim to introduce the process inside of an established organization.
The below image is an attempt to dimensionalize this framework … on the spectrum you’ll see Tell vs. Show, Yes vs. No. The first two quadrants are where I think we play pretty often due to the time and resource pressures we’re under.
1. We either push back with a hard “no”, and tell a stakeholder why we can’t deliver on a thing. The problem with this approach is that it’s confusing to the stakeholder. “But wait, you guys are the experts … you’re agile … you’re supposed to build this thing for me because I need it”. When instead, they don’t realize that our reason for saying no is from a fundamental, philosophical standpoint … rather than a “we just don’t want to do this work” standpoint.
2. What usually ends up happening is that a few weeks later the team [is forced to say] yes, begrudgingly and deliver on the ask. The problem with this approach is lack of product team empowerment. In this model, the team is there to implement the list of asks. They’re mercenaries*. They stakeholder is also slightly pissed at this point … which makes for a complex working relationship over time and can erode trust and confidence on both sides of the equation.
So, … what is the solve?!
3. Becoming a yes, AND team. In Tier 3, the product team delivers on the asks and then some. Deliver what the stakeholder asks for PLUS the product team’s ideas to solve the problem, seeded with data. Within a yes, AND framework, teams deliver on the ask and also show from expertise and knowledge how an idea can come to life in ways beyond the ask. Deliver what is asked for AND deliver one, two, three ideas on where else the idea can come to life within the product or the consumer journey. Take all the ideas through a research cycle. Validate ideas with data. This starts to give teams an area of freedom, exploration and over time, create a virtuous cycle of asks that truly transform the business. It also create a historical precedent for teams to point back to over delivery AND education for stakeholders, AND shown them a new way of thinking, instead of telling them no or simply saying yes. We become missionaries in this realm … As Marty Cagan stated — Missionaries are true believers in the vision and are committed to solving problems for their customers.
Companies need teams of missionaries, and I believe that by becoming a yes, AND group of problem solvers, you can can start to seed the change to help teams move towards that realm.
Source link https://uxdesign.cc/on-becoming-a-yes-product-team-d691f91e534d?source=rss—-138adf9c44c—4