Product Prioritization Using Design Thinking

Soumya Raju at UXDX Community: Online. Video: https://youtu.be/WjNirSh_dQI

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

Introduction and my background

[00:00:00] Hi everyone, thank you for joining me today. I'm excited to be able to share the next 30 minutes or so with you all. As Rory stated, my topic for today is product prioritization using design thinking. Prioritization is an important aspect of our day-to-day work, especially if you find yourselves in this situation of everything is top priority and there's so little time to get everything done. So in our session today we'll look at ways in which we have data-driven rationales for our prioritization decisions.

[00:00:47] So we'll get into that. Before we begin, just a little bit about myself. I'm Soumya. I am a senior manager of product at Discover Financial Services. I'm based out of the Chicago area, Chicago, Illinois, well actually the Northwestern suburbs of Chicago. My career journey, it's been one of a few transitions. I don't know the background of the folks in the audience today, but I'd guess that you are product professionals, and perhaps your journey has been one that's similar to mine.

[00:01:33] So I started my career out as a software engineer. I held that role for quite a bit before I transitioned into infrastructure solutions architect. After that I moved into the product space somewhere in 2017. When I first started out in the product space I primarily worked with data analytics products, and I've been in that space since then, although the products that I work with have changed.

[00:02:04] So currently I am responsible for creating product strategy and design solutions for content creation and delivery to our internal customers at Discover. What I've observed or noticed is that my technical background comes in quite handy in my day-to-day, especially when evaluating the feasibility of the design solutions.

Setting the stage: what product prioritization is

[00:02:34] So let's dive right in, to set the stage here. When you think of product prioritization, it's about deciding what products, features, capabilities should the product teams work on first. Or in other words, it's determining which teams' initiatives, features should get slotted into the product roadmap. So Discover's approach to digital transformation starts with an emphasis on maximizing value creation and value delivery for our customers. Our belief is that we create more business value by prioritizing the work that matters the most.

[00:03:28] Now generally, product prioritization, it involves a delicate balance of various factors, factors ranging from market conditions, you may have stakeholder expectations, customer needs, customer feedback, technology considerations, just to name a few. So how do you effectively integrate all these facets into the prioritization process? Due to the rate of change in the factors that I just mentioned, continuous planning and prioritization have become a key part of the new way of working. So this focus on prioritization coupled with the business value that we are striving to achieve will help ensure that the right work is done at the right time, for the benefit of the customers and the company.

The DVF model: desirability, viability, feasibility

[00:04:30] We talked about all of these different factors that go into prioritization decisions. So where do you start? What is a good place to start, especially if it involves integration of all of the various factors that I just touched upon? So a good starting point is to leverage the DVF model, the desirability, viability, feasibility model, and ensure that the product that you are planning for should indeed be pursued. I'm sure you have all heard of the DVF model. So IDEO, which is a global design company, they conceptualized the DVF design thinking methodology in, I want to say, the early 2000s.

[00:05:19] So if you take a look at the three domains, the D, the V and the F. Desirability, it's about the customers. Will this product fill a need? Will it fit into people's lives? Will it appeal to them? Will they actually want it? So that's desirability. We'll dive deeper into each of these domains. Viability, this is about alignment to business goals. So things to consider: will the design solution align with the business goals? Does this solution honor the client's budget? What will the return on investment look like? Feasibility, this is about: is the technology needed to power the designed solution available or within reach? How long will this take? Can the organization actually make this happen?

[00:06:18] So we aim to bring all these three domains together in prioritization. What this will do is this helps us take a broader view into prioritization. At the same time, incorporating all of these three different domains into our decision making will put us on the path to still be able to innovate and keep ourselves relevant in the market. So let's take a look at the inputs to consider for each of these domains in the following slides.

Viability: vision, mission, goals and OKRs

[00:06:57] So let's start with viability. As I said earlier, this is about alignment to business goals. If I think about it, every organization, they've got a vision and a mission that they're striving for. These are important foundational elements which in turn help influence goals and strategies for execution, that then turn into objectives and key results. So the visual that you see is trying to show that interconnectedness between all of these different elements, the vision, the mission, the goals, the strategies, the OKRs, which should manifest itself in the prioritization process.

[00:07:50] So I know I said OKRs, objectives and key results, so just a quick recap, I'm sure you all know. Objectives, they are about the strategic focus and they answer the question of why. Typically they're qualitative. KRs, key results, they measure success towards the objectives in terms of outcome, and they are quantitative. So what OKRs do is they help with alignment and focus, as depicted in the visual. So the important thing to note is it's a measure of business results, it's not so much the output or the tasks.

[00:08:28] As you are involved in prioritization, as you go about your prioritization process, think about how the goals and OKRs manifest themselves in the prioritization process. So when deciding what work to prioritize, incorporating goals into the decision making process will ensure that the viability of the product or feature has been taken into account. Things like, is this product profitable, what has the market research indicated, things of that sort. So this is one way of thinking about the viability domain, and how you think about the data as it relates to this domain that needs to be incorporated into your prioritization process.

Desirability: personas and journey maps

