It's fair to say that I've worked with some challenging product owners.

Or, more precisely, I'll just say that some product managers can be unrealistic, and some, dare I say, can just be unreasonable, pompous, arrogant, and self‐serving.

And then some are true collaborative geniuses. These maestros win over stakeholders to buy into visions and customer value propositions without getting sucked into appeasing everyone's wish lists. And they know enough about the architecture, technology, and data to ask agile teams smart questions without getting under their skin.

But the reality is, unfortunately, that some product leaders lack a sufficient understanding of how technologies work, what processes make development teams successful, or even the simplest things like treating developers nicely.

The requests they make in their requirements are often outlandish. The timelines are insane. The expectations are that everything should just work like their favorite websites developed by unicorn consumer startups. The belief is that developers must replicate a web designer's work of art with pixel‐perfect precision. Like it's Picasso's design even though it's gone through dozens of stakeholders and hundreds of revisions that convert a work of art into a messy, confusing canvas.

Seriously, it's really easy to get developers on your side. Compliment a developer and show interest in what they are working on, and they're yours like puppy dogs. But some product owners just ask, and ask for some more, all without giving any form of thanks or acknowledgment. How foolish and shortsighted is it when product owners beat up their development teams?

But here's the reality technologists know and have the treads on their back to prove it. When something goes wrong and the business wants someone to blame, the most challenging product managers pummel the technologists.

And maybe it is the developer's fault that there are delayed releases, outages, security issues, defects, clunky user experiences, mounting technical debt, poorly documented applications, duct tape integrations, shoddily architected databases, code without unit tests, manual builds, and error‐prone deployments. Perhaps it's the development team's fault when their software releases require patches, emergency break fixes, or hotfixes—whatever your organization calls them.

Or maybe it's product management's fault for overpromising and pushing every stakeholder's whim downhill into the development backlog. Perhaps it's their fault for saying yes to everyone and then blaming the technology department for missing deadlines, scope, or quality. It doesn't take a rocket scientist to know that a team of five developers can't deliver fifty features in three months. But go ahead, say yes to everyone, and then blame the development team when you get called out. That's a surefire sign of a poor product manager.

I have to confess that I am an internet veteran who started work on web applications in the mid‐1990s. That was before the Agile Manifesto,¹ the DevOps movement, user experience (UX) best practices, and sophisticated agile and Kanban tools. So, while I worked with product managers, there was no role or job description of the agile product owner as we know it today. Some product managers were old school and spent their time developing and managing large requirements documents. Others just came to us with their ideas and requests. It didn't matter too much because we didn't have a significant legacy of technical debt to maneuver around.

And the technical expectations were low. Back then, you had a server that passed a request off to an application, and then it returned HTML back to the browser. There was no JavaScript, and there wasn't even CSS. We were most concerned about the quality of search results, basic design principles, and page performance. Delightful user experiences, large‐scale scalability factors, advanced analytics, and best security practices were not the top considerations.

Quite frankly, some of the product managers I worked with in those early days of the internet were super‐talented and excelled at building products. Some lead product management functions today at large software powerhouses, while others run their own businesses. They “got it.” They understood the role of product management, operating a swivel chair in the middle of everything.

On one side of the chair, some existing customers want things to work better. On the other hand, business function leaders from sales, marketing, and operations want to grow revenue and become more efficient. Then there's the list of customers who say they won't buy the product until it has all these bells and whistles—at least that's what the salespeople say. Then there is the CEO. Yes, the CEO comes in with today's big idea and stacks it on the pile of pots in the sink.

But great product managers don't dish it out. They don't just take everyone's orders and throw them into the kitchen. The restaurant only serves so many tables, and if everyone orders at the same time, the kitchen backs up, and it delays customer service. The restaurant has a menu with options to address customers' interests and dietary restrictions, and many won't let patrons design their own dishes. In well‐run restaurants, the front‐of‐the‐house staff knows how to work with the back‐of‐the‐house crew. They know how to ask for special requests when they are genuinely needed. They're skilled at thanking people. They know how to share constructive criticism when people need to learn from mistakes and failures.

Other product managers really have no clue. Instead of listening to customers and markets, they sit in their offices dreaming big and writing novel‐long requirements documents. When business leaders ask for everything, they demonstrate how well they capture requirements and how slow technology teams respond. They attend agile sprint reviews so they can cover their asses or better communicate status to leadership. Technical debt is not their problem. Fixing defects and operational issues are the must‐eat vegetables on the side of the product owner's perfectly well‐seasoned steak. The development teams should address them on top of everything else they prioritize.

