This Winter break, I embarked on a journey to apply what I've learned so far about Product Management during my first semester at Carnegie Mellon University Silicon Valley.
The best way I found to do this: build a Product.
---
I started by thinking about a problem. I wanted to find a problem that I personally encountered as that would make it more fun and motivating for me to solve it.
After finding a couple problems, I went about identifying the user segments that share the problem and would be appropriate to target. I ended up choosing North American University students (specifically undergrads) and interviewed a couple of them to identify:
- Their use cases & the frequency of the activity
- The problems they encounter
- Their work arounds to these problems
- How solving this problem would impact their activity/their experience
With all that data collected, I was able to target the specific problem to solve and its use case. It was different from what I had previously envisioned but it allowed me to format a couple solutions that I refined bit by bit.
Finally, after choosing one, I was able to start planning and implementing the solution. I started by planning my architecture with front end, back end api and database.
After spending 2 days planning a detailed API for the solution, I realized that I was approaching the problem the wrong way. I was planning the product as a whole, without allowing myself to react to change once the project started to be released. Furthermore, I was trying to plan an architecture that would be resilient to change and scale to +1000 concurrent users without even knowing if the product would be used by such an amount that required this type of infrastructure.
Coming from a more technological background this was difficult for me to come to this realization as I felt that I needed the architecture and it would have a positive impact on the user.
-> I asked myself this: what is the most valuable to the user?
The architecture is invisible to the user, a black box. Using tools such as #Supabase I would be able to created an MVP that could scale to at least 100 concurrent users with good loading time and responsiveness (<1s).
My Plan:
1. Create an initial working product (mvp) in a way that allows flexibility for change. Remember to keep it simple.
2. Identify how users react and use the product. Do they return often? What would improve their experience the most? Is scale an issue that has an impact on users' use of the product?
3. Iterate quickly and test to find what works and what doesn't for users.
4. Go back to step 2. is scale/architecture now an issue that needs to be addressed?
Learning points:
- Identifying a problem that is valuable and can be solved
- Releasing a product
- SEO and product marketing
- Tracking metrics and reacting to new users
- Open Api v3
- SvelteKit
- Tailwind Css
Let me know in the comments if you want a part 2 of this journey.
The best way I found to do this: build a Product.
---
I started by thinking about a problem. I wanted to find a problem that I personally encountered as that would make it more fun and motivating for me to solve it.
After finding a couple problems, I went about identifying the user segments that share the problem and would be appropriate to target. I ended up choosing North American University students (specifically undergrads) and interviewed a couple of them to identify:
- Their use cases & the frequency of the activity
- The problems they encounter
- Their work arounds to these problems
- How solving this problem would impact their activity/their experience
With all that data collected, I was able to target the specific problem to solve and its use case. It was different from what I had previously envisioned but it allowed me to format a couple solutions that I refined bit by bit.
Finally, after choosing one, I was able to start planning and implementing the solution. I started by planning my architecture with front end, back end api and database.
After spending 2 days planning a detailed API for the solution, I realized that I was approaching the problem the wrong way. I was planning the product as a whole, without allowing myself to react to change once the project started to be released. Furthermore, I was trying to plan an architecture that would be resilient to change and scale to +1000 concurrent users without even knowing if the product would be used by such an amount that required this type of infrastructure.
Coming from a more technological background this was difficult for me to come to this realization as I felt that I needed the architecture and it would have a positive impact on the user.
-> I asked myself this: what is the most valuable to the user?
The architecture is invisible to the user, a black box. Using tools such as #Supabase I would be able to created an MVP that could scale to at least 100 concurrent users with good loading time and responsiveness (<1s).
My Plan:
1. Create an initial working product (mvp) in a way that allows flexibility for change. Remember to keep it simple.
2. Identify how users react and use the product. Do they return often? What would improve their experience the most? Is scale an issue that has an impact on users' use of the product?
3. Iterate quickly and test to find what works and what doesn't for users.
4. Go back to step 2. is scale/architecture now an issue that needs to be addressed?
Learning points:
- Identifying a problem that is valuable and can be solved
- Releasing a product
- SEO and product marketing
- Tracking metrics and reacting to new users
- Open Api v3
- SvelteKit
- Tailwind Css
Let me know in the comments if you want a part 2 of this journey.