X Marks the Spot - Finding Hidden Gems with Project Discovery in 5 steps

Tadeh Hakopian at UXDX Community: Rapid Discovery. Video: https://www.youtube.com/watch?v=23fwiOO_pW4

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.

Why skipping discovery costs you

[00:00:08] Tadeh: How we can use project discovery to better ensure our products and features are what they need to be. Let's get started. A quick little agenda here: we'll go over the concept in a few steps and then recap based on that.

[00:00:27] A little bit about me. You can call me Tadeh. I'm a program manager, and I do a lot of work with just about everybody in my organization. We work on renewable projects and products, anywhere from the hardware side to the UX side, and I work with the UX people, the product teams, the engineers, marketing managers, directors, consultants, you name it. As a program manager, it tends to be that you're across the verticals with everybody. I've worked both in remote and in-person scenarios over the years, and I realized that sometimes you miss your mark even when you have lots of good resources available. This is a little bit about my perspectives on using discovery to better ensure you get what you need.

[00:01:16] Let's start with the basic premise: what is discovery? One definition is that it's a phase to help you test your idea and market fit and determine what the next big thing is, the potential. Another benefit of using discovery is being able to find out what you have and what you don't have, and knowing the landscape of the challenges ahead of you. For example, I've started on projects where we were in a remote environment, and you only know what you see on screen with calls and emails. You don't really get to see the layout of what's available historically.

[00:01:54] You might be working on a new feature or product and you feel pretty confident. You feel like you're an experienced professional who can get work done, you work with other smart people who are themselves capable, and you feel confident in getting the project moved ahead. However, you may not have the standard operating procedures and workflows established, and you think, okay, we'll sort that out. We don't even have everything labeled for us, but that's not a big deal, right? Just figure it out and fly. Well, I've done that more than a few times, and more than a few times I've had my regrets. Why? Because you might be able to move things forward, but you might be missing the mark the entire time.

[00:02:33] I've learned not to skip the discovery phase for the sake of brevity and convenience, both for the potential benefit of the product and for teamwork, but to really dive into it and make some use of it. This is what I've experienced going without the discovery phase. You have a never-ending scope. You're not 100% sure what has to be done, when it needs to be completed, what the requirements are, what the end goals are. You have a vague idea; perhaps you think you had a good idea, but then it switches.

[00:03:08] You miss deadlines. Why? It was a scope where you don't know what to do, things get drawn out, the schedule is affected, and you may have to add new features and ditch ones that you already worked on that might be complete but not adequate. That's always fun. Even when you get things done, you may have a product nobody actually wants or needs, which sucks. You didn't design something that meets the target audience's needs and requirements. You did all the work, you got things done, but you missed the mark, which is an important waste of weeks, months, maybe more time.

[00:03:42] And of course we waste time repeating our work. We don't utilize our existing resources and people adequately, because we may not realize how much of that work might be available to us already. Maybe somebody knows how to solve a problem we're running into. Maybe there's documentation out there that we don't have to repeat; we just use it. It's there, but we don't know it's there.

Validating the idea with five steps

[00:04:05] You want to start by asking the right questions to avoid these detours and dead ends and missing the requirements and having these bad experiences. I've had my fair share. How do we untie this knot? Is there a straightforward way of doing this, to figure out what's a good fit for the market, but also how to make best use of our time? There is, and we'll dive into that based on my experience and also training I've done.

[00:04:33] Just to be clear, the reason we need product discovery is that it allows you to validate the idea. Instead of using your assumptions and what you might have heard, you validate early and often, you get good information, and you get on the right track. The way I start, the way I make this as easy as possible, is instead of necessarily diving into new things, which you might need to do, try using your available resources. Even if you're a one-man show and you work with consultants, you're part of a small team, or you're part of a large organization, there's usually something out there that you can find if you ask the right questions and look for the right resources.

[00:05:13] I put this together in a simplified step format for having things organized to be on the right track, defining your target audience and getting your business goals. These five steps are scope, availability, timing, gatekeepers, and a fifth element that we will reveal at the end.

Scope

[00:05:36] Let's talk about scope. Scope is as simple as: what are we working on, what are we going to do? It's a big question. What should you do? It seems obvious: prototype something, get things done, release things. But there might be higher priority objectives and lower priority ones, meaning you may have a lot of ideas of what you need to do, but what's the important thing, what needs to get out early enough? Figuring this out is a good determinator of what to do next. I've been in situations where I had a lot of scope, but I didn't realize what needed to be done first or what the actual imperative was.

