Podcast
Podcast
July 9, 2024

Greater than the sum of its parts: On finding product alignment

Catalyst
Podcast
Share:
##
min. read

Much like how products are better when multiple disciplines work together in sync, Catalyst is even better the more experts we have to share their expertise. On today’s episode, Clinton is joined by industry experts Ash Howell, Scott Campagna, and Jamie Bernard to discuss why enterprises often struggle to align their product, design, and engineering efforts and how to create harmony in the product development process.

Why do large enterprises struggle with synergy?

The product development process at large enterprises is often disjointed and lacks collaboration. In most cases, this boils down to money, power, and ego. Whoever is funding the project tends to focus most heavily on their side of things and leave others out, while others may cling too hard out of fear of losing control. The project may fail – and others before it certainly did – causing egos to get bruised and preventing some from seeking help or better ways of doing things next time around.

Close gaps through proper alignment

Goals are often nebulous and cascade down through organizations, leading to confusion and lack of specificity in decision making. The person calling most of the shots is often somewhat disconnected from the actual work and has a misaligned view of operations, while at the actual boots-on-the-ground level, those doing the work don't understand the goals. When gaps persist, the product suffers the consequences. Aligning goals and objectives through clear communication can generate more value.

Don’t go it alone

If market fit has been based on false assumptions and misguided biases, you’re not going to generate anything that's worth putting into the market. Overcoming this begins at the ideation stage. Teaming up engineering, design, and product strategy with consumer and business insights from the beginning helps ensure that your ideas are actually valuable. It is also essential to prototype and validate early in the process, a step many enterprises overlook. Decisions made without a hypothesis or empirical data can lead to poor performance.

To turn adversaries into advocates, let the data do the talking

When rigidity sets in, meeting people where they are may not always work. If this is the case, it’s best to lead with the facts and show them what they’re missing. Provide any available data and statistics around development costs, timelines, and maintenance costs upfront to help inform decision making.

It’s hard for even the most rigid of people to argue with value. When faced with stubborn opposition, it’s best to anchor on a specific business outcome. You may disagree on the approach, but it’s not about being right; it’s about the end result.

Make some magic

When teams are in lockstep, product development is a partnership that innovates and provides value in a way that feels like magic. The journey isn't painful, but it’s not necessarily painless. You're navigating challenges and evolving the product in new ways, but doing it together. At the end, you’ll have a team of people who trusted one another, respected each other’s ability to do the work, and held each other accountable along the way. But more importantly, you’ll have a better product because of it.

As always, don’t forget to subscribe to Catalyst wherever you get your podcasts. We release a new episode every Tuesday, jam-packed with expert advice and actionable insights for creating digital experiences that move millions.

sources
Podcast
July 9, 2024

Greater than the sum of its parts: On finding product alignment

Much like how products are better when multiple disciplines work together in sync, Catalyst is even better the more experts we have to share their expertise. On today’s episode, Clinton is joined by industry experts Ash Howell, Scott Campagna, and Jamie Bernard to discuss why enterprises often struggle to align their product, design, and engineering efforts and how to create harmony in the product development process.

Why do large enterprises struggle with synergy?

The product development process at large enterprises is often disjointed and lacks collaboration. In most cases, this boils down to money, power, and ego. Whoever is funding the project tends to focus most heavily on their side of things and leave others out, while others may cling too hard out of fear of losing control. The project may fail – and others before it certainly did – causing egos to get bruised and preventing some from seeking help or better ways of doing things next time around.

Close gaps through proper alignment

Goals are often nebulous and cascade down through organizations, leading to confusion and lack of specificity in decision making. The person calling most of the shots is often somewhat disconnected from the actual work and has a misaligned view of operations, while at the actual boots-on-the-ground level, those doing the work don't understand the goals. When gaps persist, the product suffers the consequences. Aligning goals and objectives through clear communication can generate more value.

Don’t go it alone

If market fit has been based on false assumptions and misguided biases, you’re not going to generate anything that's worth putting into the market. Overcoming this begins at the ideation stage. Teaming up engineering, design, and product strategy with consumer and business insights from the beginning helps ensure that your ideas are actually valuable. It is also essential to prototype and validate early in the process, a step many enterprises overlook. Decisions made without a hypothesis or empirical data can lead to poor performance.

To turn adversaries into advocates, let the data do the talking

When rigidity sets in, meeting people where they are may not always work. If this is the case, it’s best to lead with the facts and show them what they’re missing. Provide any available data and statistics around development costs, timelines, and maintenance costs upfront to help inform decision making.

It’s hard for even the most rigid of people to argue with value. When faced with stubborn opposition, it’s best to anchor on a specific business outcome. You may disagree on the approach, but it’s not about being right; it’s about the end result.

Make some magic

When teams are in lockstep, product development is a partnership that innovates and provides value in a way that feels like magic. The journey isn't painful, but it’s not necessarily painless. You're navigating challenges and evolving the product in new ways, but doing it together. At the end, you’ll have a team of people who trusted one another, respected each other’s ability to do the work, and held each other accountable along the way. But more importantly, you’ll have a better product because of it.

As always, don’t forget to subscribe to Catalyst wherever you get your podcasts. We release a new episode every Tuesday, jam-packed with expert advice and actionable insights for creating digital experiences that move millions.

sources

Podcast
July 9, 2024
Ep.
441