I suspect these product managers are on alternative career paths today. But organizations are so poor at understanding product management, it's likely some of these poor performers are still doing the same things, just with different companies and teams.

So, let me share with you some of my stories working with product managers, architects, UX designers, agile teams, stakeholders, and executives in taking customer‐facing products and employee experiences from ideas to successful realities. Everyone in this group has responsibilities for innovation, instituting best practices, and delivering business outcomes. But they come to the collaboration table from different disciplines, often with conflicting implementation objectives. Being a Digital Trailblazer requires finding the right balance across each discipline's best practices, prioritizing the optimal levers to pull, and pivoting the plan when necessary. The balance to turn pie‐in‐the‐sky ideas to great experiences developed on scalable architectures isn't easy to orchestrate. I've had my share of challenges, mistakes, and lessons learned along the way.

What to Do When Asked for a Roadmap

Things were crazy in the heyday of the internet's startup, but when the internet bubble burst in 2001, companies had more time to develop web applications with higher quality. In the twenty years since then, more companies have invested in developing web applications, but there remains a lack of knowledge among business leaders on how to work with technologists.

One day, I am sitting in my office trying to get some quiet work done. It's a school holiday, and I have the fortune of bringing my son to work with me. Ronan is six years old with a mind of his own. It's the early days of iPads, but pre‐iPhones, and he is showing signs that he may grow into an innovator and great engineer.

He takes apart everything.

We never have a television remote with a back cover. Every remote‐control car he has is in pieces through his version of quality assurance testing. I forget how many DVD players are in shambles from his tinkering. Everything to him is a science project, and he experiments with taking things apart and seeing what's inside. He rarely puts them all back together.

But that day, he is in my office with my iPad and in his own personal heaven. He never runs out of things to do, bouncing from one application to another. If he gets tired of playing a game, he can put on YouTube. My wife and I are afraid of having our kids wear headphones, so my biggest issue is reminding him to keep the volume low. People drop in to say hi, and I have to prod him to look up and respond.

Meanwhile, I am reviewing my team's plans and application architectures. We are in the early stages of building a new platform for an SaaS product. Of course, we never call it SaaS. It's a faux pas to say that an information media company is a data, analytics, or God forbid, a tech company. It boggles my mind that company executives don't want to admit technology's importance to their business. To many, it is heresy to suggest that we should operate like a tech company. Never mind that a media company is worth maybe twice its revenue, while any technology company, let alone one with proprietary business data, can easily fetch a tenfold revenue multiple.

I ponder this while reviewing the architecture plans. The corporate CIO requires business unit CIOs like me to work with the enterprise architects who report into a central IT organization. Unfortunately, these architects are two steps to the right of having any accountabilities to the business, and they have very little responsibility for making engineering teams successful. They all have experience with enterprise systems, but from what I can tell, none have any experience with web, SaaS, or customer‐facing technologies. Yet, they come up with the most beautiful and elaborate architectural drawings. In PowerPoint. Everything is neatly depicted in rows of capability with one line of integration up and down the stack. Their presentations should have been titled, “Build this, and all will be great.”

There's more fiction in an architectural drawing delivered via PowerPoint than the best web designs concocted in Adobe Illustrator. And anyone who has ever been hands‐on with any platform, system, or proprietary application knows too many architectures defined by ivory tower enterprise architects are complete fabrications. They look good. They make executives feel like they are buying and building something achievable and straightforward.

But in reality, these drawings, fabricated in the La‐La Land of some “expert’s” office, are complete bullshit.

But it's my job to review this PowerPoint. I must see what to support and where to dig in and challenge.

So, I am sitting in the office with one eye on these crazy architecture PowerPoints and another on my son watching YouTube videos when I hear a knock at the door.

It's Johnathan, the new product manager who now has full responsibility for the product that's in early planning. Nice guy. Experienced, which is somewhat refreshing, and he's coming to see me early in his learning process. That's a good sign since I didn't get to interview him and have no idea whether he is overly opinionated and arrogant or a collaborative and a well‐rounded product executive.

After some smalltalk, he looks up at me, notebook on the desk, pen in hand, and goes straight to his primary question.

“What's your roadmap, Isaac?”

A roadmap? I am with the company for less than two months, and he is with the company for less than two weeks. What the hell is he looking for in a roadmap?

I'm pretty sure that's not how I respond to him, but instead of following up with any details, he repeats the question with more words. “What's your roadmap of where you want to take the product? What releases do you have planned?”