[00:06:14] A simple way of getting out of this is just to create a simple outline. Figure out what is necessary in the project, create a checklist, ask about timeline, budget, tasks, the stakeholders involved, the strategy and workflows that you need to address. Again, you don't have to make this an exhaustive list. This is just a good starting point to figure out what you need to get started on, and it's as simple as asking a product manager, project manager or product owner to help you with this, someone who can give you some resources if you don't have all the answers. But it's good to list these out so you don't take things for granted.

[00:06:55] I recommend, once you have some of this information in mind, map out the scope. Where to start, where are the critical paths, what leads to decision making? Because again, not everything is flat. Not everything is going to be as obvious as you think it is. Even if it is for a simple release, you might be in a new team, it might be a new environment, you may not know exactly what to expect. It's always good to map it out and not take that for granted, and figure out the decision-making process.

[00:07:23] In this example, what feeds into the scope management? Is it existing plans, charters, the organization, what have you? Once you compile that, you can then figure out where to go next, so you don't take things for granted. Again, it might seem very linear and very to the point to the individual, but in a group setting there might be many steps involved, there might be existing protocols. Don't take scope for granted, because that ends up being your work, and if you have scope creep, if you have too many things on your plate, this can get out of hand real quick.

[00:07:55] Once you've figured that out, the next simple step is to get on a call and talk to your team to get help on the information and requirements. It's always good to just reach out: chat, message, video calls. This leads us into our next topic, availability.

Availability

[00:08:15] Availability is simple: what do we have to work with, something that is tangible? What do we have, what's on hand now? A list of features, actions and things we can work with. Do we have a project schedule, project staff? Do we need product specifications and budget plans? It's also good to ask what we don't have, and of course what we want to avoid: scope creep, and bringing in new people without onboarding them if we already have a lot on our plate. It's good to ask what we have, what we need and what to avoid. It's always good to make sure you know what's in your scope and availability.

[00:08:53] The way I start this is to start with your team. Your team, in my opinion, is like its own little network. Even with a small team, everybody has a little network of what they know, the resources they have available, the information they have on a tribal level based on conversations and chats they have with other people. That could be a great resource when it comes to discovery. You could talk to people like project managers, the UX designer, the product owner, the software architect. These are all valuable resources.

[00:09:23] There's nothing wrong with getting on a call with any of these people for five, 10, 15 minutes or more and asking them, "Hey, what have we got?" Because you want to figure out that scope. Reach out to your network internally, and these could be consultants or people on the client team, and just ask. There's nothing wrong with asking a few simple questions to help you along the way, especially when you're in a hybrid or remote model. It's best to ask around so you don't take things for granted. Again, it's easy to think that what you see on your screen is the truth, or the emails you get and the whole thing, but it wouldn't hurt to get things started the right way by asking actual human beings a few things in the discovery phase.

[00:09:58] Every team is part of a larger network, so you might be led into talking to other people from recommendations on these calls and interactions, which is a good thing, because what we're trying to do is just talk and find good information, but also get resources and documentation. For example, you want to get the meat of discovery, which is things like user stories, documents, workflows, information, things you can actually use. But more importantly, things that are valid and not out of date.

[00:10:32] You might have, for example, a user story with lots of stages to it, but it may be inadequate. It may be very much a prototype, it may have no bearing on the work you're doing, or it needs to be updated. These are the kinds of context you want out of the documentation: to have the documentation, and to also know what is useful and not useful about it.

[00:10:54] Also, if you have something like documents you need to fill out, instead of having a blank document, like a user persona that needs to be worked on, perhaps somebody already has it filled out. You have lots of user personas that are relevant to the product, or at most they need a little bit of tweaking. This is the kind of thing that will save you a lot of time. We talked about repeating work: you don't want to go and do all these documents yourself when you already have them available to you. Maybe the UX designer or product owner has a lot of great resources available.

[00:11:25] Now, this might seem darn obvious, but I've been in situations where we worked on comprehensive products and features where we had to do a lot of this stuff, assuming that it wasn't available to us, when it turns out it was actually documented in the past and was still valid. You don't want to end up in a situation where you spend extra time doing something that's already been done and repeating this stuff.

[00:11:49] Likewise when it comes to fundamental research. Do you have to do it yourself, like this product market fit canvas? Do you have to fill this out yourself, or has somebody already done this for you? Maybe it's from a similar product that was done in the past, and you just have to modify it. Again, it may be valid, it may need some hand holding, it may need some walkthrough to get the most logic out of it, but you don't want to go into everything assuming it's a blank canvas and you have to figure it out yourself.

