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!