My kneejerk response that I say inside my head is, “Hey, buddy, that's your fucking job, isn't it? You come up with an unrealistic roadmap. You sell it to the executives. You promise the world to customers and make great friends with the salespeople with your grand visions. My job is to take your work of fiction and make it close to reality. And somehow do this in record time, with a team that has historically struggled with execution, and then also ensure that the application is reliable and secure.”

But the real problem is, I don't have a roadmap yet, and I don't even have releases. I am just getting the team to understand basic agile practices. How to run a sprint, what meetings we need, how we should use agile backlog tools, how to properly run a standup, how to get process improvement from retrospectives, what commitment means, how to get users’ stories officially done at the end of the sprint, and how to run a sprint review. The basics. The teams aren't ready to define software releases, let alone roadmaps.

Had I told Johnathan just that, I probably would have gotten him to walk away. Instead, I give him all the details and never answer his question. Maybe if I share some of the technical issues with him, he'll go away?

I answer, “Our databases are an urban sprawl of tables, integrations, and the most complex queries you've ever seen. Our search interface is six‐screens long because the last product manager wanted to ensure that all search capabilities were available to every user type. Never mind that it takes over 10 seconds to render this page. We're not using any of the latest web 2.0 user interfaces, so customers are sitting there watching entire pages refresh after making a couple of clicks. And then there are all these other analytics capabilities we sell to customers, but today they are engineered in Microsoft Access databases and shipped to customers on CDs.”

He just sits and stares for a few seconds. I celebrate in my mind, “Yes! I overwhelmed him! He has nowhere to go and can't think of a follow‐up question!” But after all my ramblings and a brief pause, he repeats his question.

“Isaac, I get it. But you must have a sense of where you are leading teams. You must have a semblance of a roadmap in your mind, right?”

This banter going back and forth is getting tiring, but not for my son. He just keeps hearing roadmap, roadmap, roadmap.

He figures he'll help his dad out, just like raking leaves in the backyard. While Johnathan and I are going back and forth, and without either of us noticing or paying attention to him, Ronan goes to the whiteboard and starts drawing.

And after the fourth time Jonathan asks for a roadmap, Ronan announces that he has an answer. “Daddy, here's your roadmap.” (See Figure 4.1.)

Ronan draws a swirling set of roads curving around, overlapping, connecting, and separating. It is a mess of roadways on a map. At six, he is just listening and developing solutions. It is fantastic, and I am proud of his simple, though obviously nonfunctional resolution.

I look over at Johnathan, who is embarrassed and insulted, though through no real fault of my own.

But the genius is that the roadmap he drew is the best response for today. We have no sense of direction, which as a senior product manager is Johnathan's job to learn and share with the team. We have no architecture, but we know some of the problems that need addressing. We are still developing our agile processes and are not ready to plan and execute releases. We are a mess and need to straighten things out before forecasting, documenting, or communicating a roadmap.

But that question and requests for roadmaps keep coming to me in other means and forms.

When the Product Roadmap and Architecture Require a Hard Pivot

A few weeks earlier, I was working with another product manager. Charles spent six months working with the technology team on getting a new business intelligence platform approved at our enterprise. Getting this approval was no easy feat because the platform they wanted required an exception from enterprise standards.

If you don't know what that means, let me explain. The enterprise architects, the corporate CIO, and everyone and anyone in an operational role will make your life insanely difficult for asking for new technology. Never mind, there are no financial incentives to use their standards. They haven't developed plans, training, or best practices to help business units succeed in applying the selected technologies. Standards are largely elaborate PowerPoints or slide decks that communicate why the central IT group chose the platform, and the architects who develop these decks are rarely hands‐on enough to test or prototype with the technologies.

But Charles somehow got past all the blockades and obstacles. IT installed his business intelligence platform in the data center (another miracle that I should point out because back then, it took months to get IT ops to install new infrastructure). He has a corporate sanctioned team from a service provider working on it. They are even using agile methodologies and are on their fourth sprint of application development.

It's my first week at the organization, and the CEO pulls me into his office. “Isaac, before you do your assessment of the technology team or start thinking about developing a plan, I need you to go check out this analytics product that's in development. The team working on it says the product will go live in August, and I'm hoping that it will be a big win for the organization.”

I start thinking about the timeline and making some back‐of‐the‐envelope calculations in my head. It is May. The team is sprinting, but they still need time to test the application, validate performance, and meet security requirements. I expect the team to be largely done with product development and coding to hit the August deadline. The main functionality should be demonstrable, and they ought to be planning user acceptance testing, performance testing, and security reviews. It's with these expectations that I meet Charles and the development team for a demo and review of the implementation.

I watch the demo with growing fears. It ends in under five minutes, and my jaw drops, the mic is on the ground, and I am screaming inside my head, “Oh, no, this is a shit‐show.”