[00:12:21] How much documentation can you find? Where is it? Is it valid? Does it need to be worked on? You may end up with a really cool thing like a playbook that can help guide you through user stories and what's been reported, what people are interested in. But don't stop at just the UX documents and guides. Do a deeper dive. If you have things like product architecture and software, go talk to your software engineers and ask them how it fits together. It helps to understand how a product comes together in the back end. Maybe that gives you some ideas about functionality and the feasibility of doing something.

[00:12:57] Is everything in wireframe mode? Is it a complete product that only needs to be expanded upon? These are good questions to ask, so again you don't end up missing relevant context for the next release, relevant information on what it will take to add a feature. Is it ready to go? Has it been tested? What is the life cycle and product review from the software side? It's good to ask these questions.

[00:13:20] Once you have these documents together and have talked to people, I'd recommend putting a simple table together so you know who provided what for what reason. Your product manager could give you some research and strategy, your software architect could give you some technical information as well, and that way you know where to get your resources. It's a good way to cross-reference. A good rule of thumb is that the more boxes you check off here, especially across different groups, the more relevant it is, because you have lots of comprehensive cross-checking and review. If it's only spotty and you don't have enough, that's a sign that maybe you need to either find more documentation, or it's justified that you create it yourself at that point. This is a simple thing again: what's available, asking people, getting some good references going.

Timing

[00:14:14] That leads us to the next phase: timing. Time is a valuable thing. If you don't have time on your side, you're not going to have time to finish your project. A good question to ask is: what is our timeline? What do we do first, what takes priority? Again, not everything is flat. What are your product requirements? Then what are your milestones: are we trying to release a prototype or a full feature? What's the next big thing, and what's the long term? Maybe the release cycle is long term.

[00:14:44] It's good to ask this because time gives a sense of urgency. If you can find out a good timeline, or the way people manage time in your organization or your client's organization, you can easily find a lot of compelling guidance. The golden nugget here is the product release management cycle: how something goes through different stages, from planning, scheduling, controlling, testing, deployment, and then review and planning for the future.

[00:15:21] Determining the right requirements in the release management cycle goes a long way. This might seem more of a concept than an actual planning document, but if this is something your group or your client adheres to, it's invaluable, because you get a sense of what their rubrics, heuristics and protocols are. You know that maybe it's only a few steps along the way, or it's a lot, and you have a sense of how thoroughly you have to go through the steps in order to release something in a timely and appropriate fashion.

[00:15:52] If you have some kind of more strategic guidance like a release cycle, that can really help you communicate to a broader audience and team to make sure you're doing the steps the right way, and not just gunning through everything all at once, because you may have to back up, review and repeat some work. Try to see if you can find some kind of guiding document for timing, like a release cycle.

[00:16:15] What's just as good on a more finite scale is a product roadmap. What I like about this is that it's an easy document to communicate. It gives you a sense of what the product is, what kind of features are being released and when. A lot of products have these online as part of their long-term roadmap. You can find these on things like a kanban board or a GitHub repo, and it'll tell you what's coming along the way.

[00:16:47] Again, these are sometimes more driven by expectations and not actual deadlines, but it's easy to follow and gives you a sense of what's possible. This is usually a useful enough resource that you can find different parallels and swim lanes, with, in this example, a mobile app versus the customer-facing dashboard versus automation systems. It gives you a sense of what's downstream, what's upstream, what needs to get done up front and what can be a long-term play.

[00:17:18] You'd think I would have done this myself. I've been on projects where we had product roadmaps and I thought it was just graphics. I didn't think it was valid, and sometimes they might just be for marketing purposes. But later it turned out this was pretty well thought out, so it actually helped me understand when a release was coming, what I should pay more attention to early on for the users, and what was downstream because it was not going to be ready anytime soon. Product roadmaps can go a long way in your discovery phase to figure out what needs to be done first, for which swim lane and which scope.

Gatekeepers

[00:17:57] From there, we talk about gatekeepers. We did all the research when it came to scope, availability, resources and timing. This is an important, more social aspect of any organization, which is gatekeepers. What I mean by that is: who controls access? Understand the culture, how the organization operates, the culture and the decision making. This may not be obvious right away, but again, this is something you can actually figure out real quickly. How are things approved? Is it through a single gatekeeper? Is it through consensus? Does it require testing and feedback to get approvals and information?

[00:18:40] These are things that go a long way. If it's a single person approving everything, maybe just go talk to that one person and ask what's important to them. If it's a consensus-based thing where you have to have multiple people agreeing on things, it wouldn't hurt to see if you can get on a call with them, maybe sit in on their calls and see how they operate together and understand their interactions. Because then you can understand what's important to them and how they speak. While the documentation and roadmaps and scope are great, sometimes it only really comes together in an organic setting where people really communicate with each other.