[00:09:20] So moving on, we'll look at desirability. In the DVF we've talked about viability, we're going to take a look at desirability. So another input you would use is your persona, to determine the capabilities and the features that go into your product. By the time you've got to this point you'd have already done your research to identify who your customers are, what are their needs, what are their wants. You then use this information to build your customer and stakeholder compass perhaps, and to also help build your personas.

[00:10:05] So if you've identified multiple personas within the context of this particular product release, then you prioritize them. For example, if I were to draw a parallel to my day-to-day, as I think about content creation and delivery for our internal customers, we have identified a few personas, such as the ones for an engineer, one for a product professional, one for leadership. And we prioritize the persona for who we are building that particular content for. So essentially it's prioritization of personas based on outcomes and value.

[00:10:59] If you are a visual person like me, and if you imagine this view of concentric circles radiating outwards, the innermost circle would be reflective of the primary persona, and then you'd have the secondary and the tertiary. It does not mean that the secondary and tertiary personas are not important. However, based on the value and the outcome we are striving for within the context of this particular release, who should be front and center? So that's how you'd incorporate one element of the desirability domain.

[00:11:42] Customer journey maps. This is another great way to understand the desirability dimension better. Journey maps, they are a strategic approach to better understand customer expectations. It's a visual storyline. When you have created your journey map and gleaned whatever valuable learnings it offers about your customers and your process, you want to make these learnings actionable. Otherwise what's the point in having all of those learnings? And so a way to make these learnings actionable is to incorporate them to support the strategic decision you have made during prioritization. So this is another way in which I found it to be helpful, to really prioritize based on the value that we are seeking to achieve.

Feasibility: product life cycle and context

[00:12:48] All right, so we'll take a look at feasibility. In the DVF we are now focusing on feasibility. When you think about feasibility it's helpful to understand where we are in the product life cycle. How do you prioritize what goes into your roadmap? Your roadmap should have a direct correlation to where you are in the product life cycle. For example, if your product is in the growth phase, this helps us assess how much of the roadmap should be new features versus tech debt versus bug fixes.

[00:13:35] So the value of any feasibility analysis depends on the context. So it's context-driven feasibility. What happens is there are good practices in context, however there are no best practices, and the reason being, over time things may unfold in ways that are not predictable. So within the context of this product release, what factors need to be considered first?

[00:14:11] I'll give you an example. Let's say one of the most important elements for any product release is to evaluate potential risks. So what are internal or external factors that could affect your product or feature's success? How do you mitigate them? What are the contingency plans? So when you determine that that is perhaps an important factor to consider for the feasibility analysis, your study. This actually is from my own experience as well. When we did feasibility analysis on one of our immersive learning content designs, we were exposed to this obsolescence risk. Obsolescence risk is nothing but the risk of something becoming obsolete in the near future.

[00:15:07] So we were working with some teams, these are infrastructure teams, and so the risk of something going out of support or becoming obsolete is an important feasibility element for these types of teams to consider. I could go on and on about that case study, but regardless, I think you get the point. Context-driven feasibility is important, because otherwise you'll just get lost in the different factors that you'd have to consider for your decision making. So you can use various tools and techniques to collect and analyze data for your feasibility study, such as surveys, interviews, prototyping, testing, etc.

Bringing the three domains together

[00:16:05] All right, so here is a summary of what I've shared thus far. So we have the user needs, alignment to business objectives, feasibility. I said technical requirements, but there's a lot to it. Now, is one of these domains more important than the other, you may ask? Ultimately it's a balancing act targeted at business value. My personal preference, and others may do it differently, I like to start with viability, because these are about alignment to business goals, and validate alongside desirability and feasibility.

[00:16:49] The important thing is to account for all three domains and the inputs that I just walked you through as it relates to each of the three domains. So how do you do that? There's many ways. It could be planning sessions that include the business, the UX folks, engineering. There's just various ways up the mountain. Once you have evaluated each domain separately, you can bring them all together to get a well-rounded view of the likelihood of success for each product or feature. Once you have all of that data you can use any one of the prioritization frameworks to help you integrate this data together and decide which features to focus on first.

[00:17:42] So this holistic approach towards prioritization, it's helpful with focusing on the highest value work. In this session we don't have the time, I certainly didn't plan to cover the prioritization frameworks today, but do drop questions in the chat and we'll try to get to them.

[00:18:06] So really I want to leave you with the quote by Steve Jobs on focus. It's a pretty popular quote. He says, people think focus means saying yes to the thing that you've got to focus on, but that's not what it means at all. It means saying no to the 100 other good ideas that are there. So you have to pick carefully. You have to have a targeted approach, however still all-encompassing as it relates to the three domains, to be able to make informed prioritization decisions and have data-driven rationales for your decision making, as opposed to just a hypothetical guess, or trying to address all of the things on your plate at once. So I want to thank you for taking the time to join me here today. Feel free to connect with me on LinkedIn, and I want to definitely leave us some time for Q&A as well.

Q&A