I am appalled at what the product looks like and where they are in its development.

Imagine you have a contractor upgrading your vacation home only a couple of months before you plan to visit over the summer. Only the house is in shambles, and everything they install is done with shoddy materials and lacking any craftsmanship.

When you look at a business intelligence (BI) tool, you expect some decent‐looking, easy‐to‐use charts and graphs. I hope to see stacked bar charts, some versions of pie charts, trends, and some usable data grids. But that's not what I see at all, and I think an early version of Lotus 1‐2‐3 has more inspiring data visualizations.

These charts are primitive line graphs, and a few places on a web page are labeled as “dashboards.” There is no navigation or user experience, so I'm not sure anyone but the brightest subject matter experts with a strong understanding of the data can do much with the tool. There are no indicators on what questions and problems end users can ask and answer using the “dashboards.”

This isn't a product ready to launch in a couple of months. It is not an MVP, and it's barely a prototype.

Charles has a blank stare through the demo. I feel like I'm at the poker table with a pro who is staring me down, knowing that I have to make the next move. He wants my reaction and does a good job guarding his own. I don't know him at all and can't tell what he's thinking. Does Charles think the team will close the gap and finish the product on time? Or is he also disappointed with the results?

I formulate a calculated response to what I see and ask, “Charles, can we review the design and some of the requirements?”

I might as well start at the top. In addition to selecting the technology, the team spent a significant amount of time and investment with a web design agency to construct a user experience and site design. It is pixel perfect. I don't know enough about the customers, business, or underlying data, but the design certainly looks like a finished product.

So what accounts for the difference between the design and what the team produced? This isn't my first time seeing a significant gap between a product manager's expectations and the team's delivery. I've made an art and science of closing the differences, but I still need to learn more details.

I'm new to analytics and business intelligence tools. I've seen their output in the form of dashboards and reports but spent little time learning about their construction.

Now that I've seen the product and the requirements, it's time to understand the technology better. I look over at the team and ask, “Can I see the platform and the code?”

They look perplexed, and that takes me by surprise as I don't think this is an unusual or outlandish request. They're doing agile and having demos during their sprint reviews, right? Or maybe they're just a little taken back by this new CIO coming in and asking to look at code.

The developers tell me it takes about thirty minutes to set up the demo, so I pass the time chatting with Theresa, the development team's program manager.

I never had program managers with responsibilities on agile projects before, so I am intrigued. Theresa runs the standups with the offshore development team. They have one analyst with them, but the rest of the team is in India. Their standups last about forty‐five minutes (red alert signals going off in my head) and sometimes as long as an hour and a half.

“Is that normal?” she asks.

Well, no, that's not normal at all, but I let it slide. The team is running month‐long sprints. Did I hear that right: Month‐long sprints working on a new product with new technology? I find this highly unusual, but I hold back judgment.

The demo starts, and the developer shows me the BI tool and the development environment. Quite frankly, the whole demo isn't memorable at all except for one key point that stays with me for a long time after the event.

The developer shows me the code, and there's nothing spectacular about it. It reminds me of the old computer language Logo where you issue instructions on what to draw, except the one he's showing me is for a bar chart. Set the axis, add the data, design the bars, format text, and other configurations. He's walking me through this and scrolling through lines and lines of code. Maybe a couple of hundred lines of code to produce what? A single chart?

I'm hoping some rapid development tool generates the code, but the developer tells me that coding is done by hand using a text editor.

Oh, crap. And now I am having an oh‐shit moment and start adding things up. How many charts does this dashboard require, and how many dashboards are necessary for the product launch? And how many lines of code are needed to generate it? And how many iterations, improvements, and technical debt does that create?

It slowly becomes apparent what's wrong here.

I have a product design that could be a Picasso, and on the otherhand, I have hundreds of lines of code that generate charts that look like vintage MS‐DOS. It's being engineered halfway around the world in India through an agile process that, other than using the terms standups and sprints, bears little resemblance to the actual scrum process. And to make matters even worse, the program manager has limited agile experience, and she's been reporting that the program has a “green” health state for the last few months.

It's then I realize that they don't really know how bad this is. In fact, this business team didn't select the service provider or sign up to manage the project using agile methodologies. It's handed down to them from “corporate” citing best practices—which I had a hand in creating, by the way—that new products and technologies are an ideal beachhead for teams to learn agile development practices.

Only no one is coaching them on agile or the use of the technology. Not the technology vendor, not the service provider, and unfortunately not the corporation.

