This may sound counter-intuitive. When building product, don’t jump into development.
Define the problem first with a simple methodology.
If asked, you should be able to boil down the problem to a statement like the following:
PERSONA is experiencing SOMETHING NOT WORKING, which involves SOMETHING THAT BREAKS, and THIS IS WHY IT MATTERS TO GOAL
Use the WHAT/WHY/HOW method first!
WHAT
What is the problem or opportunity you want to solve for?
WHY
Why does this problem matter? Is there a business case you can point to?
HOW
How do you want to solve this? This is where POTENTIAL solutions are welcome, but are extremely preliminary ideas.
Product Development Process
This is the high-level development process that occurs in most product-led organizations. I’ve included specific examples where documentation or outcomes may need to be delivered in each phase.
03.
Design
- User Research
- UX and Visual Design explorations and directional lock
- Cross-team reviews across relevant stakeholders
04.
Implement
- Creation of Epics, Stories, etc prior to product Kickoff and Handoff
- Program Management to update leadership
- During development, product and design support engineering as needed.
05.
Launch
- Product Reviews to confirm build-to-spec
- Partner Certifications, as needed.
- Preparation of analytics dashboards, as needed.
- Completion of GTM tasks (Support, Marketing, etc..)
06.
Assess
- Project Retrospective
- Support follow-ups and improvements
- Compare against success metrics
07.
Repeat
- Review learnings from previous step, and decide on further investments.
One Team, One Dream
Important Documentation
GTM Brief
GTM iS EVERYTHING
- This document should be completed in draft format by the time the product kickoff occurs, which is the point the product story or PRD is actually complete.
- During product implementation and up until launch, this will be iterated on until final (at launch).
- The GTM brief should provide all relevant information for all stakeholders involved in a product launch – including Marketing, Sales, Operations, Support.
| Example GTM Brief… |
|---|
| Product Description |
| Target Customers |
| Product / Market Problem and Solution |
| Market Risks and Implications |
| Success Metrics |
| Rollout Plan and Release Dates |
| Post-Launch Monitoring |
| Operations and Support Plan |
| Marketing, Channel, Ad Needs |
| Stakeholders (RACI Matrix) |
Product Requirements Document (PRD)
Problem definition before solutions
Before committing to anything:
- Problem Statement?
- Why it matters?
- What is a possible solution?
A PRD should reference a possible solution to a valid problem. It is a live document and owned by the product development team, not just product management.
| Example PRD… |
|---|
| Document Summary Table (PM / Eng Team / Design / Status / Stakeholders / Exec Sponsor) |
| Background and Context (can reference MRD) |
| GTM Planning (may link to GTM Brief) |
| High-Level Use Cases and Requirements |
| User Stories and Phasing (include links to issue tracker or where details are held) |
| Technical and Performance Requirements |
| Success Metrics |
| Open Questions |
| Risks |
| Future Scope |
User Stories
Where requirements are held
- Owned by the Product Development team (Product Management, Design, Engineering), not just Product Management.
- Passes through review stages and will stay live until implementation is complete (at which point it is LOCKED).
- Some fields may not apply as they may be covered in the PRD. That is OK, the template is meant to standardize on a structure.
| Example User Story… |
|---|
| Why |
| Acceptance Criteria |
| Product Design (Figma) |
| Success Metrics |
| Scoping Process |
| Dependencies and Implications |
| QA |
| Launch and Support (may link to GTM Brief) |
| Future Scope |