The speaker delves into the realm of product management and requirements, starting with a basic premise of wanting to watch a movie. They demonstrate how such a simple requirement can be inadequately captured, emphasizing the importance of thorough documentation. Through a breakdown of the initial requirement and subsequent exploration of various scenarios, including finding TV shows instead of movies and considering different viewing platforms, the speaker highlights the complexity involved in requirement gathering. They underscore the significance of addressing gaps in requirements to ensure comprehensive understanding and successful implementation. Finally, the speaker concludes with a plan to continue exploring related issues in future discussions, reflecting on the nuances and importance of effective requirement management.

Summary

Initial Conceptualization of Requirement:

• Discusses a basic requirement: "Feeling like watching a movie, picking a movie, and watching it."
• Demonstrates how a business analyst or product manager might document such a requirement.
• Acknowledges the simplicity of the example but highlights the commonality of poorly documented requirements.

Critique of Initial Requirement and Further Exploration:

• Expands the initial requirement by breaking it down into more detailed steps.
• Introduces questions that an engineer or developer might ask to refine the requirement.
• Raises concerns about the adequacy of the initial requirement and highlights gaps that need addressing.

Exploration of Additional Scenarios and Requirements:

• Explores potential scenarios beyond the initial requirement, such as finding TV shows instead of movies.
• Discusses considerations like where to watch the movie (e.g., at home or in a theater) and subscription platforms.
• Emphasizes the importance of addressing various scenarios and the potential impact on requirement gathering.

Podcast

Check out on Spotify.

Transcript

0:00

Hey there, hope you're doing well. Let's talk about product management and requirements. Business requirements and product management, something in that space. I'm recording my screen that sits on my phone. But if you look at this picture here or this drawing, if I could even call it that, I'm not blessed with drawing abilities amongst other things, but hopefully it gives you the picture. I only use like two or three shapes. In general, there are squares or rectangles and circles, which are not exactly circles. But anyways, here, let's say you see three boxes. Here it says "feel like watching a movie, pick a movie and watch it", right?

0:21

So let's say you're trying to build something or build up an app, or it doesn't matter what you're trying to build that satisfies this requirement. Somebody comes and tells you, "hey, you know what, I need to be able to watch a movie." Here's one way you could document or capture that as a requirement.

0:55

And here's how I jot that down, right? As a business analyst or a product manager, I'm like, hey, the first box is, the user feels like watching a movie. The second box is they pick a movie, and then the third is they watch it, right?

1:28

So that kind of captures it and that at the highest level, someone feels like watching a movie, and if they feel like watching a movie, they're going to pick a movie, I guess, right? And then they end up watching it. Now this could be called a requirement on paper at least, and you could ask the developer to implement it, right?

1:49

And I say this because I've seen requirements such as this come from product during the course of my career. Obviously this is an exaggeration, completely unrelated in that sense, but hopefully you get the idea. Requirements that are not properly documented or clarified.

2:25

Just keep that in mind. Feel like watching a movie? Pick a movie, watch it right. Three boxes. It seems like it's enough documentation, but let's see why it's inadequate, right? Let me switch to the next image here. Hopefully you can see this well enough. It's a little bit tinier than the other, so this one is broken down a bit further. Right now I'm asking as an engineer. As a developer, I'm asking these questions to my product manager. Hey, you feel like the user feels like watching a movie. The next thing that they might want to do before they pick a movie, they need to pick a platform, right?

3:39

So now we come to box #2, but we had several other steps, a few other steps before that point. We pick a movie and then we stream them to devices, right? This says watch it. But before you watch the movie, you need to be able to stream this movie to one of many devices that you have, maybe a tablet, maybe a phone, maybe Apple TV or computer or whatever it is that you want to stream it to.

4:21

One of the questions I could ask is you felt like watching a movie, but what if you end up finding something that's a TV show? It's not a movie, right? Or it's a documentary or whatever it is. So what do we need to do in the application or from a requirement standpoint to handle those scenarios?

4:57

So how do you handle that as a requirement? And you could keep going further, right? You felt like watching a movie. I just went directly to picking an OTT platform. There could be several steps in between. One of them is where do you want to watch this movie?

5:42

Do you want to watch it at home? Do you want to go to the theater? So there is at least one question I can think of off the top of my head. And if you then decide that you actually want to watch it at home and you want to watch it on one of those OTT platforms, one of the next questions could be, do you have a movie in mind and are you trying to find a platform that supports or that streams that movie or are you just going to go with the platform because you have subscriptions to Prime and Netflix but nothing else.

6:16

Not sure we will see how it goes.