I hold back my thoughts and judgments until meeting with the CEO the next day when I break the news. “Adam, there's no way this product is launching in August, and that's not even the bad news.”

He's looking at me like he's trying to figure out my next words. Like what could be worse than being off on their deadline.

I continue, “I'm pretty sure the team is working with the wrong platform. And yes, I know they spent nearly six months convincing corporate that they needed this one.”

I say this with the mental picture of lines and lines of code scrolling by and the mental image of what the product looks like today. There's no way he's seen the product. I've demoed other products to him before, and he definitely knows what a polished business application looks like when it's a couple of months away from launch.

He looks at me. “Isaac, let me get this straight. The team works for months on selecting a platform and signs off on a design that looks great. They get an experienced team, run a project for several months, and report a ‘green’ status. Now, you visit the team for a day and are telling me that this is all bull?”

I pause for a minute and think. There's no easy way to put it. “Yes, Adam, that's exactly what I'm telling you.”

He thinks for a few seconds while his ego comes down from the stratosphere. Adam is also new to this organization and is looking for quick wins, but not for himself. He has nothing to prove given his success at completing several significant business turnarounds. No, this is needed for the organization to get its confidence back—to demonstrate they can do something new and different. He needs this win to buoy their belief that they can innovate with technology, and with that, ideally bring in new customers and revenue.

Adam looks over at me and says, “Okay, Isaac. How do we fix it?”

And inside, I think to myself, “Fuck.” I know better than to show up at the CEO's office with a problem but without a plan or a solution. I have nothing formulated as the next steps, let alone a plan. I'm so proud of myself for dissecting the issues in such short order that I hurried to his office without thinking about the next steps and what I will need to develop a plan.

More important, I have no idea what I need from him and the organization. What are the changes that are going to get this product back on track? These are things that you can't shoot from the hip. Even if you get it right, a good CEO will see right through you. You're bluffing at the poker table with a mediocre hand at best, and now you need some cards to fall your way.

I take a deep breath and reply, “We have to take a few steps back and review the vision behind this product. I saw how the existing product is delivered and have a basic understanding of its value. I saw a new design that looks great on paper but may not be feasible to implement in a reasonable amount of time or with a team that is still learning the customer needs, data, and technology.”

Alarm bells go off in my head. I'm losing him, I think to myself. I have to bring this back to earth. “The developers are following the whims of one product manager who knows the business and customer needs well. The rest of the team doesn't, and they're just trying to get the technology to do what the design requires. We need to pull up and make sure the team understands the product vision, and we have to help the product manager better understand how to pursue a minimal viable product.”

I'm watching Adam's expressions now, and I know he's beginning to understand. He's seen this before. But I go on because this isn't just a product management issue. “Then, the team is following agile ceremonies, but they aren't applying the practices in a way that solves problems. They need coaching, and I will step up to get this started. It's through this dialog we'll also review the underlying technologies and course‐correct if necessary.”

Have I covered everything? I trace through all the issues to decide what's relevant for the CEO to hear. Yes, there is one more, so I continue. “I'll also have to look at how we're defining projects and reporting on status. There's no way this project should have been labeled green for the last four weeks. There are plenty of signs indicating that this project is, at best, yellow and probably red. We can't have people sugarcoating status or afraid to report problems.”

Adam gives me his okay. It's his way of saying that he got it and wants me to come back with something more substantive.

When You Pivot a Major Initiative, Step In and Help the Teams to Transition

This story doesn't end here. I have to get this team to change their mindset and practices quickly. I start with the basic agile ceremonies and help Theresa adjust the forty‐five‐minute “stand‐up” to a properly run meeting lasting no more than fifteen minutes. We spend a ton of time documenting the product manager's vision, reviewing how customers use the legacy product, and defining some of the aspirations of the new product. We help the team understand how to write agile user stories and leave requirements documents as an artifact of the past.

But that is the easy part. The next step is separating the vision from the user experience and design, which was created in a vacuum absent of any realities of what it would require to engineer the underlying solution.

I pull the whole team together—Charles, Theresa, the engineers, the general manager of the business, and the head of sales for this product. I try to help the team understand. I start by sharing an honest assessment of where the product is and looking around the room to confirm where there is buy‐in. There are questions and some challenges that we work through, but I halt any suggestion of blame on one person's part.

I try to explain to the team and the business leaders in terms they understand. We work in the construction industry, and I draw some analogies and differences between architecting buildings and engineering experiences with data and technology.

“The challenges we see in the product and implementation are not a product management matter or a technology one. It isn't happening because of corporate standards and requirements. Don't blame the service provider or suggest the issues lie in India. We have a collective problem in how everyone is working as a team.