[00:19:13] I would say try to find out if that's the case. Learning how these decisions are made will help you get a grasp on how things are processed in the company. This is more, again, organic, tribal, people. But one hint I can give you to help you along the way is to find out what the hierarchy and org charts are. That might give you a sense of who the individuals and the teams are, and there are a couple of different scenarios we can look at here.

[00:19:42] One org chart is where you have multiple teams of designers and owners going to one product manager, where you know that person's the gatekeeper. Everybody has to report to the product manager no matter what the feature is, so the product manager has a lot of grasp and latitude. It'd be good to talk to the manager and talk to the teams and figure out more finely what's going on.

[00:20:04] What's perhaps more common in smaller or distributed organizations is a distributed staff of UX designers, where you have maybe one person involved in multiple groups. The staff themselves in UX aren't necessarily all in one team; they're part of multiple teams. That might mean more collaboration, more talking, and things might get lost on the cutting room floor, which is good to be aware of and note. That might be something you run into where you have multiple product teams and people distributed across them.

[00:20:44] Or you have UX taking the lead. Maybe it's a UX-driven group, maybe it's early stage, or probably a late-stage product release where the releases are more fine-tuned, and you have the UX professionals leading the way when it comes to how these releases are managed. You might have a product manager at the top, but a lot of the back-end work feeds through specific people. Figure out how your team and your organization are managed. Again, it's easier if it's part of the same company as you, but if it's outside facing, it wouldn't hurt to ask who somebody reports to and where the decision making goes.

[00:21:23] One easy way to figure this out is to just use your internal software. A lot of productivity software these days has org charts built in. This is an example from Microsoft Teams, the messaging platform from Microsoft Office. You can actually click on somebody's profile in Teams and, assuming the management structure is organized, which usually it is, you can figure out all their reports and who they report to. I've used it myself to figure out who would be a good source of information to talk to in a given engineering team or product team.

[00:21:55] This might be possible, I believe, in Atlassian products and other products from other companies that have these kinds of team workflows. Try to see if you can just find the reporting structure in software that you already have available, and again, it's always good to ask. But this has been a convenient way for me in my organization. I use this software to find out who is in charge of what and who they report to, and this is a great way to understand the decision-making process and the reporting process.

[00:22:27] A couple of key questions to ask to figure out how decisions are being made. How does your organization actually make decisions? Does it require some kind of process? Are different parts of the company making different decisions? Does it have to be a handoff? Maybe a feature is approved and it goes to software to figure out if they can actually build it, and then marketing has to figure out how to market it. How does this go? Is it a clearinghouse or is it a handoff?

[00:22:56] What are the executive decisions? What decisions lie with the design team? Does the design team have a lot of discretion, and what are the bases for making those kinds of decisions? You might have multiple different ways of answering these questions depending on who you ask, but again, the more consistent the better. And do you need evidence? Do you need data to back up what you're saying? Is it good enough to say, "I've done this work, I feel confident," or do you need the actual KPIs and reports? Figure out what's valid there.

[00:23:25] A note about the decision-making process: sometimes you have a change management process. Maybe you have a mature product, a mature feature, and it takes multiple steps to get something across. Like in our last talk, it might be a very mission-critical feature. It can't just be approved because it was approved by one person; it has to go through multiple checks in order to be validated in every way possible. That's a long process, so that might mean you have to have all your ducks in a row before you can get approved on anything, but also wait for approval to be finished by everybody in a change management process. My organization is implementing a change management process, and it does require a lot of approval, for that reason: it's mission critical.

[00:24:09] Or it could be a little more concise, with a main loop and sub-loops, as in this example, where it has to go through a couple of passes in order to get some validation. It's more of a subroutine on top of the main routine. Consider: does your organization have a change management process, a decision-making process, like a chart? Charts are beautiful. If not, just ask somebody who might be in charge of this to help you along, to understand what it takes to get something done.

Knowing when to stop

[00:24:38] That leads us to our fifth element, and that's a great one to talk about: knowing when to stop, when enough is enough. The discovery phase is always very insightful. You can meet a lot of people and get a lot of good resources, but if you're anything like me, knowing when to stop can be very challenging. A couple of tips here to help you put the brakes on and just move forward. Your secondary research is starting to repeat itself and you're getting information that's almost duplicate. You say, okay, this is probably on the right track: repeated information.