Greater than the sum of its parts: On finding product alignment

0:00
42:43
https://rss.art19.com/episodes/b1b66d54-b2de-4ef7-9391-b55ccb9d0b6d.mp3

Much like how products are better when multiple disciplines work together in sync, Catalyst is even better the more experts we have to share their expertise. On today’s episode, Clinton is joined by industry experts Ash Howell, Scott Campagna, and Jamie Bernard to discuss why enterprises often struggle to align their product, design, and engineering efforts and how to create harmony in the product development process.

Why do large enterprises struggle with synergy?

The product development process at large enterprises is often disjointed and lacks collaboration. In most cases, this boils down to money, power, and ego. Whoever is funding the project tends to focus most heavily on their side of things and leave others out, while others may cling too hard out of fear of losing control. The project may fail – and others before it certainly did – causing egos to get bruised and preventing some from seeking help or better ways of doing things next time around.

Close gaps through proper alignment

Goals are often nebulous and cascade down through organizations, leading to confusion and lack of specificity in decision making. The person calling most of the shots is often somewhat disconnected from the actual work and has a misaligned view of operations, while at the actual boots-on-the-ground level, those doing the work don't understand the goals. When gaps persist, the product suffers the consequences. Aligning goals and objectives through clear communication can generate more value.

Don’t go it alone

If market fit has been based on false assumptions and misguided biases, you’re not going to generate anything that's worth putting into the market. Overcoming this begins at the ideation stage. Teaming up engineering, design, and product strategy with consumer and business insights from the beginning helps ensure that your ideas are actually valuable. It is also essential to prototype and validate early in the process, a step many enterprises overlook. Decisions made without a hypothesis or empirical data can lead to poor performance.

To turn adversaries into advocates, let the data do the talking

When rigidity sets in, meeting people where they are may not always work. If this is the case, it’s best to lead with the facts and show them what they’re missing. Provide any available data and statistics around development costs, timelines, and maintenance costs upfront to help inform decision making.

It’s hard for even the most rigid of people to argue with value. When faced with stubborn opposition, it’s best to anchor on a specific business outcome. You may disagree on the approach, but it’s not about being right; it’s about the end result.

Make some magic

When teams are in lockstep, product development is a partnership that innovates and provides value in a way that feels like magic. The journey isn't painful, but it’s not necessarily painless. You're navigating challenges and evolving the product in new ways, but doing it together. At the end, you’ll have a team of people who trusted one another, respected each other’s ability to do the work, and held each other accountable along the way. But more importantly, you’ll have a better product because of it.

As always, don’t forget to subscribe to Catalyst wherever you get your podcasts. We release a new episode every Tuesday, jam-packed with expert advice and actionable insights for creating digital experiences that move millions.

sources

Episode hosts & guests

Clinton Bonner

VP, Marketing
Launch by NTT DATA
View profile

Ash Howell

Senior Design Director, Visual and Emerging Design Lead
Launch by NTT DATA
View profile

Scott Campagna

Emerging and Immersive Technology Sr. Director
Launch by NTT DATA
View profile

Jamie Bernard

Sr. Product Director
Launch by NTT DATA
View profile

Episode transcript

Jamie Bernard: Do we have the rights to Pink Floyd's "Money"?

(LAUGHTER) 

Jamie: Because that's... 'Cause we should... That's what we should lead in with. 