“On the one hand, you can't have the architect designing your new kitchen without an engineer there to provide feedback on the construction. Otherwise, you might end up with a design that requires upgrading foundations and takes too long or is too costly to construct. On the other hand, you don't want the engineers ripping floors and walls apart until they better understand what the new experience requires.

“Now some gotchas can happen in construction that can throw a curveball to a plan. Maybe an exposed beam is rotting and needs reinforcements. Perhaps the customer sees a new cabinet being installed and has a change of heart on her selections. In commercial construction, both situations require the owner, architect, and engineer to agree to pivot and adjust their priorities.”

I continue, relating the problem at hand to the construction analogy.

“In application development and technology projects, the number of unknowns is far greater. We work with a mix of familiar technologies, legacy ones, and new ones where we're trying to innovate. Just like in a construction renovation project, we might find technical debt, the equivalent of a rotting beam that needs fixing. We're equally likely to find that our customers better understand what they need as they see and use the product.

“It's for these reasons that we can't fully lock in the customer experience before and work completely independent from the engineering teams. Similarly, this team can't architect and select technologies without prototyping some of the underlying use cases.

“The designer and the engineering team must work together, iteratively, while building up confidence that the design and underlying technologies meet customer needs. And when we finish an iteration, we need to demo it in front of some users to get feedback. Are we on the right course? Is this showing the data you need to help drive decisions? Are we using the right terminology?”

Over the next several weeks, my leadership team and I work with this group to start afresh. We get agile fully in place with two‐week sprints. We then break down the essence of the product to a vision, high‐level epics, and then a handful of priority features.

We also start working with a different BI tool. Technology teams can't select platforms solely on their alignment to an exhaustive laundry list of current and future state capabilities. The selection process should include a better understanding of required skills and how the team wants to work. Checking all the feature boxes but requiring significant learning, skills, and programming to configure is not optimal for teams that want to build and test quickly. Time to value is a critical design criterion for digital platforms and seeking technologies that provide self‐service capabilities to business users has significant advantages. Especially in data and analytics tools, where the subject matter expertise is with the business and the best tools are easy to learn and adopt.

But selecting nimble, self‐serving tools comes with trade‐offs that require significant and repetitive dialog with business leaders. Some are still stuck with the 1990s notion that technology teams and platforms must fully align with business requirements—in other words, the business selects technologies, and IT implements them.

Screw that. It's dead wrong, and this misstep buries many IT organizations with hard‐to‐use legacy systems that are complex to integrate and support. Business leaders must articulate the vision, customers, value propositions, business opportunities, and constraints and then partner with technologists on solutions. And when I say technologists, that often means architects, developers, engineers, data scientists, security specialists, and others versed in the problems and applicable technologies.

And sometimes it takes a blow‐up moment to get everyone to understand it. That moment happens with this team about two months later.

How to Create a Blow‐Up Moment

The team accepts the new technology and is sprinting with the product owners. But I am watching the demos and getting wary of what I am seeing.

Charles is still trying to make the team match a specific workflow that he has in mind—a way of navigating the application that works for him as an expert, but not necessarily one that would work with customers. The dev team implements the workflow in the BI platform, but the performance is poor, and the experience is lackluster. The team hasn't learned the platform's best capabilities and how to design optimal experiences. Instead, they are trying to make the technology work against its best practices.

So even though they are operating in sprints, they aren't collaborating or learning together. What's worse, they aren't bringing all their stakeholders to their demos and getting broader feedback to make adjustments.

I could let this go on if I want, and the team will probably get a working product this way. But it will be subpar and unlikely to resonate with customers.

So I fix this on the grand stage.

Our CEO Adam and the whole management team visit this group for a full day of meetings, and I schedule a time slot on the agenda to do a demo. Charles would demo what the team is working on, but I fear a ho‐hum reaction. The product is better than where it was two months earlier, but it isn't going to wow or impress anyone.

And I know how this will go down. No matter how much I try to get business and technology teams to collaborate, business leaders are more likely to blame the technology team when projects aren't going exactly as planned.

I can see how this will play out. A big room. All the executives there, and the demo is less than perfect. The executive group is still new, and we're not operating as a team yet. They know I drove the changes, and I have a couple of supporters in the room, but I'm still new to the rest of them. So when the discussion goes south, the darts will flow in my direction.

Time for a preemptive strike. Anticipating this, I have an alternative demo in my back pocket that a friend of mine helped create in case things went south.

He's an expert on the BI platform, and I know the technology can do more than how the team currently uses it. I know it can look better, function better, and perform better. Sometimes a team just needs a bit of help to get started, and sometimes they need a little bit of a shock.

