How to Align Stakeholders from Different Departments on a Product Roadmap. Speaking with Paul Ortchanian, CEO, Bain Public
Originally published on UXDX; Speaking with Paul Ortchanian, CEO, Bain Public
How do successful product companies lose their way?
When working in product, which is very iterative and it's not a project waterfall type of approach, it's really a continuous deployment environment. The problem is that many product teams need to work with a leadership team who oftentimes blackmail you with tons of ideas and tons of improvements, that could eventually lead a product to just boil the ocean. Having engineers just releasing features that don't add much value, really bloat the product and doesn't make it as valuable as it could be.
I call this strategic gridlock. Everyone has 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 who has different working styles than the UX, 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, and what the designers and engineers do.
This quote of Steve Jobs pretty much articulates the fact that we often tend to give 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 and influence. And that gives them some kind of authority over what features the product needs to be delivering.
The gridlock that happens in most product organisations is that there is no priority. The sales team is going to take esoteric features that are being requested by people that are prospects, they're not even actual customers, but their feedback somehow is going to have more value than the actual customers themselves. The marketing team is going to look at the competition. The engineers want to work on their pet projects. The CEO wants things to be delivered. There is no roadmap so the organisation isn't really geared toward moving a product iteratively.
The engineering UX and product team just become yes, man. They just go forward with whatever feature people are asking them to work on. The product manager just takes everyone's request and put them in a big parking lot, where they often stay parked. Eventually as a product manager, you will realise that you're not adding much value.
The first version of your product added a lot of value. Customers are loving it. And then the sales team comes in and adds a bunch of features that no one uses and the value of the product goes down. And again, the marketers come in and they 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 as we zigzag from adding value and removing value, the product adds more and more complexity. A lot of companies will die because of their insistence on releasing features that don't add much value to the customer.
That sounds familiar. So how do you go about escaping this trap?
At Bain Public, we've come up with this idea that we call SOAP. SOAP is a hygienic thing where every quarter you need to move your product forward by making some key decisions on what you will be focusing 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 explain on one page what the product is supposed to do. So that includes what's the big hairy ambitious goal (BHAG) of the product, the value for the customers. What are we going to ask the engineers to 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?
I'm going to show you an example with Tesla where, you know, Tesla has a BHAG of 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 anti-IP? All of our patents belong to you. They want to 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 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.
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 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.
It would be fantastic to have this level of clarity from leadership. How do product teams convert this context into action?
A pillar is an initiative that's being proposed by the product team that solves a problem and has a particular objective that will allow the company to achieve a key result that there has a strategic importance for the organisation to do so and some value that it creates for the customer.
Each pillar has a problem statement. It's a good old business case with objectives and key results as well as a scope statement. So the scope could be divided into must haves, nice to haves, and wish lists. Once you have the priority you can 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.
What do you use these estimates for?
What the leadership team needs to do is choose the pillars that make most sense for the organisation. 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 , also, 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 express themselves on each pillar. 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 make those decisions on what they're going to move forward with and what they're not going to be moving forward with.
This sounds like large upfront planning. How is this different to Waterfall?
We have three months to deliver but the scope is variable. We are not following a fixed scope, variable time approach. 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. 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 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 tell customers that future fixes are coming.
Great. So how do you move from the prioritization to delivery?
With this prioritisation we can 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 product manager can 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.
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 just 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.
How do you get people on board with the decisions that leadership have made?
As a product manager, if you're 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.
We call this a pre-wire. It's informal conversations with marketing, with sales, with support, with engineering and 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 facts to back it up, right?
And start negotiating and compromising and understanding 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.
What outcomes can teams achieve by following this process?
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 ides are collected by these various departments and turned into problems, how they are represented to the leadership and aligned with the high level strategic baseline and ultimately decided on what needs to be built and how the product will change.
- - - - - - - - - - - - - -
Would you like our Product Management Premiere E-book? Visit our Download page →
- - - - - - - - - - - - - -
