Three things product leaders can do to evolve from endless discussions about changing priorities and # of shipped features, to building better products in less time that the entire team is proud of.
I tapped my finger on my iPhone. 2:27 PM. I had 3 minutes to get upstairs to the phone conference room to join my 2:30 call. On my way there, I passed a small round table of 3 Wall St. types — loud, finely manicured, formal business suits. As my foot hit the first stair I heard one of them say, “Creative people are different.”
I turned to look in their direction. One was shaking his head. Another had his arms folded, stone-faced. He reminded me of Sam the Eagle. The third had a look on his face that said, now what do we do?
About 45 minutes later I came back downstairs and they were still there, now huddled around a laptop looking at an Excel file.
I couldn’t help it. I introduced myself, told them I overheard their comment about creative people earlier, and asked them what they were working on.
They explained that they had been put in charge of creating a new technology platform for a major bank (I know my Wall Streeters) but were struggling to make much progress.
I said, “Let me guess, you guys were put in charge of the idea and you’re looking to the product team to come up with the solution. But they keep coming back to you, asking for more information. And now you’re stuck because you’ve taken it as far as you can because design isn’t your job .”
Two of them just stared at me.
Sam the Eagle morphed into De Niro, going from a look of, “Who the hell is this guy?” to “Nailed it.”
Turns out, if the next table over from these guys were a product manager, UX/UI designer, and developer, they would have the same exact story, in reverse. Something like… “De Niro keeps asking us to build the product. When we ask him why it’s important and what it should do, he tells us he’s not sure but he’ll know it when he sees it .”
I call this Product Ping Pong. But it gets worse.
If you were to sit and talk with your average product manager, their solution to this endless loop would be to take complete ownership of the product vision / roadmap / features / design / fill in the blank.
When product leaders say stuff like this, I picture someone trying to break down a cement wall with more cement.
These defensive tactics are going to make bad situations worse. The exchange between product (PMs, Heads of Product, Heads of UX) and business (stakeholders, senior leadership, sales & marketing) will look something like this, chronologically:
Oops.
This whole time, product and business have been going back and forth on scope, budget, and time for a set of features your users don’t care that much about.
When the product ultimately fails, business blames digital for not building what they asked for and taking too long — remember your roadmap that listed out features by date?
And digital blames business for changing priorities too much and not providing sufficient budget for research.
This happens every day inside companies, between agencies and companies, and even inside innovation labs (God help me). And it certainly happened for years inside New Haircut.
But if we could change things for the [much] better, you definitely can.
Related: How to Get Your Team Aligned Around a Big, Important Problem
Product “ownership”
The first thing to get straight is that, as the product team (PMs, designers, engineers), you own the process not the product.
Your CEO, VP of Marketing, Supply Chain Director, and CFO have enough to worry about. It’s fair for them to present you with ideas and rely on you to shepherd the process through solution development and launch.
To do so, and avoid product ping pong, I want you to think about leading the following 3 shifts.
1. Get clear on the problem
Everyone wants to talk about solutions. That’s the fun part. It’s when you begin to see results. It means you’ve figured things out.
But no one uses a solution to a problem they don’t have. That’s why you must start discussions with problems . Not only will this ensure your solutions are well-positioned, but everyone can contribute.
Problem definition is where you can have active discussion with your business stakeholders, while keeping them away from inventing solutions they’re not (yet) qualified to provide. They don’t want that pressure, and it provides no benefit. Double fail.
2. Define your north star
Once the team is aligned on an important, user-centered problem, you’ll want to help the team connect the user problem with the business opportunity.
As Sandhya Hegde summarizes, agreeing upon your product’s north star allows the entire team to:
This shared vision will not only align your multiple stakeholders and cross-functional team, but help to decentralize product decisions — only ideas that align with this vision will be considered, regardless of who suggests them.
As a result, everyone on the team will filter their ideas and suggestions based on measurable:
Note: Problem framing + north star metrics are something your team can complete in 1 day. Remember this speed as you continue reading.
3. Move quickly
In the world of product — speed, quality, and scope have historically been at odds with one another.
Which is the most important factor? For decades, the iron triangle told us that we could have 1 or 2 of them, not all 3.
But building digital products today is very different from the software we built even a few years ago, where speed was equated with cheap and low quality.
We’re also a lot busier today, with exponentially more distractions and shorter attention spans. And there are more and more competitors pushing out competing solutions — sometimes from entirely different industries.
Today, speed is the most important factor — especially since we now have the tools to decouple it from quality and scope.
Let’s start with scope.
By starting with problem framing and north star metrics, you shift the focus from the number of features shipped, to the value you create for your users and its subsequent impact on the business. The tighter the scope, the easier it is for your users to realize the product’s value. In other words, less is more.
Related: Knowledge Management Powers Digital Innovation
Next, quality.
Again, let’s filter quality through the lens of providing user value that generates business impact. When we do this, we realize that quality has very little to do with how perfectly designed a solution is or how many features it ships with.
The most efficient, effective way to figure out which solutions are giving value and producing the right business results, is to get them in the user’s hands early and often and ask for feedback — a perfect use case for design sprints .
To summarize, by starting with an important problem and aligning the team around ways your product will solve it (quality), you narrow your focus (scope), allowing everyone to move much faster.
Problems + measured impact + speed = better products
It takes a multidisciplinary team to build a successful product. The typical human thing to do is start by discussing solutions. This inevitably leads to power struggles, lost time, and poorly built products.
Instead, by focusing the discussion on important problems, defining north star metrics that align and excite the team, and using frameworks like design sprints to bring speed to the process, you can create better, user-centered products in less time.
Yes, there’s a small upfront investment of time. But the payoff is that product ownership means becomes decentralized. This means PMs can own the process while everyone owns the product. And as a result, trust and collaboration boon, allowing teams to move faster and more efficiently.