[00:25:15] Your primary sources correlate and corroborate, and you are having a coherent process and outcomes described to you, which is a good sign, meaning there's not a lot of variation. You are finding things you already know, so it looks like you do know what is valid, and you don't need a whole lot more research based on what you already have. And if you don't have a definite answer after thorough research, that's okay. You can still proceed, because maybe you need to get some work done, and you already have a lot of good information.

[00:26:00] In that case, what you want to do at this stage, when you feel like you have a lot of good information feeding back, is collect the information in a shared folder you can provide access to for other people. I always recommend that you document your findings and schedule a follow-up call with anybody you need to have some discussion with. I would recommend providing a short description of the content at your disposal to your team, so that at least they can quickly, in one page, see what you're doing.

Putting it all together

[00:26:30] I call this putting it all together: map it all out and present your findings. Help yourself organize this content first of all, so you're not lost, and help others understand where you're coming from, and move forward. This is a nice little board I've used; I found this nice to be a source, where you have just boxes and you can either print this out and put Post-its on it or just write it out, however you want to use it. The basic idea is: take the project in mind, put in availability, timing, scope and gatekeepers, which we talked about, put some notes, describe some gaps, and fill them out. Keep it simple.

[00:27:07] Put in there what you know, what you don't know, what you feel is valid. This is a great one-page document you can share, screenshot, email, whatever, to other people, and tell them, "This is where I'm coming from. Please let me know if this makes sense." That's a great way to get people to say yes, you're on the right track, or no, we're going to talk. I've used this to my advantage because it's visual, easy to follow and to the point. You might have a lot of great information to report, but keep it to the point.

[00:27:38] To recap, the five steps: scope, availability, timing, gatekeepers and decision making, and then knowing when to stop. Key takeaways, the key points of discovery we talked about: get started by finding nodes in the company to help you be communicative and request information, and know when to start and stop your process. Start when you're fresh, and approach stopping when you have some core correlating information.

[00:28:07] As a send-off: get started, do some research with contacts and peers, document your findings, get approvals by gatekeepers. I have here the handy dandy example of a one-page little document you can put together, which I'll share with you. Here are some references for continued reading, and if that's a little too fast for you, here is a QR code for the whole document and deck. You can keep in touch with me on LinkedIn, Twitter, whatever. It's been a pleasure speaking to you all today. If we have a little bit of time, we could have a chat and discussion.

Q&A

[00:28:42] Rory: Great, thank you very much. That was a nice, concise walkthrough, and it brought me back to when I first started my career. Everything was a black box around my part of the project. I didn't understand how everything else worked, so I do think it's great advice to just walk around, talk to people and try to figure out how the whole end-to-end flow works. I have a question, but if anybody else has questions, please do write them in. My question is: what happens if you're that new person on the project and you do want to get that end-to-end insight, and people are just saying, "Just focus on what you're doing, stop asking all these questions, just do your job"? Do you have any advice if anybody comes up against that kind of pushback?

[00:29:36] Tadeh: That's usually an unenviable situation, where people say just get started, get going. In that case, you can play it a little more clever: okay, sure, let me get started. All you have to do is ask in the form of a question, or as a form of approval, so they know you're getting something done, but you can also request information. You're saying, "Hey guys, I have this next step and I want to do X, Y and Z. Is this the right thing to do? If not, tell me where I can get good information. If it is, great, can you tell me who I could talk to and get the next step approved?"

[00:30:13] All you've got to do is take the same steps and package it as an email or a request to say, "Hey, I'm moving along. Can you give me some more information and context, and if it's a rejection, can you give me some good documentation to fall back on?" That way they understand you're getting work done, but at the same time you're still doing some kind of covert research to get the right information. We've all been in a situation where everybody moves fast, they're stressed out, they just need to get things done, so be mindful of that. But it also doesn't hurt to ask, "Hey, am I doing it right? If not, give me some resources. I'd be more than happy to take a look at it and fix it." That way they know you're going to provide an action in return and not just pass-through research.

[00:30:55] Rory: Brilliant. Well, that actually brings us exactly to time, so I just want to thank you once again for sharing those great insights on the end-to-end process.

[00:31:07] Tadeh: Thank you so much, Rory. Appreciate it.

[00:31:10] Rory: Thanks for tuning in with us today. We genuinely hope that this video sparks some fresh insights and ignites inspiration for changing the ways that you work. But as with all things product development related, there is no one-size-fits-all, so please do share your thoughts in the comment section below and let's keep the conversation going. Finally, if this video resonated with you, please do us a favor and hit that like button and subscribe to our channel. This not only keeps you up to date with all of our latest content, but it also helps us with the YouTube algorithm. Lastly, if you want to keep learning, we have a couple of videos suggested here, but otherwise, until next time, take care and enjoy the rest of your day.