Today’s lesson talks about how a Product Manager creates the Product Spec.
The Product Spec is meant to be a living document that is constantly updated and contains all the documentation around the product that you intend to build. The most critical parts of the Product Spec?
In my opinion, there are 2. The first would be the User Needs and User Stories.
Sample User Need: <User Type> needs a way to <Achieve a Goal>
Sample User Story: As a <User>, I want <Feature/Functionality> so that <Reason>
This is where you document all the different use cases for the persona that you’re building for. This allows you to think of all the main cases, as well as edge cases to ensure that what you’re building out fulfills all those needs.
The second most critical part is the ability to attach goals and their associated success metrics to the product/features that you’re trying to build out. Being able to articulate and measure the success or failure of your product is key to being a good Product Manager.
An area of the Product Spec is a section called Feature Development Timelines. According to Kevin, PMs don’t necessarily need to be able to estimate Feature Development Timelines on their own! I breathed a sigh of relief when I heard that one. With no prior programming background, this would have been pretty difficult for me to estimate accurately. The way to overcome this setback is to have a great relationship with your engineers and have conversations with them to finalise the timelines. Get as much input from them as possible and try to establish the Sprint Velocity (The number of story points the team can complete in a sprint). Once the baseline Sprint Velocity is established, this will make your job of Sprint Planning much easier.
Epics – Super long User Story. Typically broken down into shorter User Stories
Story Point – Measure of effort required to implement a user story
The assignment for today is to use the provided template to create a spec for my own product. This is going to be exciting!
This was a pretty interesting lesson. The key takeaway for today was a better understanding of Agile Development Methodologies (always a key requirement in any PM Job Description). This was a new section that was added to the course. It was fun seeing Kevin, the designer of the course, iterate on his product and continuously improve on it.
Agile Development Methodologies
- Teams run sprints (short blocks of time allocated to work on specific features)
- Daily standup involved to communicate to team and identify blockers
- Quite a bit of planning/meetings involved – Product Prioritization > Sprint Planning > Actual Sprint > Retrospectives
- Allows you to forecast things like workload, product/feature completion
- Less structure/more flexible than Scrum
- Operates on a basic TODO list concept where there are 3 sections – To Do, In Progress, Done
- More autonomy as developers choose which bits to work on themselves
- Doesn’t make it easy to forecast completion of features/workload
Working in Cross Functional Teams:
Communicate, communicate, communicate. That was the main takeaway from this section. A product manager manages not through power, but through influencing and consensus therefore it is important to build trust with the various teams that are part of the product development process (i.e. Engineers, Designers, Sales & Marketing).
Another takeaway is the importance of being concise. No one has time to read novel-like emails, or listen to a long drawn out explanation. Enough said.
The main topic for Day 2 was User Personas. What were they for and how do you create them?
- Conduct user interviews – During these interviews, stay away from leading questions! PMs are there to listen and understand thoroughly the types of problems the user is facing and what alternatives have they tried. (Note: If a person says it’s a problem but hasn’t tried any alternative solutions, that problem really isn’t a big one)
- Creating User Personas and prioritising the ones that you want to build for – Common mistake is to listen to every piece of feedback and build all of them. Nothing good comes from trying to please everyone. Identify the top persona that you want to build for and focus on that. Delighting that one user persona will inadvertently result in other personas having their needs met as well.
As with the first day, there was an exercise. Conduct 3-5 User interviews and craft a user persona for the problem that you’re trying to solve. Can’t do this right now so will update when done.
Here’s a sample User Persona that I crafted based on a product that we we’re trying to build out at work:
User Persona Exercise – OneWeekPM
I’ve been trying different things to try and equip myself with the necessary skills needed to be a successful product manager for the last couple of months. Recently, I stumbled upon a community of Product Managers that used Slack as a communications tool (think of those old school PHP forums of yonder but built on Slack). The community has multiple chat rooms talking about different topics relating to Product Management. The people who started it were clearly on to something because even with a fee of $25 to access the Slack community, it now boasts over 1400 participants.
Recently, they launched a course called OneWeekPM.
“The One Week PM course will arm you with everything you need to know from: learning the essential fundamentals of product management, creating your own PM project, and finally cracking the process of answering tough PM interview questions. ”
Most product management course that I’ve seen so far cost a whole lot more than $97. I thought I had nothing to lose and signed up. I’m going to try and document as much of the process for me here. It’s a 7 day course (hence the name) but I’m going to give myself at least 14 days to complete it.
Every day I’ll watch about 10-15 minutes of videos, and at the end of that, there will be a simple assignment to let us get our hands dirty.
Today starts off with a simple introduction to the basics of becoming a Product Manager. What does a PM do? What types of skills does a PM need? How do we identify problems to solve?
For today’s assignment, we were tasked to identify 3-5 different problems that we could work on for the duration of the course. So here’s my list:
- The general public doesn’t really understand the implications of the business news and most people who invest, do so based on hunches, and tips, instead of understanding how businesses work (too big a problem to solve in a week?)
- When I was doing research for my thesis back in university, I had to read lots of academic papers. Those papers were long and difficult to read because of the way that they were written. Is there a way for us to visually present the data in a fun, easy to read way?
- I’ve signed up for free trials that require my credit card, and more often than not, I forget to cancel them and end up being billed even if I did not want to use the product. How can I keep tabs of all these subscriptions that I’ve signed up to easily?
- I never ever feel that I am up to date with all the things that I have to read. I have opened countless tabs, telling myself I would read them, I’ve used Pocket to store them, but all that has happened is that I accumulate a whole list of articles and never get round to reading them. How can I fix this?
Let’s see how I go with trying to solve these problems 🙂