ProdPad and Intercom blogs
Product Management is about making sure that you are building the right product to solve the right problem, for the right user. Product Management operates at the intersection of Business, Technology and Customers.
Idea Management involves capturing new suggestions, ideas and feature requests. Ideas are the building blocks of your product backlog. Ideas until validated are just hypothesis. Validated ideas serve as a good source of inspiration for your product evolution.
Specifications is providing product development, design team and other stakeholders with all the information they might need to build the feature. It includes business case, User personas, user stories, wireframes, prototypes, mockups, definition of done (DoD), etc.
A roadmap is a communication tool that helps communicate where you are, where you are heading (product vision) and how you expect to get there (plan). Your product roadmap should remain consistently true to your product vision, but always flexible in how you are going to achieve the vision.
Prioritization is an actionable interpretation of your roadmap. It’s the process of deciding what should be build when, based on what will bring most value to the user and the company. Value + Cost determines priority. Prioritization is about making trade-offs. If you focused too much on short-term value, the product or company won’t sustain for too long. If you built only for long-term, your customers won’t wait for you. There needs to be a balance between quick wins and product evolutions.
Delivery is about working with engineers, designer, marketing, support and other teams to design, build and deliver high quality, to the specification product.
Experiments are run and analytics are tracked to continually test and improve product/feature and understand what is truly of values to the users.Experimentation is a way to test out the hypotheses we came up with in Idea management.
Three places where we can use analytics and experimentation:
1. To define KPIs for success
2. Measure success metrics against the defined KPIs
3. Continuous experimentation to evolve the product
Good metrics should be quantitative, comparable and actionable.
Create a user workflow funnel/tunnel, measure metrics at every step and make changes based on what you learn at every step.
Customer feedback is the qualitative validation of your findings from quantitative feedback. It can generate new ideas, used to layout specifications, help with prioritization, discovering new problems. It can collected in may different ways like customer interviews, usability testing, support requests, general conversations.
Types of Requirements:
1. Business Requirements
2. Business Rules
3. User Requirements
4. Functional Requirements
5. Non-Functional Requirements
6. External Interface Requirements
7. Physical Environment Requirements
8. Development Constraints Requirements
User Stories characteristics: INVEST
Independent: A user story can be developed separately from any other user story, regardless when it is developed.
Negotiable: A user story should be general enough for your team and customers to work around the implementation.
Valuable: A user story should bring some sort of value to the client.
Estimatable: A user story should be estimatable in terms of time or complexity to design and develop the story.
Small: A user story is meant to be small so that it can be developed in a short period.
Testable: A user story should have an acceptance criteria.
User Stories need to be:
User Story format: As a WHO, I want to WHAT, so that I can WHY
Acceptance Criteria format: Given condition (and condition) When action Then outcome (and outcome)
Given I am a user with a disabled account
When I try to log in
Then I should not be able to log in
And I should get an error message that tells me who to contact for help
Acceptance Criteria vs Definition of Done
The acceptance criteria are to verify the new feature is working as expected by the stakeholders. They are better called Business Facing Tests.
A business-facing test is a test that’s intended to be used as an aid to communicating with the non-programming members of a development team such as customers, users, business analysts and the like
The definition of done is to see if the feature is ready to be deployed to production and only for programming team members. The definition could include that the feature has tests, documentation is updated, release notes are written, version control is cleaned and anything your team needs todo to make it able to release this feature. Some also call it DoneDone as in really done.
Hypothesis format: Don’t validate the idea, validate assumptions instead
- We believe that [Assumption A] is true
- Therefore we believe [this capability]
- Will result in [this outcome]
- We will have confidence to proceed when [we see a measurable signal]
Product Manager’s Core Competencies
- Conducting customer interviews and user testing
- Running design sprints
- Feature prioritization and roadmap planning
- The art of resource allocation (it is not a science!)
- Performing market assessments
- Translating business-to-technical requirements, and vice versa
- Pricing and revenue modeling
- Defining and tracking success metrics
- Build the right thing (Product Manager)
- Build the thing right (Dev Team)
- Build it fast (Product Manager)
- If you build the right thing and build the thing right, you might be too late to the market.
- If you build the thing right and build it fast, you might not be building the right thing.
- If you build it fast and build the right thing, you might not be building the thing right.