Clinton Bonner: I feel like we could just like, (singing the riff from Pink Floyd's "Money") Doom, doom doom doom doom doom doom doom doom doom doom doom doom... 

Jamie: Yes, with the (making drum sounds) ch-ch-ch.  

Clinton: Maybe we could get there, right? 

(CATALYST INTRO MUSIC) 

Clinton: Welcome to Catalyst, the Launch by NTT Data podcast. Catalyst is an ongoing discussion for digital leaders dissatisfied with the status quo, and yet optimistic about what's possible through smart technology and great people. Folks, let me tell you why I like Slack. Well, there's actually lots of reasons I like Slack, and this time it's because often I'll see some really interesting internal discussions. And, you know, they're going on in our channels, and I'll say, that sounds like an interesting podcast topic. And that's how we got to today. There was a recent discussion about a prospect who shall remain nameless, and the crux of it was something like, quote, I can't believe they were that far down the roadmap and then decided to pull their product team in to the discussion. Basically, pulling the product team in way, way too late. As you can tell, I'm paraphrasing here. However, today we're bringing together three distinct experts, including a product strategist, an engineering lead, and a design lead so they can share with you the lessons of going it alone, how to avoid this at the enterprise, and the intentionality of healthy tension. Let's welcome back three voices you might have already heard on Catalyst: Ash Howell, Launch by NTT Data's Senior Director, Visual and Emerging Design; Jamie Bernard, our Senior Director in Product and Business Strategy at Launch, and Scott Campagna, Senior Director, Mobile and Emerging Technologies from the Launch team. Alright, team, how is everybody doing today? 

Scott Campagna: I feel like I'm feeling very skeptical about the way that people currently do business, and want to talk a lot about how I'd rather they did business. 

(LAUGHTER) 

Scott: That sounds like what I'm feeling.  

Clinton: Well, we're all hearing Scott there first, and that's what we're going to talk about today primarily, is that, hey, there's ways that they all can do a bit better. Jamie, how are you doing today? 

Jamie: I'm raging against the machine. No, I'm doing very well, thank you. 

Clinton: (Laughing) I love it. Ash, how are you doing? 

Ash Howell: Doing good. I'm gonna try to not make this a cathartic release of emotions, and productive. 

Clinton: Maybe some glass case of emotion, we'll find out, but it's all good. So, alright. So, for me, when I saw that discussion happening in Slack, I asked myself, well, why does this happen, really, so often at large enterprises? We're talking multi-billion dollar organizations. And... Like, why are they not together about what products, services or even new features they're bringing to market? So, first and foremost, can we answer this in one sentence? Why does this happen so frickin' often at large enterprises, where they are not orchestrating things together when it comes to understanding and then delivering the products they're actually trying to bring to market? 

Jamie: It's money. Who's writing the check? That's where it comes from, usually, if it comes from the business side. They're funding the project. They tend to overindex on that side and leave folks out. That's my answer is money. 

Clinton: Okay, so we got money from Jamie. Scott. Maybe that's the first answer on the board if this Family Feud, I don't know. 

(LAUGHTER) 

Clinton: But is there another reason that things just don't... They're not orchestrated well, typically? 

Scott: In the spirit of friendly tension, I'll add other ideas to the mix beyond just the money. It's also about control and power, right? It's about who really feels like they are the ones who are in control and power wants to keep and retain that control and power, and doesn't want to cede that to other people. It's a very human nature type of a thing, where it's like, the moment that I give up a little bit of power, I feel like everything's going to get taken away from me, and then I can't do anything that I feel like is important. And there's that tension that's there that I think sometimes people butt up against in a large corporate environment. 

Clinton: Mm. Alright. So, so far we've got money and power. And, uh... My 46 years on earth have taught me those things tend to go hand in hand, not just at the enterprise level, but all facets of life. Ash, is there another answer on the board or another... A nuance you'd like to add to the discussion? 

Jamie: I think, ego. There's like, the famous, like... It's a manipulated quote, but, "I have not failed, I've just found 10,000 ways that don't work." And... It's the... Part of innovation and product development is saying, okay, I failed and let me learn from it and move on. But often ego gets in the way of, like, recognizing that failure and doing something better down the road. 

Clinton: Now, things could fail at a large scale. A product never launches, it's completely misaligned with maybe the business strategy or value. Or, it could fail post-launch in a way that, like, hey, what you brought to market, nobody actually wanted. And so, Ash, going back to you, I know you've had some looks at different studies around features. What the heck happens all the way down to a feature level? And why, so often, are they... They're brought to market and literally it's crickets. Like, nobody wants to even use them. 

Ash: Starts all in ideation. And not those that hold the cha-ching, the money and power and ego, saying this is the tried and true path forward. You have to bring the right stakeholders to the table early and often. So, looking at all your different practices, i.e. engineering, design, product strategy, combined with consumer and business insights, to the ideation table to ensure that the ideas that you're trying to bring to market are actually valuable. And if market fit has been based on false assumptions and misguided biases, then there's... You're probably not going to generate anything that's worth putting in the product sphere market. 

Clinton: So, Jamie, anything you'd add there? You were saying earlier, hey, who's got the money is going to dictate how a certain product's projects goes forward, and can cause misalignment. Does it happen at micro levels too? Money's a pretty big one. So, does it happen at other levels, or does it just cascade from the original sin? 

Jamie: I think there's some level of confirmation bias and existential crisis that gets in the way. Scott really hit on something earlier in terms of, like, if I put this thing in play, does that automate me out of a job? Or, does that jeopardize something that I might have control over? Because I know it works, and when I implement this, it's no longer in my control. And therefore, how am I going to know it works? And I super care, because that's what my individual incentives are based on. So, I think it has to do with a lot of... When we have these ideas that we just know, because we've been here for 20 years, and we want to get them done because we just know that they're the right thing to do, I think that people forget that hypotheses need to be disprovable. That is a phrase that my mentor says all the time: what is your disprovable hypothesis? And I think more often than not it's, well, customers can't do X, we want to let them do X. And success is, now they can do x. Versus, they can do X, which is going to generate Y, which costs us Z. And then, you know, gets more to value. But people don't take it that far. They really focus on their need, their fear, their confirmation bias, and ultimately, what are they being incentivized to do? 

Clinton: And that almost sounds and feels like good storytelling versus bad storytelling, in a way, because there's some great South Park clips out there. You know, Matt and Trey. Talking about, you know, if you're writing a story and it's like, okay, this happened. And then this happened. And then this happened. He's like, then you have a really bad story. However, if you have a story that says this happened, and because of this, this next thing was enabled or unlocked, and because of that, you know, Cartman does this ridiculous thing, and because of that, et cetera et cetera. And they were saying, that's a way more effective way to share a story and craft a story, even in the absurdist comedy that is South Park. Jamie, the things you just said there sound to me like a lot when they're looking at it through a... The first prism you described was more like, we will do this and then this thing will happen. Versus that because, and now, and now we're able to. 

Ash: There's an important step in any, like, whether it's product or solution development, that I think so many businesses or BUs, whatever, stakeholders, may skip, is actually prototyping and putting something out in market to validate it early. Right? You gotta test your hypotheses, to Jamie's point, right? They skip that part. It's just like, let's get this out. Let's see if there's true value there. And if there's not, let it die. And so many times they just don't let it die. They keep going. They keep pushing towards... (Laughs) Their confirmation bias. 

Scott: And I think that dovetails into the absurdism of South Park relating to the absurdism of the corporate world, which is that, you know, we tend to just sort of make decisions and not necessarily have a hypothesis even involved in it, let alone a disprovable one. And sometimes it's just, hey, we just need to do this because someone else has a bee in their bonnet that we need to do X, and so we do a lot of work around X without talking about the value that we're trying to provide, and who we're trying to provide it for. So it's... It's trying to disconnect from the emotional, "I know what to do," and instead tap into the empirical, "here's data that shows what our customers need us to do." As a developer, I don't want to develop something that no one's ever going to touch or use, and then have to maintain it in production for ten years and have everybody tell me how bad it is because no one's using it. (Laughs) 

Ash: And by the way, here's the analytics on your lack of performance. And... 

Scott: Yeah. 

Ash: Tried to tell you. 

Jamie: I am currently reading The Signals Are Talking by Amy Webb. The chapter that I'm on right now is about trending, and is something really a trend?, and the importance of questioning your decisioning. Like, you know, taking the affirmative and the counter of why you're doing something. And so that just reminded me, Scott, while you're talking, is like, there's a trendiness factor that pushes some of this also. So like, it might... 

Ash: Mhm. 

Jamie: ...You know, if we take it outside of the person making the decision and, you know, hoping that they achieve their goals and that sort of thing. And none of this is malice, right? This is all the Hanlon's razor. This is, absence of malice is either ignorance or, you know, stupidity, or whatever, right? So, in my mind, you'll just get random requests, also, for the thing that somebody read about. Scott, I imagine you live in that hell on the daily. 

Scott: All the time.  

(LAUGHTER) 

Scott: One of my favorite examples I love using with this is that, back in my early days in the development world, right as Twitter released their first API, I was helping to write an app for a bank, and the bank was adamant that they needed to be on the cutting edge. The Twitter API was available. We need to put Twitter into our mobile banking app. But you can really quickly see where all of the negatives can come in there, because what are our options for success? What's going to happen when someone starts using Twitter within our banking app? They're either, one, going to praise our banking app. That's the best possible scenario. The next one is they're going to think that it's a help desk and start tweeting out their bank account information, or they're going to just roast us on Twitter. Those are our three options. The best option there is not worth the time and effort to go and deal with the other two options that are pretty bad. So you gotta think about all of the different pieces that you're actually going through, instead of just saying, hey, trendy new thing, let's pull it off the shelf and put it into whatever we're building. Because that's not the right way to operate. And we're seeing it today with Google search trying to include AI responses that are absolute garbage. 

Jamie: (Laughs) 

Clinton: Yes. 

Scott: It's like, you've gotta think about why we're doing things and how we can operationalize them in a way that works, as opposed to just sort of making a decision and hoping that everything works out in the end. 

Clinton: Yeah, I love that example. I think it's a great one. It is trend chasing, and very often you're misaligned there, and like you said, then, whoever's the loudest voice or the person with the purse can make a call that is fundamentally not aligned with actual value. So, talking about that crunchiness and that alignment, who owns that? Do we think this often comes from, if it's the loudest voice, is it the C-suite? Maybe the product owner has the bag so they have the money? But in your experience, where do you typically see the misalignment begin? Is it C-level? Is it right in that product level? Or is it more sometimes grassroots? 

Scott: I want to go first on this one. 

Clinton: (Laughs) 

Scott: Because then I want Jamie and Ash to yell at me and tell me that I'm wrong. So, I think that there's two levels. So the first level is with whoever holds the purse strings and is making decisions. That's usually someone disconnected from any of the actual work that's happening. That person has a misaligned view of how operations actually work and how they are going to go through everything. Absolutely. And then the second layer of this is misalignment at the actual hitting the ground, boots to the ground, doing the work level. Because those people don't understand the goals. And most of the time it's the translation of goals, from that person who's disconnected from the work to the people who are doing the work, is where all of the gaps come in. And if we align those two together instead, we start finding a lot more value. 

Jamie: I agree, to a certain extent, but I also think that "goals" is such a wildly nebulous thing that tends to get cascaded through the organization. We're going to spend $50 million on this wind strategy. Or, we're going to disrupt the market. And these kind of big rock, rah-rah, internal cascading things will go down into the org. And now you have VPs going, okay, I gotta decompose this to justify my existence as an organization, or a product or technology. And we have to figure out how to spend this money. Because there are more than just, like, personal financial implications in terms of your P and L, right? You have to be able to illustrate why you spent the money. You have to make some level of like, we're going to increase revenue or what have you. And I would argue that you should also measure it, but I don't think that happens very often. And what I see that does happen is the same level of nebula floating all the way down into, I am very biased on this, product tends to take the face shot. Because you get this, like, go solve for this thing and you're talking to the product team usually, if you're on the business side. Or you get, you know, some data that says, well, this isn't doing what we need it to do, or there's a technology thing that has to get solved for, and you have to go tell somebody no, in the nicest, not-lying way possible. You know, it tends to converge on the product person. Even though I think there's this lack of specificity, or at least quantifiable outcome and goal. And I don't think a lot of people know why they're doing it, even if the end is to get, you know, increased revenue. And it's so bad that I know of a major financial corporation that, they print money, I think, so fast that they don't realize how much is hemorrhaging out, that we are at the end of June, and I have colleagues who are still waiting on objectives for fiscal year 24 that started on January 1. And so, this results in an end of year scramble to go, oh my God, what did we do? And how can we actually back into our objectives so we don't get in trouble? And that's the cycle that so many people get into, because you have... It goes nebula, nebula, nebula, nebula, point, this thing we have to do. And you push it so, so far... 

Ash: Catch up.  

Jamie: ...Down that, yeah, you're playing catch up, and then you completely miss the tech debt that has to be dealt with. The design debt that has to be dealt with. You don't do user research at all. So, like, that's kind of where I, I would yes, and and and and and and, what Scott just said. 

Clinton: What's being described there is a bit of a vicious cycle, I know that's an overused term, but but it is what it is, that you're sitting there or team's sitting there in June, late June, and do not have objectives from Jan 1, when when this particular client's fiscal year began. So let's turn to the positive, or turn to, how do you fix this? And proactive real ways to make that better. Because it's, I think we all know, these are large enterprises, they tend to move more slowly than we want them to. And, to enact change, it's not a light switch. It's not, okay. Hey, that was a good idea. We're doing that tomorrow. How do we reverse it so that we get the right people at the table, sounds to me, way, way earlier, so that objectives can be understood at the level they need to be, you know, detailed at. How is that possible? What have you seen effective in your careers? Ash, any particular ways you would start to steer the boat differently? 

Jamie: Yeah, and I mean, I have a really, like, narrow view on this. Part of what you're asking can be everything from, like, organizationally, operationally, creating a monumental paradigm shift, to, on the product level, how do we sway this in the right direction? I mentioned that this is going to be really pragmatic, but... Like, even validating your ideas is impactful. And we have had the opportunity to do that with clients. We're working with one that was just focused on a technology. Like, we want to do XR for our field. It's like, well, why XR? Oh, let's talk to your people. Let's see if this is really actually what they want. Oh wait, they don't have the basic fundamental tools to do their job. They need something way more basic. They don't need XR tools. So, even putting back that data, funneling it back up top to show them the case, maybe, against what they're asking for is... I mean, it's our job as consultants in the product space to also inform them on the right path forward. But, yeah. Changing massive organizational think is not a small thing. But on the product level, there are methods to actually start effectuating awareness for creating value. 

Clinton: So Jamie, taking it to your purview, is that bad trickle down we just talked about... What are you trying to bring back to the top-level discussions, and how do you change that behavior? So over time, you don't end up in that same space, that same rut, because it can be... It will be repeated. Project, product, you know, over and over again. So, what do you have to change in order to actually make it better holistically? 

Jamie: Where I come in and play is, like, I would grab Ash and I would grab Scott and we would lock arms, and we would time travel to three months in the future. 

(LAUGHTER) 

Jamie: And, you know, obviously, like, in our brains, where it counts. And acknowledge that we have sunk cost that is in flight right now, that is probably going to get deployed. That is probably considered important by somebody. And we have to accept that noise as what it is. Or signal, if that's what it is. You look into the future because, number one, it turns the heat way down. And that creates the space for the should-we conversation. Should we continue? What are we seeing? What do we want to research today so that we can think about how we might look at what three months from now looks like? And it allows you time to get the disprovable hypotheses going. To do the market research. So many people avoid or miss the outside-in perspective, and that is where you get the halfway solutions. Because, listen: people who have been in domains for 20 years, they are smart people. They know their domain, they know their customer to a degree. But what they aren't is that they are not their customer. And so to that end, research has to get done and you have to create space for it. And so I would lop us off of the Borg, time travel us with a lens of three months into the future, or six months, depending on how fast or slow the train is, and just acknowledge that we have a certain amount of our budget that's sunk cost, and it is what it is, and you just move forward. This is so top of mind because my husband and I watched this show called Forged in Fire. They make knives and swords and stuff. Like, under a time crunch. And of course, I sit there knowing nothing about forging, very critical of how these people are doing their work, right? But like, part of these kinds of shows is that you could sit there and see them go, I have made a mistake. I have a limited amount of time in which to accomplish this very specific goal that I've been given. And because it's a tangible goal, and because I see the mistake that I've made, now I'm going to chuck this mistake in the trash and I'm going to start over. Every single time, without fail, that the people, the contestants on those types of shows acknowledge the sunk cost and chuck it, they always end up with better results than people who double down on the failure and go, well, I'm already in it. And so, to that end, you just acknowledge that you're spending money, so you don't freak out your organization. You come together with people who bring different perspectives, and you have some really hard, spicy conversations that, you know, you argue, but you come to really good stuff in those kinds of environments. Because the temperature's down and the pressure's low, but you can crank it up a little bit and have some healthy conversation. 

Clinton: So from a dev perspective, Scott, what would you add? 

Scott: Well, first of all, I'm going to steal that analogy. But I'm going to apply it to cooking shows because that's where my head goes more than to everything else. So, absolutely I'm going to steal that one. But, from the technology end, the part of this that sometimes is hard is that we want to work in really confined spaces in technology, right? We want to have specific parameters of things that we want to develop, and we want to have really clear results of everything that we want to do. But some of the time, that still relies on us as development folk to have good data that we can then give back to people like Jamie and Ash to help them make better decisions. Right? And so that's where my head comes into this, which is like, you know, we do things all the time with, like, code coverage and making sure that we have no errors and things like that, that we build into our process, but we don't build it back into the ideation process as much. Right? And so I know Jamie hit on this a little earlier, which is that, like, we need more statistics coming into this so that we can make good decisions. So we need to be there to help with, you know, like, what is going to be the development cost? Whether it's by dollar amount or by timeline, on how we're going to actually develop some of these solutions. Because that also can help make better decisions. What's the maintenance cost of this solution going forward, when we're talking through this stuff? Which is how we can come in earlier to say, hey, let's make smarter overall thought processes about what we're going to do next, as opposed to just thinking about things in a vacuum. Because when Ash or Jamie or I think of things in a vacuum, we stop thinking about the problems that the other people are going to experience. And that's really where problems come in. And it's so much easier to live in your own world, and not have to hear other people tell you about why something might go wrong. (Laughs) And it's a little bit more uncomfortable. But the thing that's tough about all of this, and Ash and Jamie, I want to know if you guys agree with me on this one, but, a part of this is making sure that you're building the right kind of team. Because, if you build a team where your leaders all are not willing to compromise, and they aren't willing to see each other's options and aren't willing to give up a little bit of skin in the game in order to do better, you're not going to be as successful. Because of the fact that you're always going to create tension that can't resolve, as opposed to creating tension that can resolve. 

Ash: It's like the side of the coin, of the solution coin, right? You have the right ideas, like what is it going to be? What's it going to do? Getting that right needs to be done, but like, also, how do we build it? Like, you see that so often. It might be everything from, they might not have the right process, might not have the right buy-in from the right stakeholders across the process. You might not have the right team to unite, it's... agreed. (Laughs) And I'm sure Jamie does too. 

Jamie: I do. I feel like it should be a really fun game of capture the flag, where I'm coming in going, I need, I want to quantify it! And I have my spreadsheets and my calculator going, you know, listen, if I can't get us into market share or share of wallet, or generating revenue or cutting costs, like, help me understand. And, you know, Ash, I would expect you to be like, yeah, but it looks like crap. So users aren't going to use it, even if it, like, does exactly what it says. And I would expect Scott to be like, yeah, that's super nice that you want to do that, but it's going to cost you, you know, a gazillion dollars. And oh, by the way, the environmental impact is horrible. So like, if I do that in a vacuum, I might come up with the most amazing business case ever, and design expertise and technical expertise can show why it's actually a horrible idea. So, I love being challenged and having a team of leaders. You know, and I play this role a lot. I am a challenger. I am an eight on the Enneagram. I will come in the room and I will be like, hm, where's the math? But it's not to be contrarian. It's to try to get to good. And I want people to do that to me. Because there's nothing more embarrassing than, like, not taking an expert's advice. Like, or even seeking it in the first place. Which is, you know, that's not the best feeling. 

Clinton: Scott, you said something earlier. You said, you know, living in your own world. So that could be the client. That could be, you know, the folks hired to do the work, the partner hired to do the work as well. And then, Jamie, when we talked about this prep, you had talked about the large difference of having a clear roadmap versus a plan. And that there's not too subtle differences to the things. Can you explain what you mean by that? 

Jamie: Yes. I use the literal map and directions analogy. Because, more often than not, when someone says they want a road map, they want a to-do list. These are the things we're going to build. This is the, you know, I'm predicting the future and telling you when they're going to be done, and how much it's going to cost. That is putting the cart before the horse, because the... That's just telling me, go down the street, turn right, go down the street again, turn left. But I don't know where I'm starting and I don't know where I'm going. I just know the steps that I'm taking. Right? Whereas, from a mapping standpoint, you have a visual view of, oh, I'm starting at my house. Okay. Now I know I'm going to the grocery store. Now these left-right directions are going to help me understand, as I'm going, that I'm getting closer to the destination. And so, to that end, your roadmap should be the outcomes that you can tangibly see, or actually measure, in the market or internally with your production lines or what have you. And not just, okay, we're going to check this box so that at the end of the year we can tell you how busy we were. That's a horrible waste of money. And frankly, it's a horrible waste of your team's talent, because I guarantee you that you have folks in your organization who have fantastic ideas and they have fantastic skills, and they don't want to be told, hey, go do this and check this box. So I could filibuster on and on. 

Clinton: (Laughs) 

Jamie: But I have found it egregiously done in design because, I just, I really get salty when design's not at the table, mostly because I'm really bad at it, and so I need somebody there to keep me checked. (Laughs) 

Ash: I love the marriage that design has with product and engineering, too. And, like, the true, like, symbiosis that comes together when we ideate solutions that consumers want, that are going to have the market fit, and they're actually feasible, and which should then funnel into your roadmap, right? Like, these should be all at the party, and it shouldn't be one siloed practice developing that. Because... Any time I've embarked on, like, a strategy, like, I'm going to be partnering with engineering. And, you know, product strategy to bring that to life. Because, you need to be looking at all facets. You need to look at the business, and you need to be looking at what's actually realistic, what can we achieve? And we need to look at what people are actually going to be using to make that valuable roadmap. 

Jamie: I was going to say, and if you are the recipient of RFP responses or RFI responses, and the only person that you're speaking with is a salesperson, demand practitioners talk to you. Demand it. Because, while the, you know, sales folks are usually former practitioners, I think that you can get so much more valuable insight into, you know, the skill sets you're buying and the perspectives you're buying, and the considerations up front. I just firmly believe that while you're making those decisions, please seek the perspective of a practitioner. 

Scott: I want to triple down on that, because there's so many times where you get an RFI or an RFP, and there are questions in there that, they seem very basic, right? But there's so much nuance that can go into it. And a lot of the time it's really easy, as a consultant, to go in and say, I have an answer, stamp. And then say that you know exactly what's going on. But it's so much more realistic and advantageous to you if you are dealing with someone who admits that they don't know all of the answers, but they do know how to figure them out. That's more important than actually knowing the answers. It's knowing how to figure out the answers and how to get to where you want to go, as opposed to already claiming that they know how to do it. Because, I would guess that a high percentage of the time, the people who say they already know how to get there are going to use one very isolated example that does not relate nearly well enough to your experience to be able to say they could just do it over and over again. 

Clinton: And the things you're hinting at, Scott, also are... I would frame them up as like, the, a rigid mindset, and when rigidity sets in. Which can be very destructive, right? So what do we do if we're noticing that, hey, there's a roadmap, and this is an established roadmap. This is it. This is our didactic, turn-by-turn directions. And rigidity is present. Either in the RFP, the way it's presented, or when we're talking to them as humans. How, again, do we make sure that nuance can win? And practitioners' voices can be heard? So, like, Ash, from your perspective, what's a way to not defeat rigidity, but to soften it? Because you're not going to get rid of all of it. But what's a way to really mitigate rigidity? 

Ash: Again, I'm going to go back to, like, proof is in data. And we talked about that pretty extensively. And then I think you need to find who your advocates are, for change. And that may be on the product level and you have to partner your way up to those... The power that be. But you really have to find your advocates in the process to help enforce the change. That simply put. 

Clinton: I'm going to kick it to Scott and... Similar question, just framed a tiny bit differently. But we noticed rigidity has set in. And people are not willing to deviate, or they don't seem willing to deviate to an established roadmap. What kind of approach do you take with that person, or a team where you're sensing and feeling that? 

Scott: It's very funny. When you were asking the question to Ash, my immediate response in my head was, you've gotta meet people where they are. But then I get angry at it, hearing that statement, even in my head. 

Scott: (LAUGHTER) 

Because some of the time meeting people where they are works, some of the time it does. But some of the time you need to show people what they're missing. You know, it's one of those things where, I like Ash's comment about data. Like, if you can start showing people with data, hey, if we were willing to go and take another tact, based on this data, this is what we could achieve. And so it's one of the reasons why, like, you know, there's a lot of naysaying in social media about agile right now, because of the fact that people don't understand what agile really means. But really what agile means is that it's about trying to understand how you actually operate and then make smart, measured change in order to get to a goal that you're trying to achieve. And if you can get some data, like, as a development team, if I can tell you how many story points my team can output in a sprint, we can then start saying, okay, well, based on the size of all these different objectives that we have, this is what we could accomplish during this time frame, or we could accomplish this during this time frame. And that way we give, sort of, a better view of what's going on to our partners in order to... Sort of start easing up on some of that rigidity, and saying, hey, I know that your vision is only this one thing, but look at these other things we could do with the same amount of budget, time, people, whatever else we want to do. And how we can get to, sort of, a different type of an endpoint here. 

Clinton: I dig it. So then, Jamie, I want to ask you, have you had experiences where you're, you know, kind of going toe-to-toe with somebody that is rigid, really set in their ways, and you're really trying to move them. So they're kind of this supervillain. Maybe they do have the power, and they do have the sway, and they do have the purse strings. And yet they're wrong, right? They're wrong in how they're approaching it. Do you have some experiences turning what were kind of supervillains within a client into, what become, like, your best advocates? You win them over, and they become extremely powerful advocates and provide lots of value that way. Any experiences or, you know, go-to tales in that realm? 

Jamie: Well, first of all, I ain't scared. (Laughs) I think that when you get the supervillains, I'm a fan of the Socratic method. And, you know, the vanishing cloud. That's a methodology to manage conflict. Where we ground on the fact that we agree that we want to accomplish this good thing. Right? So... And then the goal is to kind of reduce the uncertainty and bring clarity around, where do we, like, get to? And I think of, the person that is typically the most rigid, and I would expect them to be, is the CFO. She is writing checks to me. And so, to that end, like, I would expect there to be pushback, to say, why should I continue to fund this? No, we are going to go this way. This is what we've been spending money on. Or if it's somebody who leads an organization and they have a lot of skin in the game, and if a change has to be made, they have egg on their face, that the point is, really, is find out what is driving that person. Establish the goal, kind of, where you agree, or at least where you want to get to. And then, asking questions and kind of leading the witness, so to say, to get them to think through what it is you're trying to tell them. The other piece is, I will math my heart out. I think it's important to establish credibility around dollars and cents. I think it's important to set baselines, and it's important to compare yourself to the competitor that you hate the most, because those are the people who are stealing your customers. And what are they doing that you need to either get in front of, stop, prevent or whatever? So, there is value in digging in your heels and coming to the table to say, first of all, I'm not being a jerk just to be a jerk. There's a reason that I'm here pushing back on you, and it's because we're both anchoring on this specific good business outcome. We disagree on the approach because of reasons, and then I would just ask a lot of questions to either understand what their motivations are and give them some level of  calm, or I want to take them through the quantified thought process to get us to a different outcome. And when they don't, because that can and it does happen, I will tell them outright, that is the wrong call. But I will dissent and move on. Because not only have you bought consulting services, you've also bought some level of delivery. So we'll get it done. But when you want to, you know, acknowledge the facts here, let's hammer it out. And I have been wrong before. And I knocked on that person's door, back in the olden days when we worked in physical locations with people, and I was like, listen, you were right. I stand corrected. This is a really great, you know, takeaway for me. So, it's not about being right. It's about focusing on the thing that... Being right about the thing that you're both after. That's the easiest way to navigate through rigidity and conflict. And realize that, like, at the end of the day, the hard conversation has to happen, because we are stewards of millions of dollars. We are stewards of, if you're at a health insurance company, people's lives. We are stewards of all sorts of things, and it's up to us to be willing to dig in our heels as leaders and have those conversations, but also know when to shut the hell up and move on. 

Clinton: All well said. And for folks that want a bit more on that particular topic too, just a couple of episodes ago, we had Jim Brusnahan from Clarios on, and he went into a lot of the leadership skills he uses to work through some of these hard discussions that happen, real discussions that happen at an enterprise level, because the work is serious. Because there's millions of dollars at stake, and at the end of it, it might be patients' lives like you were saying, Jamie. It's some user, it's some human at the end being actually impacted by the technology we're building, which should always really be at the core of what we're doing. I do want to go with one more question. I want to end this on a shiny, happy people montage moment here. Everybody loves a good opposite day. Let's go opposite day. So, Ash, starting with you: what does it feel like... You've been in these environments to when engineering design and product strategy and the internal team, everyone buys in and everyone is actually aligned from jump street. We talked a lot about, today, what the crunchiness is and how that feels. What happens when it's the opposite? We're in opposite day land, Ash. Tell us what that feels like. 

Ash: I mean, it's rare, but when it does happen, it's magic. It truly is. I mean, from ideation all the way to scaling a solution, if you're in lockstep, like I talked about the two sides of the coin earlier, right? You have to be together at the beginning stages of defining what this thing is, all the way to being together lockstep in actually delivering it. And that is a truly rare thing. But when it does, you get to see a product come to life that has got scale, it's providing value, it's providing impact, and the journey isn't painful. And it's not necessarily painless either, because you're always navigating challenges no matter what they may be, but you're doing it together. It is a partnership. And instead of focusing on myopic problems that are really foundational, you're focusing on evolving the product in new ways, and you're actually innovating. Like I said, it's magic, and... More of that, please. 

Clinton: Scott, over to you. You've spotted the white stag of Narnia. Clearly it's very rare, but you found it. What does that feel like when these things actually come together from day one? 

Scott: I'm going to move away from C.S. Lewis and instead channel my inner Star Wars nerd because of Jamie and my backgrounds. But the way that I've described it to other teams is that, you feel like the Rebels. You feel like you can accomplish anything against the greatest odds, and you can just sort of make things happen, even though you really shouldn't be able to. And you can see in some of the work that we've done that, we have had this come together where you create something and you're like, holy cow, we actually made that? (Laughs) And it's one of those things where you feel so proud and impressed by it, that it sort of shocks you even, even though you were a part of the process of making it. 

Clinton: Love it. Alright. So Jamie, you're now in the X-Wing. You're channeling down the Death Star there. You gotta take your shot. What does it feel like for you when these three things: design, product, strategy, and engineering, come together to create magic? 

Jamie: It is like the lord of all dopamine highs. It's one of those where, you hear the phrase "more than the sum of its parts." And that is when you actually understand what it means. Because you don't have somebody there who is a superhero. It's the Justice League. It's not just, you know, some superhero and their poor sidekick running behind them, picking up their trash, right? So, it feels so good. It is proveably useful, because you're making a difference in somebody's life, even if you have just made somebody's workday less of a pain. And that's this, the level of stakes that you're at, versus, you know, creating something truly innovative that changes the way that we travel or move people. It feels the same regardless, because you've had the opportunity to really leverage the best out of people, to watch individuals grow. People who think that they have these limits just organically surpass them and not even know it. I've seen it and been a part of it a few times in my life, and it's the only time, to me, where the phrase "man, those were the good old days," like, actually felt good to say, because you had this dream team of people who trusted each other, who respected each other to just get it done, and who argued with each other to make sure that we held each other accountable, and the end product was pretty cool. 

Clinton: Love it. Alright. That is a great place for us to wrap it today. A huge thanks to Ash, Jamie, and Scott from our Launch team. It was passionate. It was informative. It was chock full of pop culture references if you were listening carefully enough, I hope you were. And for everyone out there enjoying these Catalyst podcasts and conversations, please share it with your colleagues and friends. Because in this studio, we believe in shipping software over slideware, that fast will follow smooth, and aiming to create digital experiences that move millions is a very worthy pursuit. Join us next time as the pursuit continues on Catalyst, the Launch by NTT Data podcast. 

(CATALYST OUTRO MUSIC) 

Show full transcript
Back to top button