Mental models, a quick note:
A mental model is a simple representation of reality, of how something works
Product management relies heavily on mental models
Charlie Munger:
“[...] You can't really know anything if you just remember isolated facts and try and bang'em back. If the facts don't hang together on a latticework of theory, you don't have them in a usable form. You've got to have models in your head. And you've got to array your experience both vicarious and direct on this latticework of models.”
Each step overlaps with the next in the sense that, for example, while you are working on an idea, there will come a point where you start to generalize your idea, but you may end up backtracking. Between each step there is a kind of handshake where you move on to the next step and continue the process. The assumption may be wrong and you may go back and rethink the idea. And it's like a continuous flow between stages that is not fixed in reality. He's a little more intangible. Using this model, you can understand at what stage of the journey you are as a product manager, at what stage of the journey as a product developer your product is, and this will help you determine whether you are ready to move on to the next stage and maybe return to the previous one.
Going from zero to something
Discovery of problems and potential solutions
UX research, customer feedback, business problems
Definition of hypothesis
White canvas, brainstorming, whiteboard sessions, informal chats, coffee breaks
Divergent thinking, be creative: draw, write, perform!
Set aside time to think
Frameworks: Design Thinking, Lean Startup
Sharing your idea with the world, diverse perspectives
Put your idea(s) in writing
Sharing of ideas (no matter how small, silly, or ambitious they seem)
Early and quick validation of hypothesis – i.e. am I after something? Is someone else already doing this?
Start with your immediate circle (colleagues, manager) and then expand (different teams/functions/orgs)
Incorporate feedback from stakeholder and answer their questions. Focus on those disagreeing with the idea.
Objective: align on business problem and product vision to solve it (including MVP, proposed roadmap)
Collaboration Tools: Google Docs, Sharepoint, Slack, etc.
Time to test your idea (quickly and at low-cost)
What is the problem you are trying to solve?
Identify minimum feature set that would validate your hypothesis
Collaboration between product, development and design teams
Assumptions? Risks?
Balance between: quality, frugality, speed
Be clear about the hypothesis your MVP will test and define your success criteria (hint: success metrics ≠ hypothesis)
Set clear expectations with stakeholders, i.e. MVP is not “the product”
Capture data from your MVP
Frameworks: Agile Development
Time to Launch!
Incorporate feedback from MVP: pain points, must-have, should-have, delighters
Re-assess P0/P1/P2 based on feedback and learnings
More expensive investment, assumptions and risks still exist
Performance KPIs (inputs + outputs). How to measure economic performance?
Very important to know if you are adding value and/or how to pilot
Launch is only the beginning!
Brainstorming with Tech: How can technology help solve business problems?
Foster a tech-driven approach to product development
Shortlist of 15 pain points identified by business teams
Divergent Thinking: write down ideas
2-pager with high-level business problem and solution
Socialize with my product team → business team → product peers → engineering → cross-functional teams
Convergent thinking
How to define the scope? Deliver value, be frugal, build for scale?
Challenges:
20-pages document with too many details... “I am not sure what you want to build”
Tech: “let's build complex and fancy features from the onset (e.g. NLP, ML)”
Simplify scope: mental model for feature sets (UI, Content, Systems Integration, Targeting)
Communication with Tech (user stories): Need to lead with the product vision, build PoCs
Launch of MVP of “chatbot”... more of an interactive wizard.
Development:
mechanisms for progress update
designated “core team” to make low – level decisions (not requiring leadership sign offs)
go/no-go mtg prior launch
Launch: customer feedback (quant + qual) → VERY IMPORTANT
Evaluation & Learnings: success metrics ≠ hypothesis!
High engagement, good conversion, positive feedback, low financial impact
Challenge: Why should we continue investing if it is not bring financial results?
Product – time to go big(ger)!
Redefine scope, longer term vision (3Y plan) → platform vs stand-alone app
Alignment with additional stakeholders: product peers, platform owners (e.g. mobile), cross-functional, international teams, etc.
Challenge from platform owners: “how will your product help me achieve my goals?”
- Product goals (adoption, engagement, conversion) and business goals (revenue, cost savings, productivity)
Understand what you want to learn from the beginning (hypothesis)
Create shared goals with external teams to drive better collaboration
Involve your tech teams in all product development stages, they are your partners!
Sergio Luna, Amazon Sr PM