You are hired as the first product manager at an early stage startup. You are expected to hit the ground running, start shipping product features to attract customers. Often these features are ideas that the founders want to build. You are under pressure to quickly build a prototype to test the idea. You quickly mock a design with the help of a freelance designer and share them with the developers. Over the next few weeks, an early beta version is shipped hoping to attract early customers but you are met with disappointment. You analyse a bunch of data, make a few customer calls and eventually arrive at the conclusion that the product didn’t reach escape velocity because of just one missing feature. You convince the team to build the missing product feature and the cycle repeats itself until the exec team decides to shelve the entire product and move on to another idea.
Early in my #ProductManagement career I thought the product did not take off because of just one missing feature. I know better now ЁЯзШ- I need to subtract, not add features.
Tweet
In my career as product manager, I have made countless such blunders. I wish there were how-to-guides for product management back in 2008-09. Surprisingly, I see budding product managers make the same mistakes even today.
Why do product launches fail?
Product launches fail due to countless reasons such as product-market-fit, timing, pricing, strategy, marketing, competition etc. But here’s a product manager’s view of why product launches fail to reach escape velocity:
- Bad Strategy
- Unclear problem definition (the “why”)
- Complicated solution
- Lack of product vision with end goal
- Bad execution
- Wrong prioritization
- Stakeholder misalignment
- Lack of Go-To-Market strategy
- Undefined dependencies & risks
- Wrong KPIs and measurement
In case I missed a key reason, please feel free to click on Tweet and let me know. Will consider adding it.
One more reason why Product launches fail is …
Tweet
A successful product launch starts with writing a clear and detailed Product Requirement Document (aka PRD). But in order to save time, product managers instead jump to create a Jira ticket with product requirements and share with engineering counterparts to start development. Since there’s no standardized PRD template within the startup, each PRD varies in quality, depth & clarity depending on the availability of time.
Over the years, I have refined the elements of a good Product Requirement Document (aka PRD) for my use. Feel free to copy (File тЗТ Make a copy) and customize the Product Requirement Document (PRD) template – Google Docs and use it at your startup.
What are the elements of a good Product Requirement Document (PRD)?
- Summary Page
- Change Log: To highlight and track changes in each new version
- Link to other research docs, slides, Jira tickets etc.
- Ownership: Identify and align product, business, marketing, design, developers, QA owners etc.
- Goals / Objectives / Problem Statements: Software developers and architects would attest to this; more time you spend on thinking about design, less time you would require to build it. So product managers should resist the temptation to jump to solutions without thinking deeply about the nuances of the problem. One of the most useful techniques is: ask the 5 why’s. It’s better to focus on the deepest 5th why than the 1st one.
- Proposed Solution: Usually novice product managers tend to design solutions for themselves instead of for the target customer. They assume customers have as much context as the PMs themselves while using the product. Instead think of the simplest solution that even an average target customer can understand without explanation.
- Prioritization: How does this fit into the overall Northstar metric?: Most common mistake novice product managers make is wrong prioritization. They fail to ask why is this important now? How will solving this problem now help move the company North Star metric? Is this the most important needle mover now?
- Stakeholder alignment on assumptions: Almost all products have underlying assumptions that product managers make. But often they fail to highlight them upfront to all stakeholders, thereby leading to conflicts and missed execution/growth opportunities.
- Go-To-Market strategy: All PRDs must have a Go-To-Market strategy. Either the PM or corresponding stakeholder can fill in this section. Failing to think in advance about how to drive awareness, adoption while designing the product is critical. Not taking this into account will make the product dead on arrival.
- Open Questions: Usually PMs keep a side note to track open questions but it’s important to track them as part of the PRD so that stakeholders can comment on it publicly and it’s tracked to closure.
- What is not included in this version: As important as what will be built, is what will NOT be built. It’s important to highlight this and ensure upfront stakeholder alignment and avoid assumptions. It’s better to debate them upfront than later.
- Dependencies & risks: Identifying dependencies and risks in the PRD and tagging stakeholders will ensure they spend time de-risking them. This usually ensures product launches happen on time instead of last minute delays.
- User stories: Detailing the product workflow in a PRD ensure everyone including developers understand the expected user and interaction behaviour. If developers lack of this clarity, the end product interaction is not as expected requiring rework and delays.
- Product design: Share complete product designs before writing a developer writes a single line of code. Doing it in parallel to save time, usually ends up delaying it due to mid-sprint cycle design changes.
- Events Instrumentation: Instrumentation is underrated and usually left for last and not well thought through. PMs in a hurry to ship miss instrumenting many events and later realize they cannot measure the KPIs or A/B experiments.
In case I missed a critical component of the Product Requirement Document, please feel free to click on Tweet and let me know. Will consider adding it.
One missing element in this PRD is …
Tweet
Feel free to copy (File тЗТ Make a copy) and customize the Product Requirement Document (PRD) template – Google Docs and use it at your startup. Also feel free to comment on the Google Doc itself if you would like to add missing elements in this PRD.
In case you find this Product Requirement Document (PRD) template useful, please tweet below and let me know.
I found this free Product Requirement Document (PRD) template in a Google Doc format. Check it out…
Tweet
Click on the below image to download the Product Management PRD template.
