Aligning Product & Business Objectives
Aligning Product & Business Objectives
Distinguishing product objectives from business objectives is crucial in making sure your product delivers for your end users.
- How do you keep your product objectives aligned with ever changing business needs?
- How do you ensure that your product teams don't have their hands tied?
Moderated by Snjezana Momic, join the conversation, share your insights and probe the speakers on the elements of their talks that left you wanting more.
Pete Anderson: Morning or evening wherever you may be. My name is Pete Anderson. I work at US Bank. I've spent the last six years or so in project to product transformations across Target and US Bank and then a variety of experiences prior to that when it came to consulting and experiencing financial services industry but a primary focus for the last six years between those two companies has been project products and truly leading the transformation of folks that are in those kind of business analysis. IT types of gigs over into product management and transforming how we think as an organization.
Snjezana Momic: Thank you, Pete. It's Pamela.
Pamela Mead: Hi, I'm Pamela Mead. I'm Global VP of Design SumUp. I've been with the company since November. So, it's been almost a year which is pretty remarkable to think about. I'm actually German born. I've been in Silicon Valley though many, many years and came back to Europe just to really bring focus on customer driven innovation to Telefonica. And in the last couple of years here in Berlin working with different companies to really establish design practice within companies. And my focus is very much on how do we really enable design to be effective within an organization. How do we help transform companies to leverage design and ultimately, how do we really create products that are great for the customers that we're trying to serve. So, very passionate about the transformation. It's always part of the journey, but also really passionate about great products which I think is one thing we need to really keep focusing on how to develop.
Snjezana Momic: Great Thank you. Adam?
Adam Copeland: Hello, my name's Adam Copeland. I work at Mayo Clinic. It's one of the largest nonprofit academic health systems in the world. We've got about 65,000 employees and we focus particularly on caring for patients with serious complex and illnesses. My role particularly is in client experience. I work at Mayo clinic laboratories. So, we're related to Mayo clinic. We help healthcare providers support patient care through access to specialized testing. So, before COVID-19 nobody really cared about reference labs. We never made the headline but suffice to say like the little pandemic has caused a lot of noticeable change in our life to work in all of our lives at home. And they medical labs has actually conducted a 1.3 million coded PCR tests over the last few months. So, my work in client experience, frames, the needs and opportunities of our clients. So, in our case, those are physicians and healthcare systems, care teams make sure that their needs and challenges are at the center of our digital strategy work. So, prior to Mayo clinic, I actually taught in graduate school. I was a professor focused on Digital Rhetoric and Leadership, and it's great to be with you all today.
Snjezana Momic: Thank you. So, actually, Adam, we'll start with you. So, how do we work with product teams to keep product objectives aligned with company objectives?
Adam Copeland: Yeah. So, that's actually a hot topic at the moment for us because we're rolling out a new strategy to help keep a company goals and goals of our executive leadership aligned with the goals of our product team. So, I'm going to tell you a little bit about sort of one of the new things boosted up recently. So, previously one of the challenges for us was project team leads with sort of shop around different areas of the company to find a development team that would be willing to take on their projects. And if they heard no and one place, they keep talking until they found you. So, that's didn't work for some obvious product reasons. In the last quarter, we've stood up couple of our calling the digital advisory board. So, I sit on the board and the basic concept because we take executive guidance on the needs of the business some financial constraints the business project goals. And then we break those down into problems for our product owners and scrum teams that they can then package into their backlog. So, the digital advisory board communicates up to executive leadership about status and impediments dependencies and we asked a lot of questions about prioritization and then we also ourselves use an Agile framework and a weekly cadence for our work and we've got that close relationship with executive sponsors and bring them in when appropriate and then sharing out from the product teams. So, far so good. The digital advisory board we're developing a clear path to continuous delivery. That's been as are aligned with our business goals. In other words, what the teams that that's responsible. So, there's an advisory board. We're responsible votes with the executive leadership and the product teams. And every day we wake up thinking about how do we maintain alignment that if anything seems misaligned and we've got a clear appropriate next step to getting clarity. So, that's how we've been tackling that question at the moment.
Snjezana Momic: And how often this actually digital advisory board assembling and making these decisions?
Adam Copeland: Yeah, so we have daily standups and then on Mondays we have an hour-long planning meeting and Friday we've got a retrospective and some share outs. So, that's an hour long as well.
Snjezana Momic: Brilliant. Sorry. That's great. Thank you. So, Pete so while alignment is important, we know that company objectives are more focused on company outcomes, sometimes commercial, most of the time commercial, so revenue and registered users but product objectives are focused on user and customer success. So, the mushing those product objectives from company objectives is actually very critical to happen for the success of products. So, from your point of view and experience in transformations, so what would be the best practice to make sure this is happening?
Pete Anderson: Sure. And so, for me, the thing I always give as a caveat is that there are no two enterprises that are identical. So, looking at these suggestions are from experience. And so, there are things that have worked or things that I've seen that don't work. And so, normally when I'm thinking about this stuff, I'm starting to think about it in three tiers all the time. I'm thinking about the senior leadership layer, the middle management layer and the individual contributor, lower level management layers because I think the tactics have to be different at each of those levels. And the responsibilities are different at each of those levels. Just like I spoke about in the presentation that I gave yesterday. At an enterprise level, I think it's absolutely crucial to make sure that that our senior leadership is creating customer centric goals. And it sounds like super simplistic way to talk about it. But I can use examples from both the retail I worked for and that we were centered on making sure that our customers had personalized product and they could get it any way they wanted to and so ultimately, we elevated the priorities and strategic themes around supply chain and personalization within each of the stores. And so, that impacted how we could basically take those couple of key strategies and overlay it on our product taxonomy. And be able to basically light up the products that would have to do work in those spaces and explore that but those goals while we knew they would drive revenue were truly customer centric goals. We knew that those things had to change and the banking example I would give is that the do it yourself concepts around right now, the US Bank probably has about 56% of the capabilities for our customers that they can do themselves online and so ultimately there is a goal to make it easier to bank with us by enabling those capabilities online. At the same time, I've seen the bank demonstrate. So, I'm pretty old school thinking and that, "Hey, let's try and get wallet share from our customer. So, let's make sure that you're using more products." That's not a customer centric view and that particular strategy is one that I'm not too in love with and that we're trying to coach people through and so if you take that type of strategy, that's a little bit more command and control traditional business metric and drive it down into the team. We use tools like Jeff Patton's opportunity Canvas that basically about two thirds of that conversation that it's basically nothing more than a structured conversation has about nine categories. So, what's the problem I'm solving. Who am I serving? Who has that problem? How do they solve for today? What's the value fixing it? How are we going to measure value from a customer perspective? And then also taking a look at the business lens. And seeing what business problem we're solving with that. And so, by shifting the dialogue from here's eight features to here are the problems that those features are trying to solve helps at the team level and then last but not least, I truly believe that culturally, that the organization has to be aligned around some shared values and some humility around the fact that we can't solve our customer's problems in silos. So, how do we get in front of them and make sure that we are defining the problems to solve and incorporating those into our strategic themes as an organization. So, we'll leave it at that for now.
Snjezana Momic: Thank you. Pamela, from design perspective, how can establish establishing design metrics and creating the context for design help actually in keeping customer in the center of, of happening in the organization?
Pamela Mead: It's a great question. A lot of companies are coming very saved data driven and certainly data and log if you will. Relying on NPS as one of the metrics to evaluate how well they're doing or doing a lot and lots of AB testing to evaluate whether or not something performs better than another. Neither of those are really very good metrics especially NPS for like really say, what's the customer experience and how it, how on target you are really from a product experience perspective. There's a slide in my presentation, we are really looking at first because we're such a distributed team. We're really looking at what do we even mean by a certain amount of quality and design excellence and experience excellence which includes really solving, understanding what is the right problem. We're trying to solve what is really the merchant problem which is that much more research based but then also, how do we really keep a pulse on understanding whether or not we are solving these problems right and we're focusing right now very much an iterative testing and evaluation to get there long before we launch a product. The challenge is that if in the company that really likes data and more metrics based and how can we actually establish some benchmarks from a usability perspective or using different criteria. So, we can have teams focused on both solving the right problem and also solving it well and really getting that dialogue into the culture even though I know that usability metrics in a usability lab setting can have Medi-caveats. And just because you're doing a usability test doesn't mean that the results are necessarily good depending on how you've crafted it, but it does give us a chance to really establish a shared language. So, we can start to really engage with the designers, with the product managers on what to improve, how to improve, why to improve long before we actually launched things in an AB test, or then later evaluate the customer satisfaction. It's a vehicle for us and it does very much put that merchants or the customer at the center of the experience because it really reinforces us to answer the question. Are we solving the right problem? What's really driving our hypothesis? And then it gives us a variety of tools to evaluate along the journey whether or not they're really doing it and doing it well. It's a really good vehicle for aligning the organization around it and it's a little bit more metrics based. It also gets the company on board with understanding of the value of it and the importance of this kind of methodology.
Snjezana Momic: Brilliant. And is there like UX strategy incorporated in this vehicle?
Pamela Mead: It will be.
Snjezana Momic: It's real big.
Pamela Mead: Because I think that was one of the questions on the Slack channels is how does U X strategy relate to business strategy.
Snjezana Momic: I just wanted to die to that question.
Pamela Mead: I think it's very much around, a little bit more about product strategy because the business strategy is really much more it's even broader than that. But it should definitely be in a reflection of it encapsulated and in that regard it ties very much to how do we really through our product experience manifest the brand or the vision of who we want to be as a company to our customers and it starts to give us a bit of a North Star almost on terms of what the quality of the experience could really be. Our strategy will be something that will be expressed in a way that we have our expense that we can touch UX metrics and we will have an articulation that people can understand. It's like where we want to go and it's tied to storytelling. Storytelling is I think really key on how do we make it come to life because I believe we need to not only have design aligned with where we want to go, we need the whole organization behind it. As a matter of fact, I always say the engineers don't care about what we care about. It doesn't matter how great our designs are aspirational we are because it's really one effort. We need to work together as a team.
Snjezana Momic: Yeah. Thank you. Pete, back to you. From your work in helping organizations transform the truly product-based organizations, what are the biggest challenges actually, the teams are facing in the environments where they are not to, to solve the problems in the way their customer love?
Pete Anderson: Sure. I'll try to hit both the problem and the approaches that we're trying to use to tackle them. And we'll see if we can do that in two minutes. So, I'll go fast. But first one, I'm using old processes with a new mindset. We teach the masses on, "Hey, we need to be Agile minded and product thinkers and customer centric and then we're going to have you go through a three to six-month process that we call CapEx to come up with a prescriptive list of things that you're going to go build on a specific timeline." And so, we've done the mistake of putting scrum as a transformative method" is strictly delivery based as opposed to the mindset that's used to actually make decisions about what to build and then we basically tell them to build it faster and be order takers along the way. So, that the things that I've seen that have helped us change that previous company was really just to see one senior leader with a mandate for change. There wasn't an option to do it differently. And it was, all of us are going to go to this method of working. All of us are going to be thinking differently and we're going to measure the outcomes of the work, not just a project plan. If you're absent that leadership then ultimately you kind of have to default back to pilots or proof of concepts or places where you can say, "Okay, if the organization is so opposed to the risk of trying to do this at scale then let's do it locally and prove it and then be able to basically spread the love that way. And that's what I'm currently doing at the bank within our platform space. Another problem is staffing approach when you shift from project to product, you're shifting from temporary teams to essentially permanent teams. Nothing is truly permanent but as close as you can get. And so, being able to flip, if you're over-index toward contractors, being able to flip toward a full timers or people that are going to stick around for a longer period of time and that helps you build an engineering culture, it helps you build domain knowledge and depth of understanding of your customers so on and so forth and I've seen that be just a dramatic change as you've flipped that percentage. Again, target it was 80/20 contractor or a team member that flipped to 80% team member and contractor. And all of a sudden, the engineering culture was able to develop at the company and you see it in their results. Another problem, lack of willingness to tackle the root cause of problems whether it be process-based or people-based or technology based. So, I see some things in my current employer where we kind of white glove our way through the existing processes. And so, you get some iterative gain in being able to go a little bit faster than you could before, because somebody's guiding you through the process. Whereas we really need to step back and be able to say, "Why do I have to white glove through somebody through a process? And still only think that speed is a quarterly release or a monthly release in some cases." How can I basically change the process itself? So, it doesn't need somebody to guide you through it. It shouldn't be that complex. Team size is another issue that we have because of the lack of willingness to hit root cause and so you end up with six different roles from the business. And a two-pizza team would have to be like a pizza the size of New York in order for us to do some of the stuff that we do. So, we've got teams of 20 or 30 that we're calling a scrum team because of have issues with roles and responsibilities and fear of missing out so on. And then last but not least kind of the frozen middle or fear or lack of trust is kind of how I talk about it in that the folks like myself that are middle management oftentimes don't know how they're going to add value if they're not directing somebody or managing somebody versus empowering someone. And so, for me, that's a lot of where our coaching crew comes into play. I lead a team of coaches and scrum masters, and we do a good bit of executive coaching on, "Hey, your job is to really provide a crystal-clear vision for where you're headed." To hire really good people and then to put in some ways of working structure that enable them to go succeed on their own. And then ultimately, you're supposed to get out of the way. And so, we're also looking at redefining some of the roles and incentives from an HR perspective as well. So, a lot of stuff but those are the key themes that I see.
Snjezana Momic: Thank you. It's shifting projects to product teams is very important and relevant. I think for most of the organization from there. Adam, we heard that old process with the new mindsets from Pete, it's not really something that is actually a good practice. With this new organization, how do you help your team factually shift from project or features to product organization?
Adam Copeland: Here's, how I think about for us in the healthcare space and I hope the audience see that I can take that perspective to their own environment. In healthcare, obviously it's incredibly complex space. There’re disconnected journeys, diverse human needs, and then dozens of touch points along the way. But when it works right, healthcare is always about the patient or the patient always has to be central. That said, to support the patient you need an overwhelming amount of data. There’re tests, their levels, patient history, medications, more tests. Much of what we're doing it in every clinic and labs going straight to the patient bedside because the data we feed in affects real change for the healthcare team. But on another level as that much higher level, what we deliver is data. So, lots of data. So, to get to the question of what we started thinking about at the labs in large part sort of conceptualizing ourselves as a data company so if that's true. The product is the data and it's the tests, the results, the diagnoses, the turnaround time and the predictive capabilities that's where we can build onto that data. So, then for us, any project is really an iteration or a feature of that bigger basic data product. So, it's about how the data is delivered or about making a new subset of data available in a way and a new way. So, finally this is super important, right? While the data and the human expertise are interpreted is what we provide. The patient always has to be at the center of our story, so this is echoing in our catalog, right? Ultimately, there's any project or feature that we helped stand up it's for the benefit of the patient's bottom line. At every level of the organization, we've got to tell that story of how the patient is being benefited by probably be working out together and telling us story helped us keep focused on the right thing. And it pushes us to faster, greater, more innovative solutions because the patient is at the center of the work.
Snjezana Momic: Thank you. Yeah, thanks. And maybe Pamela from design perspective, if we get to this true product-based company, so what are those attributes that we are actually looking in modern product designer?
Pamela Mead: I guess that can be a long answer. No, but actually it's a really great question. So, I think part of what we're talking about in doing moving from project to product really is for you to have a better designer. We talk about this magic triad and in theory, at least Agile and the squats and the much more collaborative teams of the magic triad or it should be the manifestation of this collaboration that can really lead to this level of agility and constant product developer and then evolution and then that's role, the modern product designer really needs to be much more holistic in addition to having an expertise, which I generally see in product design as being more closely on the UX side, they need to be able to at least understand enough of the business context to know what questions to ask and they need to have enough technical sensitivity to really also engage with the engineers. And that's really where a modern product designer would really be able to Excel because they can partner with them as peers and really work together. That's the ideal of the realities is quite different. Most of the time when the triad doesn't really quite work that way. Sometimes it's because of organizational structure that the product designers are much more tied to product managers, but they're not really collaborating with engineers too in the way that can really be just some of these really amazing breakthrough or fast kind of solutions the other thing that I've seen happen is that we've started to create this mythical magical product designer that's a unicorn of exceptional qualities that can do everything that we would never ask a front end developer to do from writing UX copy to doing research, to being able to do the great flows and then also be able to create pixel perfect iconography. And this is what I was talking about in my presentation that I just don't think is real. I'm really coming back to one of the roots which is a UX designer who's really steeped in their understanding product, not just a feature really knows what are the questions to ask and they can really work off of strength. But they can start to have a conversation of what are the additional skills that I really need to be to really feel great experience to start to manifest. And that dialogue can instruct to really shape actually the organizational structure back from, "Yes, we all tribalized or in squats or in teams into what are the additional skills that we really need and I think that is where a company or organization that can understand it really can strive towards this excellence. Otherwise, I see and I've seen in some of the companies I've worked for with the quality of experience moves more towards the lowest common denominator of what are the skills that people have and the seniority and the understanding. So, I don't expect a truly modern product designer to be an amazing and everything but I think being really, really strong in this business engineering problem solving, UX space and then really know where to bring additional expertise and to make it really great. I think that would be really powerful.
Snjezana Momic: Great. A little bit about strategy, Pete, for yourself so what's happening in the intersection of enterprise strategy and the product organization today and how do you see that will develop in the future?
Pete Anderson: Sure. It'll basically be what I've seen in what I would like to see whether or not it's the right thing would be a hypothesis. But what I've seen is that in large enterprises at least, enterprise strategy is a separate group hunting for ideas within a silo and when they find something that is successful, they often struggle to operationalize it and deliver it through the product organization because they're disconnected and because a lot of times during transformation where we're basically taking a delivery arm of the company and asking them to be strategic in the concept of product but we haven't quite enabled them and empower them to do so. And so, what I'd love to see in the future is products play a bigger and bigger role in innovation for the capabilities that they own and have it just integrated into the product accountability or if it's still separate established routines to stay in touch. So, one of the things that we've done at both of the 421-25s that I've worked with has been a quarterly demo day, which is basically normally it's about a third to half of the product teams in the organization sharing what they've accomplished over the last quarter and where they're headed. Just that act of pausing every single quarter and talking to each other, unlocks a lot of different connections that you wouldn't get otherwise. It seems again, overly simplistic but the vast majority of transformation is about conversation. And I think it's the same thing with strategy and product. How do I set up environments for them to connect with each other, align their strategies, align the work that's coming up and go from there? And then the only last note there is that in an appropriate world in the same way that our OKR should be kind of tops down and bottoms up to land someplace in between, I'd love the enterprise strategies to be influenced by what the product teams are learning. And so, in those cadences of connection, I also want senior leadership in there to be able to hear what's being learned on the ground so that their strategies are impacted from above and hopefully that makes sense.
Snjezana Momic: Those are really important. Yeah. I actually have to wrap up. I am sad actually because there is so many topics that I wanted to address with you today, but this was the brilliant discussion. There’re some questions just popping up for me but I guess we will have to address them via Slack later on and our panelists will we'll do that for us. So, just to wrap up, we discussed magic triad, we understand the importance of a truly good collaboration within the triads but there's also this importance of having customer or patient in healthcare industry always in the middle of that and just start from there. When you need to resolve the tension between product and organizational objectives and try to start your conversation from there if there's maybe not tension maybe just not enough conversation. So, I think that would summarize what we wanted to say today. So, thank you so much all.