My friend reviews the data and the application and comes up with several alternative experiences that are more visual and vibrant. They use clickable charts instead of drop‐down filters, which should be easier for our customers to use. These dashboards show purpose and focus on specific questions and problems. And they're fast.

I share them with Charles and the team, but it's a lot to absorb. It's like looking at three completely different kitchen designs, knowing they are all functional kitchens. But which one will the customer want? Which is easier to use and sell? We need additional time to research these options, but I inform Charles that I may elect to share these screens with the executive group to get their feedback.

Awkward Blow‐Up Moments Often Lead to Innovative Solutions

Charles does his demo at the meeting, and I read the room. It's the first time the executives have really spent time on this product, and I see a group of blank faces. They are watching a demo of a sophisticated B2B product designed for a customer segment that many of them don't know very well.

But Charles has his own stakeholders he works with on the product. They are highly knowledgeable and work with customers daily. Some of them are also experts with the underlying data and perform ad hoc analysis on it regularly.

No one in the room is shy. The experts start asking Charles questions, and he does his best to answer them. Can it break down the data with customized dimensions? Can we add columns on the fly and implement nested sorts? Can we develop custom searches to define the views?

More questions are voiced, and Charles doesn't know all the answers. He lets the group know. “I'm not sure if the technology can do what you're asking.” That works the first and second time, but by the third time, I definitely see a drop in everyone's confidence.

And as expected, now everyone's eyes are focused on me. I see the pitchforks and torches, and they're about to scream, “Burn the CIO!” They're thinking: He chose the technology platform and brought agile here. He works with the corporate IT groups.

At that moment, I went for it. I didn't have anything to lose at this point. The group needs to see what the technology and the team are capable of implementing. When you walk into the car showroom, there's always more than one model on the floor. And when you're at the poker table, always leave yourself outs, and in this case, the alternative design is my big bet.

I display the alternative designs and begin talking through what they're seeing, but I'm not an expert on the data and the use cases. Instead, I just let the visuals do the talking. The dashboard has a map and some stacked bar charts to help users navigate to answers. It looks a lot better than the screen of drop‐down filters that Charles demoed earlier.

But we have detractors in the room who have high expectations. A demo to them implies a finished product. Charles hasn't invited them to the agile demos, so they aren't used to seeing a work‐in‐progress application. They aren't versed in providing constructive feedback.

The executives are getting wary. This is supposed to be a team‐building meeting, not one that creates new frictions. I can see the CEO is ready to cut off the conversation, and he has no problem killing dead‐end projects. I've seen him do it before.

But while this is going on, the head of the product's sales has stepped up to the screen. He's looking at the map and the bar charts. He's not your average salesperson; he's more like a sales consultant as he helps customers leverage our analytics products to grow their businesses. And he's more than a consultant because he's a stakeholder to our agile development practices and provides feedback on what customers need and around the user experience. He knows the dashboards must demonstrate the breadth of data and the value of the analytics, but also be easy to use.

It's at that moment that he turns around to everyone and announces, “Folks, this is exactly what we need.”

And over the next few years, this team builds three analytics products, adds customers, and grows revenue. The products turn around the business, and this is one of the legendary moments that truly aligns the team.

Here are key leadership lessons to take away from this chapter:

1. Align on the product vision because roadmaps are rarely straight‐line journeys. Organizations often try to pack too much into their business cases—resulting in lengthy presentations that may look impressive in the boardroom but are too complex for implementation teams. It's important to align everyone on the product vision before detailing the user persona, journey maps, values streams, and functional requirements.

   Start by creating a single‐page vision statement that clearly outlines how your product will benefit customers and stakeholders. It's easier to secure a shared understanding from a single‐page vision document than from a seemingly endless scroll of business artifacts. My company's vision statement is available for free at https://www.starcio.com/digital-trailblazer/vision-statement.

   Remember, the road to great products and experiences is never a straight line. It's easy to get lost in the details. And along the way, the product documentation will likely evolve through ongoing feedback and experimentation. When you have a single‐page vision statement that you can continuously point to as your north star, you'll be better positioned to keep your teams and business stakeholders focused.

