Strategic Gridlock? Discover the Tools You Need to Drive Product Decisions
Strategic Gridlock? Discover the Tools You Need to Drive Product Decisions
Many CEOs will tell you that they’re the best-informed people when it comes to knowing what customers need — and that they’re in the best position to drive decisions on product priorities. What happens here is that these expectations and this type of behaviour become the primary contributor to product strategy gridlock.
Often people will become product managers by default rather than through decision. What the CEO needs to do is shift their focus toward building the product leadership team, empowering the product manager to think strategically and focus on features that map and complement a ‘high level’ strategic baseline they set for the product.
When there’s no solid product leadership team in place, it can lead to several challenges in the product delivery, from internal politics and lack of prioritization to miscommunication and inadequate discipline. When you have a confident product leadership team who can build and nurture the product team, drive product strategy and processes, grow cross-functional collaboration and accomplish successful goal alignment, then nothing can get in the way of product success.
Hi everyone, my name is Paul. We're going to talk a lot about product management and how oftentimes some of the biggest problems when working in products, which is very iterative and it's not a project waterfall type of approach, it's really a continuous deployment environment, how you need to figure out how to work with a leadership team who oftentimes blackmails you with tons of ideas, tons of improvements, some of the things that could eventually lead a product to just boil the ocean, having engineers basically just releasing features that don't add much value, really bloating the product and just not making it as valuable as it could be.
So today we're going to talk a lot about strategic gridlock, which is how to basically avoid it because ultimately when it comes down to product managers, user experience designers, as well as engineers, marketers, salespeople, leadership, and everybody can have the best of intentions. But unfortunately, when you're building a product, you really have different working styles. The sales team has different working styles than the marketing team was different working styles than the UX and product and engineering team. And that really creates a lot of issues. And usually what happens in most growing organizations is that we have a tendency not to really understand what the product manager does, what the designers and engineers do.
And this quote of Steve Jobs pretty much articulates the fact that, you know, we often tend to give to the a lot more influence to the marketing and sales teams. They're often seen as the ones who are moving the product forward in terms of revenue, in terms of influence. And that basically gives them some kind of authority over, you know, what features the product needs to be delivering.
So oftentimes when that happens, when you have the marketing team just winging it in some ways, or the sales team just winging it, the impression that that gives inside of an organization is there's a lack of priorities. And mainly because they're not product managers. There is no roadmap. They're just basically making decisions because their function of marketing and sales isn't really geared towards moving a product iteratively. It's actually geared towards doing marketing and sales. So why are they making calls on what features we're supposed to be releasing and what we're supposed to be working on and prioritizing? So oftentimes the gridlock that happens in most product organizations is that there is no priority. Who's making the call? That creates a lot of internal politics. The engineers want to work on their pet projects. The CEO wants things to be delivered. The sales and marketing are basically pushing for features the customers want or prospects want and you have customer support that wants all the bugs resolved. And that creates a loss of direction. And the engineering teams often feel like they're being set up to fail.
That includes the product and UX team and contention develops where there is like what we like to call these days, quiet quitting, right? The engineering UX and product team just become yes, man. They basically just go forward with whatever feature people are asking them to work on. And that creates a lot of people issues. People leaving the company wasted resources and product is not going to succeed. So what we need to come to terms with is the fact that a product will work will basically deliver value iteratively.
And that iteration has to come through a gateway, which is the product manager. The CEOs will have a lot of features and shiny objects and R&D issues they want the engineering team to focus on. The customer success is going to want every single bug fixed, every single optimization to optimize. And the sales team is going to basically take esoteric features that are being requested that people that are prospects, they're not even actual customers, but their feedback somehow is going to take more, have more value than the actual customers themselves. The marketing team is going to look at the competition one exact same thing. And the engineers are basically going to constantly complain about technical debt and having to like remove that debt. So the product manager here, their role in all of this is to take everyone's request and basically try to identify what problems they're trying to solve. What are the problems? These are not about customer problems. Sometimes it's internal business problems. Sometimes it's about how we basically work internally, what is being done manually, what can be automated, where the customer is hurting the most or where are we hurting in the customer sales cycle or the customer acquisition. So all of these problems need to be understood. And the product manager's job is to take those problems and put them in a big parking lot. And a parking lot, the reason we call it a parking lot is because it's just where ideas go to stay, park, not to move forward. And ultimately it's the product manager to determine, okay, which one are bugs, which ones are blockers, critical, major versus minor and trivial, because not every bug should interrupt the engineering time. But also what are we going to, from these ideas, which ones are we going to do in six weeks, six months and six years? Because oftentimes when the CEO asks for something or the engineers complain about something, that doesn't mean we need to immediately be working on it. There is also, there's always this short, mid and long-term timeframe. And in most software companies that we refer to as the roadmap and the product manager is the owner of that roadmap and product leadership. This is the CEO and the VPs and the directors of the company have a particular responsibility of steering the product team towards a particular direction. But unfortunately, product leadership is messy. You've got marketers, salespeople, a CEO, CTO, CFOs, and they get into meetings and the opinions are dismissed and conversations are basically taken on the side. And eventually as a product manager, you will realize that you're not adding much value. The first version of your product added a lot of value. Everybody was like, hey, the simple feature is so awesome. Customers are loving it. But as time goes on, as features get released, you realize that the value of the customer is getting out of your product is just decreasing. So decreasing to the point where you really start looking at, am I really understanding my customer? So you do this customer understanding effort and you release a bunch of features that really add value and people are feeling it. And then the sales team comes in and adds a bunch of features and no one uses and the value of the product goes down. And then you do another effort of really understanding this to your market. And that basically allows you to get nice one. Great. The product is doing really well. And again, the marketers come in and they basically want a bunch of things figured out because the competition has it. You release the same features of the competition and ouch, it doesn't work. And we count continuously zigzag. And as we zigzag from adding value and removing value, the product adds more and more complexity. And eventually we start making revenue. We start moving forward. But imagine if there was a way of avoiding all of these bad decisions from happening because ultimately this zigzagging is not really good for an organization. Sometimes you're working on value producing features, sometimes you're not. And a lot of companies will die because of their insistence on releasing features that don't add much value to the customer.
So at Bain Public, we've come up with this idea that we call SOAP. SOAP is basically a hygienic thing where every quarter you need to basically move your product forward by making some key decisions on what you need to basically move forward on and be honest enough on the things that you're not going to be touching on. And the whole foundation of SOAP is a product manager has to have some kind of a guideline.
So the high level strategic leadership of the company, that's the CEO, the CFO, the VPs and directors need to pretty much on one page explain what the product is supposed to do. So that includes what's the big hairy ambitious goal of the product, the value for the customers. What are we going to ask the engineers to basically focus on? That's what we call the product mission. What are the various strategies the product needs to be able to achieve in order to differentiate itself on the market and not be cloned by competitors? And well, as well as what are the various tactics that align themselves with each strategy?
So I'm going to show you an example with Tesla where, you know, Tesla has a b-hag of being a zero, living in a zero emission world. The value proposition is really about competitively priced products that are energy efficient. The mission of the product is really to transition the world to sustainable energy through transparent R&D efforts. And what is transparency of R&D effort really mean? What aligns with this strategy here of basically anti-IP? All of our patents belong to you. They basically want to basically put patents out there to the world. And that's because they want to safely use the patents of companies using their own patents as a trade off. So everything at Tesla has basically been defined strategically with particular tactics and particular metrics that allow the company to make decisions pretty regularly on what to move forward on and what not to move forward on.
So in some ways, the leadership team of a company, again, that's the CEO, the C-suite, the directors and the VPs need to align on this high level strategic baseline that basically brings you all the way from BHAG to the various tactics the company is going to use in order to accomplish what it needs to accomplish. And then the product manager, the UX team, the data and engineering team need to find various initiatives that align themselves to the tactics and the strategies that could potentially solve a bunch of problems through product releases that are basically going to allow the company to achieve its objective, its KPIs and indicators. So normal to say that every single feature of a product cannot be delivered at once. So any given quarter, based on this high level strategic baseline that's been given by leadership team, the product team needs to go and present a number of initiatives and ask them from the leadership team, look guys, we have, let's say a million dollars of engineering firepower for the next three months to invest our time in. Is it possible for you guys to let me know which one out of these 12 initiatives we're going to need to move forward with? Here's how they align to the tactics and strategies. Let us know which ones we're going to move forward with.
And the leadership team needs to have a way of making this decision and identifying the red ones that they're going to move forward with. As soon as the red ones have been identified, it's pretty easy for people to figure out what are the product releases in order to outbound communicate it to the customers, to the prospects in the world, that here's what's going to change about our product and what the engineering team and UX team needs to be working on. So ultimately it comes down to the product managers to be able to take all these problems and to represent them as initiatives that solve those problems through the various features of the software. And that needs to be rigorously done.
So ultimately we've come up with the concept of a pillar. A pillar is basically a problem that you're trying to solve. So a pillar is one, if you look at it, all of these items here are pillars. So a pillar is basically an initiative that's being proposed by the product team that solves a problem that has a particular objective that will allow the company to achieve a key result that there has a strategic importance for the organization to do so and some value that it creates for the customer.
A pillar is also a combination of a good old business case, this layer that you're seeing here, as well as a scope statement. So the scope could be divided into must haves, nice to haves, and wish lists. And the idea for the dividing it up is because you want the engineering team and you want the outbound communication by marketing and sales to be done based on things that you can deliver in a three months timeframe. So the must haves needs to be delivered in three months. The nice to have and wish lists will be delivered only if we have time. It's a nice to have. So we ultimately get into the must haves that could be UX improvements. It could be technical debt. It could be some kind of online unplanned features or deal during feature, but you'll write it down. And ultimately what you're asking to the leadership is here's where we suck. I'm the product guy. I'm going to tell you guys here's where we suck as an organization and here's where a product can improve.
Each pillar has a problem statement. It's a good old business case with objectives and key results, but also each pillar has scope where if you look at the must have and ask the engineers, how long is it going to take you to build this? Can you just give it to me in t-shirt size estimates, small, medium, large, you can get a pillar to basically show you, get an estimate against each one. So if you were to look at them one against the other, I should be able to say, well, I mean, given the amount of engineering firepower I have, let's try to do these two large ones rather than just doing this extra large one. That's a fine constructive conversation to have, but that doesn't really solve the problem strategically. Basically what the leadership team needs to look at is present me all the pillars. We're going to choose the ones that make most sense for the organization.
The best way to look at that is to have a decision-making framework, a bunch of questions the leaders need to ask themselves once these initiatives are being presented. So first off, what is the investment of resources? That's going to come from the must have scope that the engineers are already put in place and defined, but what is the customer's willingness to pay? What is the customer's perceived value and what impact is it going to have on our company? Let's go and get some data across each one of these pillars so this way we can evaluate them on quadrants. So customer's willingness to pay versus the perceived value could be evaluated if we can get the leadership to basically express themselves on each pillar.
If they basically provided that data to us through meetings, then we can easily say which ones are going to have high willingness to pay and high perceived value, which are the core features, but the differential features are the ones you're looking for. That's the one you need to go after. But also you need to look at the impact that a particular feature is going to have versus the level of effort you're going to put. Because if you put too much effort on something that's going to have low impact, that's a money pit. You don't want to go forward with that.
So ultimately the leadership team needs to look at what the product team is presenting in terms of a good old business case with scope and estimates and basically make those decisions on what they're going to move forward with and what they're not going to be moving forward with. The items that get discarded go into the near term and the engineering team with the UX and data team can start working on the next quarter. Now next step is to basically start taking down pillars that we've already agreed on for the next three months and breaking down what we call the scope matrix. The scope matrix is now taking pillar must have features and breaking them down into more detail.
So for example, if I'm going to add functional features to pillar one, well, I have workflow simplicity, I have personalization. Those are UX tasks, but the security fixes are can go straight into JIRA into a ticket because they're non-functional features that basically require the engineering team to deliver a firewall or traffic filtering. So once you have a decision from the leadership team on what we're going to do in honesty of what we're not going to do, it's easier for the product manager to break down the features, the pillars into its multiple sub tasks, identify which ones are UX, which ones are non-functional and be able to delegate it down to the engineering team for execution.
Now what's important is that we basically fixed time to three months. We have three months to deliver this scope. Unfortunately, we might encounter some problems. One thing we know is that we've decided the pillars we're going to move forward with, those pillars are aligned with the tactics and the strategies that give that the high level baseline that was set by the leadership team. So nothing is going to be a waste. We also know all the scope that's going to be delivered.
So at this point, it's easier for the product manager to outbound communicate to the marketing team, to the engineering team, to the support team and to the sales team, what is going to happen with the product because it's pretty well known. If I look at all these details of what's about to happen, I could basically promise the following features are going to be released. So it's a lot easier for the sales team to go out and talk to customers about the future evolution of the product. It's easier for the marketing team to update the website to let them know of what's coming up and it's easier for the customer support team to basically tell customers that future fixes are coming.
But ultimately nobody likes being told what to do. So you are a product manager and you're working with all these departments and none of these departments wants to work with you. Why? That's just human, right? People are defensive. They're like, why did you make these decisions? There's a little bit of rebellion and all that. So what's really important is if the product's not going to move forward, unless all these departments marketing, sales, engineers, support are aligned on why we're building what we're building, which comes down back to the reason why we originally presented this particular project. These initiatives had business cases in them and they had an alignment with the strategies and tactics of an organization.
It's important for the product manager to remind people that ultimately we're not building anything here. We're trying to create the most value with the engineering resources we have. So the good habits that we need to do about roadmap completion is give ourselves the three months in order to figure out what are the other problems that we need to fix. You might not be happy with the decision the leadership team took today about features that are going to be released in three months, but I'm listening. Tell me what other problems that this product has because I need to identify other opportunities for us to make decisions in the future.
So what word that we like using is prewire. As a product manager, if you're basically releasing features iteratively and your job is to identify problems in order to get them dissected into business cases and approved by the leadership team, you have a certain responsibility to sit down with every single department and have these meetings before the meetings. That's what we call a prewire. It's basically informal conversations with marketing, with sales, with support, with engineering, with UX in order to really understand the problems the product is having and just make sure that whatever they're telling you, is it coming from anecdotal evidence or it's really data-based. They have backed with facts, right? And basically start negotiating and compromise and understand their way of thinking because ultimately if you're not trying to build a company where decisions are made by consensus, you're trying to build a company where decisions are made with consent.
That means if the company judges that the particular pillars that were identified are the correct ones, it's not about getting everybody on board to say I'm in. It's about making sure that everybody acknowledges that we are moving forward on this particular initiative because it makes the most sense for the end user and makes the most sense for the company. Marketing might not like it, salesman might not approve of it, but we have consent to collectively move forward. So there's a difference between getting consensus and getting consent. Consent can only be gotten if as a product manager, you are delivering pillars, business cases and scope statements that align themselves with the company's strategies and tactics.
And ultimately product enablement, which is the output of these business cases that turn themselves into product features. The enablement is the outbound communication of that to the customers through customer support marketing and sales is going to be done by departments you don't control. So it's quite important for you to make sure that there is a process of how you're presenting these ideas, how these ideas are collected and first of all collected by these various departments turned into problems, represented to the leadership aligned with the high level strategic baseline and ultimately decided on what needs to basically be built and how the product will change.
I want to thank you for giving me this 20 minutes to explain how we at Bain Public do things within organization. We have a way of working that is just best in breed approach to product management. And if you basically want to book a time with me and talk about it, we love learning about other companies on how things are. And the SOAP approach is basically this approach that I just described in the last minute.