In this developing series where I write about some of the big lessons, I have learned as I work in my first Product Management job, today I want to talk about scope. Scope is a very general term and in Product Management, it literally could mean everything or nothing at the same time. In this piece, I want to focus on the scope of projects and from there what the end results should be. As a PM you must remember to always be listening to your customers and your competitors. Understanding what people what and what people are doing will give you more information when defining and presenting that next new feature or product altogether. Recently I worked on a project to address a pain point one of our users was having, and working in an internal product team, I did not have very many users like some of you may have. I listened to the pain point, I came up with a solution and I presented on it to my manager and the users. During the presentation, the user proposed a solution that she had come up with on her own. A solution that I felt like would be a great way to address her needs but I lost scope of the project and wanted to make it something to address all of our users. Really this came out of a need to positively impact as many people as possible.
The solution that I proposed went through and began development. During QA, we ran into a few issues and a couple showstoppers (for a lack of better words). While the development and QA process was unnecessarily difficult, I was hopeful that his project would get released wand would be well received. The feature went out and we had some use from our target users as well as others but I had a feeling that for the work we did, the use was not really there. Well after a few months my fears came true. The feature had broken and while we have gone ahead with a fix, it still broke. This lead to another conversation as to what we can do to then again fix the original problem. Long story short, we went with the user's proposed solution. A very straightforward and simple solution.
Why did we have to go through all that just to make a fix that would have not required all this work? Well, that question is hard to answer and that is just another lesson to be had. You take a risk when you make something new and you have to assess that risk and reduce it all you can but sometimes, it just comes around to get you. That is something I will talk about in a later piece but for this one, I want to point out that I did not assess scope properly.
While the solution really came down to one person and I wanted to expand that to use for the bigger audience. When fixing a problem for a user it is also worth noting how much other users will have for this fix/feature. A simple solution is a lot of the time the best one. As a PM you should always keep in mind what the scope of the project is and who it will be using it on a regular basis. Continue to a solution for individual users but know where priority sits and how necessary is your solution to the bigger and individual audiences. Continue to question yourself and always communicate with your user as an individual and the greater user group. this questioning and communication will expand your ability to assess and define the scope of a project.