2. Start with basic agile and scrum fundamentals when establishing new teams or course‐correcting struggling ones. When teams aren't working well together, it is not easy for them to accomplish their goals. There's a sizable gap between textbook agile and scrum processes compared to how people in groups interpret agile principles, mindset, and culture. So, when I hear a team is doing agile but missing goals, I start digging into their process. For new teams, I always begin by reviewing their scrum ceremonies, even if there are standards, tools, or expert coaches in place. Once the team has basic practices instituted, I review how well they use agile approaches to solve planning challenges and execution problems. All too often, teams go through the scrum ceremonies without understanding how to apply them to solve their issues, opportunities, obstacles, and conflicts. This isn't an overnight improvement, and the transition from practicing agile to agile mindsets takes time, best practice guides, and coaching.
3. Begin agile continuous planning immediately after defining the vision and agreeing to pursue a new idea. It's a misconception that agile practices begin the moment the development team kicks off its first sprint. It actually must begin sooner—from the point when a leader transforms an idea into a vision. Agile planning should start at the exact moment when someone begins working on the idea with little detail, like a row in a spreadsheet or database record identifying the business need or opportunity. That may seem premature but starting early sets up the entire product development process for success.

   Too many organizations miss this critical step. As a result, key team members miss out on the opportunity to add their input. Once the business need or opportunity is identified, agile processes should be adopted to ensure speed to market and deliver sustainable solutions.

   This means the product owner must iterate on the vision statement with the full team. The designer must iterate on their understanding of personas and user needs, and they must partner with engineers to gather their ideas and best practices. Architects must prototype with engineers using different technologies and implementation approaches, formulating success criteria that helps everyone align on an execution strategy. When product owners implement continuous agile planning from the get‐go, they are setting off on a stronger course.

4. Promote team culture by listening, reserving judgment, asking questions, managing conflict, and just being nice. You're probably nodding your head around this lesson as people largely have the right intentions when working in teams. But as pressure mounts to fulfill requirements, address quality standards, meet stakeholder expectations, and hit looming deadlines, we all lose our cultural compass at some point.

   We forget to do the little things like thanking people for their best efforts. We pass judgment too quickly without realizing we might be offending someone's hard work and best intentions. We're offended by questions as if someone is challenging our expertise, knowledge, or integrity. Asking questions is the required theater to build a shared understanding and secure “business‐IT alignment” or just alignment in general.

   One of the key differences between great teams and average ones is how they create and manage conflict. Teams that can learn how to step on each other's toes without hurting anyone are more likely to learn from each other, handle stressful moments, have fun, and create a culture that more people are excited to be a part of. Because these teams are open to challenging each other and debating solutions, they are more likely to challenge legacy practices, innovate collaboratively, and deliver robust solutions. When I showed the alternate BI dashboards to the leadership group, I hoped my colleagues would understand my intent and goal to bring a great product to market.

   It also means that these teams are more likely to avoid the hot‐potato culture—an environment where people avoid taking on new challenges and responsibilities. When there's a gap in ownership, people on these teams step in to fill it, knowing their colleagues will respect their judgments. For example, let's say your QA engineer is unexpectedly out the week of a major release. Who should step in and review the performance, security, and functionality tests for any major issues? On great teams, you'll find several people willing to step up and fill the gap.

5. Answer the question before steaming through jargon‐filled details, and have some ideas on the next steps. The single hardest thing engineers, product managers, and data scientists must master when progressing to leadership roles is answering questions top‐down without brain dumping all the underlying details. If the person asking the question wants details, they'll let you know what information they're interested in. While you must operate in the weeds, don't lose your audience in the swamp before providing answers to their fears and aspirations. And don't make the mistake of not thinking a couple of steps ahead on where to go next. Getting it wrong is okay and should be strived for, especially if it brings forth a dialog. If you are in the weeds and don't have answers on where to go next, then you truly are lost.

   So how should you adjust your approach to answering questions when your engineering, science, or business training often leads you straight into the details and problem solving? Part of the answer is coming into a discussion prepared. When I met the CEO around the product launch delays, I had a pretty good idea of what I wanted to say, but unfortunately, I made a serious mistake of presenting the problem without being prepared to discuss the next steps or solutions.

   Then when you are asked a question, don't allow your voice to run faster than your mind. Develop your active listening skills by pausing, thinking, and making sure you understand the question's intent. Get to the answer in your mind, and then you're ready to articulate it to your audience. Active listening, top‐down thinking, and succinctly answering questions are key leadership skills, especially when managing up to your bosses or trying to influence colleagues.

It was impossible for me to present product management and innovation without touching on agile practices, ways of working, and culture. And if you read my first book, Driving Digital, you know that I believe agile is fundamental to leading transformation. In the next chapter, I share some of the stories and lessons learned in developing agile teams and challenging an enterprise's waterfall practices.

If you would like more specifics on these lessons learned and best practices, please visit https://www.starcio.com/digital-trailblazer/chapter-4.