[00:19:25] Rory: Excellent, thank you very much, that was a nice overview and kind of deep dive into the three core assumption categories for different products. Brilliant. So as Soumya said, please do, if you have any questions, write them in the chat box in UXDX or whichever platform you're watching this on. But I'm going to kick off the questions, because one thing that I've been reading a bit recently, and Teresa Torres just posted about it, was there's five categories for how to break up assumptions. So obviously the three that you just mentioned, desirability, viability, feasibility, but she added in usability and ethical categories. So what are your thoughts, or have you read about that, do you know about those ones, and what are your thoughts about those extra two categories?

[00:20:20] Soumya: Yeah, thank you for the question, Rory. Brilliant, I'd say brilliant, just a specific call out in terms of the two additions, because sometimes some of those elements may be implied within the broad category of DVF. So I like that it's further called out. And I'm very familiar with Teresa Torres's work, and I try to keep up on sort of how she goes about further distilling some of the best practices that are out there. It's certainly something that fascinates me and I think that's really awesome. Yeah, actually, to answer your question about have you heard about that, I have, just at the surface level. I haven't really gotten into a deep dive of that.

[00:21:20] Rory: It's actually one, I'm on the fence on the ethical one, because I think there's a risk. The concept of the ethical one is that you have to think about what could go wrong. So the way social networks lead to these social problems we're seeing, Uber could potentially lead to increasing traffic and pollution in certain cities. So there's the kind of, should we do this? I'm on the fence on that one because I have a feeling it could lead to a lot of navel gazing and people thinking, oh, we could have all of these millions of things go wrong that might not actually happen.

[00:22:02] Soumya: I see, interesting. Yeah, that's a great call out. Certainly something to think about for a follow-up session.

[00:22:10] Rory: Brilliant. So next question is on viability. So you mentioned about, okay, so you've got your mission and then you've got your annual and your quarterly and all of that kind of the cascading down of the objectives. What do you do if you're a junior level person and you don't really have visibility of that? What recommendations would you give to somebody?

[00:22:38] Soumya: Yeah, absolutely, happy to take that one. So I say this during our immersive learnings all the time: I highly encourage folks to ask clarifying questions. It's all about assessing the need for the work that we are working on today, and it is a good practice to always ask those clarifying questions in terms of understanding, okay, we're really good at delivery and execution, what does that sort of ladder up to, what's the broader vision that we are going to achieve as a result of delivering this work?

[00:23:21] Soumya: So a great way to phrase that is something to the effect of, I'm really excited about the work that we're doing, can you help articulate for me how does this ladder up to our larger vision, our product vision, does this align to our product strategy? So I think just a simple question like that will actually open the doors. And maybe the person you pose it to may not have the answer, but they'll certainly point you to someone who will be able to open the doors there in terms of what the work that you're working on ladders up to.

[00:24:04] Rory: Brilliant. And the next one: when you were going through the desirability and you mentioned personas, and you mentioned thinking about it from the persona perspective, what would be valuable for them. How do you avoid falling into the trap, which I am very guilty of, of kind of going, oh, of course this persona will love this, without then validating and backing it up that they do?

[00:24:39] Soumya: Yeah, so that's a common pitfall, as you stated, because we're not designing this for ourselves. And I myself am guilty of that as well, because within the context of my current role I've actually had the role of a product professional who I'm designing the content for. So it makes it easier to fall into that pitfall, really.

[00:25:10] Soumya: And so we are big proponents of validating our hypothesis, and so we have a lot of voice of customer techniques, which we then also have ways in which we validate and ensure that the design solutions that we are designing are truly for our customers, or in this case, truly are for the personas that we've identified to be front and center for our immersive learning. So we certainly tap into those tried and known techniques of validating the hypothesis we have.

[00:25:53] Rory: Excellent. Yeah, so it's not a case of just assuming, it's go out and actually do the work of validating.

[00:25:59] Soumya: Exactly, yeah. It's definitely an extra step but it is an important step, so that we don't discount the power of having access to our customers, so that we are able to validate, or invalidate if that's the case.

[00:26:28] Rory: Brilliant. And then I just have one last question, because you teased it, you asked me about the prioritization framework. So is it MoSCoW, is it FIFO, LIFO, is it cost of delay? What's your kind of go-to, or do you have a go-to framework?

[00:26:47] Soumya: We do. So our company is a big company, and within Discover in different pockets different frameworks work best. So we have quite a few folks who use RICE, the R-I-C-E, which is an objective weightage scoring system for then just incorporating all of the data that you've gathered into the prioritization decisions. We have MoSCoW in certain pockets of the organization. I've also seen WSJF used quite a bit, and in very small pockets, nevertheless, I have also seen buy a feature framework used as well.

[00:27:36] Rory: Great. I've never heard of Mischief before, that's a new one to me.

[00:27:43] Soumya: WSJF, and it may have been my way of pronouncing it. Weighted shortest job first.

[00:27:50] Rory: Okay, yes, that makes a bit more sense to me. I thought there was a new framework that I wasn't aware of. Brilliant. Well, I think, just checking if there's any other questions, but I think actually that brings us to an end. So I just want to thank you once again for sharing. I really enjoyed the session and I hope everybody out there did as well.

[00:28:15] Soumya: Thank you so much, Rory. Thanks everyone.