Welcome to Tibor product management page
This site is about my product management materials and experiences
Last updated
This site is about my product management materials and experiences
Last updated
“My primary responsibility as a PM is to answer the question of why we develop features by linking them to customer outcomes and then on to business impact. Together with the team we detail what feature output we could do to reach sought outcomes and impact. Here we test different things until we find the right ones, and I contribute as a PM, but expect the whole team to be engaged.”
What business impact is most important to achieve?
What improved customer outcomes would achieve business
impact?
How would different development efforts improve customer
outcomes?
Output-focus is about maximizing the number of “stuff” (features, epics, products) produced. This is a valid focus when you’re making a big bet that you’re pretty sure will have the right outcome and positive impact. It could be a pre-requisite to other bets or initiatives. When having an output focus, remember that customers do not want features; they want you to solve their problems!
Outcome-focus is about applying yourself to understanding your customer needs, solving their problems and creating new possibilities for them. You know that you’re succeeding when your customers have changed, or adopted, behaviors that make their life easier.
Impact-focus is about maximizing the bottom-line for the organization in term of revenues. Generally, actions here tend to be dictated by cost accounting, resource efficiency and economies of scale with the purpose of cutting costs. It may be a very valid focus for a while, but remember that an organization that focuses on solving its own problems doesn’t have time to solve its customers’. Do that for too long and you’ve lost sight of your customers; what was the purpose of the organization to start with?
Two companies in the exact same space are going to pick different opportunities. I really encourage teams to take time to explore the opportunity space, to assess which opportunities are most likely going to drive their desired outcomes, and to use their company’s mission, vision, and strategy as a filter.
Because Google is going to choose one opportunity, and Apple is going to choose a different opportunity. It’s not because one opportunity is bigger than the other, it’s that those companies have completely different DNA, and so they are going to filter opportunities differently. This is where I think the heart of the product strategy lives, and most of us are skipping it.
And finally, once we discover opportunities, we need to make sure that we discover solutions that deliver on those opportunities. And it’s the links between the two which help us evaluate our thinking, it’s how this tool acts as a critical thinking aid. We really want to ask this question, in fact our experiments should help us ask, one, is this solution viable, but then it should help us test the link. Does this solution deliver on the opportunity? And again, that sounds so obvious, but we have built all sorts of solutions that don’t actually deliver on the opportunity we’re targeting. And then finally, we have to ask, does the solution deliver on the opportunity in a way that drives our desired outcome? Because even if we solved the problem for the customer, but it doesn’t increase their engagement, we didn’t actually create value for our business.
In the future, we’ll all be shifting toward continuous product discovery.
But here’s the goal. The goal is to do smaller research activities every single week by the team building the product. So that in any point in time, when they need to make a product decision, they can stop and take stock, and have multiple data points from multiple research activities that very week and say, based on what I know right now, what’s the best decision I can make.
The goal of the PM should be to maximize impact/output, in theory extending the formula to “impact/output = impact/outcome outcome/output”. It will be important to link business impact to customer outcomes and all the way down to feature outputs, as well as to estimate the effort required to build feature outputs.
It is important to make sure the targeted customer outcomes support the sought business impact. But too much focus on impact brings risks of making a series of short-term improvements rather than actual customer innovations. It is also less inspiring for the team, as great teams derive meaning from helping their customers. Ideally business goals and customer needs are aligned early on in the process, resulting in a positive flywheel effect, as if they are perceived to be in conflict, it is likely a signal of some underlying problem.
The best PMs avoid the trap of not paying attention to the customer. They manage the trick of prioritizing to maximize impact/output, while at the same time focusing most of their actual work on the customer outcomes. Success is to innovate on behalf of your customers.
A PAD is where the results of product discoveries and product retros are documented. This document consists of three different sections that get completed during the product lifecycle – from discovery to launch:
Problem/opportunity framing
Solution framing
Post-launch recap
Every product development process starts with either a problem to solve or an opportunity to capture. During this stage, product teams clarify what the problem or opportunity is, who the target audience is, why we are solving this problem and why now, what success metrics are, and how competitors may have solved this problem (e.g., if it leads to neutralizing competition). At this stage, the product team explores a few potential solution directions without going into detail about solution design and implementation. The goal is to consider every possible solution, so it’s best to save the details and concerns for later.
Section
Guiding Questions
Problem statement
What problem are we solving?
What is the opportunity that we are addressing?
Audience
For whom are we solving this problem?
Rationale
How do we know this is the right problem to solve? Why this opportunity and not others?
Does this relate to current OKRs and if yes, which ones? Or is this a proposal for future OKRs (based on business strategy)?
Will this neutralize competition? Differentiate Miro? Delight prospective users?
Any links to customer research, conversations, or observation from data?
Success metrics
How do we know if we solved this problem?
Competitive research: (if neutralizingcompetition)
How did others capture this opportunity / solve this problem?
Potential solution directions
What are some high-level solution directions to explore to capture this opportunity / solve this problem?
Describe potential solutions through short descriptions or high-level sketches / low-fi prototypes (no implementation details at this stage).
Compare the high-level solution directions (e.g. through impact vs. complexity using high-level T-shirt sizing estimates in days, weeks, months).
During this stage, the team chooses the most viable solution and goes deep on solution discovery. Discussions should focus on what the solution is and the scope of it, why proposed solutions were rejected, dependencies, risks and mitigating factors, and the GTM (go-to-market) plan and strategy.
Section
Guiding Questions
Proposed solution
What is the scope of the proposed solution?
What are the key features?
How difficult will it be to realize the solution?
Why proposed solutions were rejected
Provide context for why this solution was chosen over the others.
Include links to user research, customer data, etc.
Out of scope
What is not in the scope of the proposed solution?
Dependencies, risks, and mitigating factors
What are the dependencies?
What are the risks associated with the solution (e.g. compliance, legal, privacy, security, strategic risk, operational, infrastructure stability/scaling risk, etc.) and the mitigating factors?
GTM strategy
What is the release plan? List the key milestones (e.g. dev complete, alpha, beta, general accessibility, etc.).
What is the marketing and operational support needed for this launch?
What are the pricing and packaging strategies?
WHAT’S REALLY ON A STORY CARD?
Imagine a card from a library’s card catalog. That card’s got useful information on it to help you organize it and confirm you’re talking about the right book. A good story card is a bit like that.
Short titleOne that’s easy to insert into a conversation when you’re talking about it. A good title is the most valuable part of your story. Don’t be afraid to rewrite it if it’s confusing people.DescriptionA sentence or two that describes what we’re imagining. It’s a good idea to describe who, what, and why—who uses or needs it, what they’ll do with it, and what benefit they hope to get from it.
Product Managers are responsible for designing and delivering a profitable product or feature into the market. Define product strategy and KPIs based on market analysis, pitch a product vision to get stakeholder buy-in, and design a user-centered prototype that adheres to engineering constraints. Develop an execution timeline that handles competing priorities, communicate a product roadmap that builds consensus amongst internal stakeholders, and create a comprehensive go-to-market plan based on product KPIs.
[Product Name] solves [meaningful problem] for [target customer] by providing [benefits or value propositions]. We’re interesting because, unlike alternatives, [unique differentiator].
Babylon solves the desire of urban professionals to live a greener, healthier lifestyle by providing cost-effective and convenient access to hyper-local, fresh, organic produce. We’re interesting because, unlike alternatives, our fully automated and space-efficient solution eliminates the time-intensive process to learn and maintain the otherwise manual, error-prone and complicated alternatives currently on the market.
The most effective products start with a comprehensive market-based, insight-driven strategy. Identify the right problems to solve through market research, target user definition, and market sizing.
Create a compelling vision and strategy that will set up the team to solve those problems. The vision tells a story: what you are building, for who, and why it matters. The Strategy is about how you are going to realize your vision and takes the following things into account: User needs, Key Features, Competitors & Differentiation, Business Goals, Trends.
After identifying that core job to be done and the desired outcome statements, the next step is to identify the needs that your product or feature solve for. The idea here is to classify those desired outcome statements into buckets that can then be prioritized.
This can be done by surveying or interviewing (e.g. by using a Likert Scale) the users whose core jobs to be done were mapped out and asking them to rate and rank how important each desired outcome statement is to them, and whether or not the current solution they have in place to fulfill that is satisfying (and to what degree).
Underserved needs: Very important and very unsatisfied Overserved needs: Very unimportant and very satisfied Irrelevant needs: Very unimportant and very unsatisfied Appropriately served needs: Somewhat important and somewhat satisfied Table stakes: Very important and very satisfied
Pains are functional (e.g., a solution doesn’t work, doesn’t work well, or has negative side effects), social (“I look bad doing this”), emotional (“I feel bad every time I do this”), or ancillary (“It’s annoying to go to the store for this”). This may also involve undesired characteristics customers don’t like (e.g., “Running at the gym is boring,” or “This design is ugly”). These are things that prevent customers from even getting started with a job or that slow them down (e.g., “I lack the time to get this job done accurately,” or “I can’t afford any of the existing solutions”). Risks: (undesired potential outcomes)What could go wrong and have important negative consequences (e.g., “I might lose credibility when using this type of solution,” or “A security breach would be disastrous for us”).
Customer Gains: Gains describe the outcomes and benefits your customers want. Some gains are required, expected, or desired by customers, and some would surprise them. Gains include functional utility, social gains, positive emotions, and cost savings.
Pain relievers describe how exactly your products and services alleviate specific customer pains. They explicitly outline how you intend to eliminate or reduce some of the things that annoy your customers before, during, or after they are trying to complete a job or that prevent them from doing so.
Q: produce savings? In terms of time, money, or efforts.make your customers feel better? By killing frustrations, annoyances, and other things that give customers a headache.fix underperforming solutions? By introducing new features, better performance, or enhanced quality.put an end to difficulties and challenges your customers encounter? By making things easier or eliminating obstacles.wipe out negative social consequences your customers encounter or fear? In terms of loss of face or lost power, trust, or status.eliminate risks your customers fear? In terms of financial, social, technical risks, or things that could potentially go wrong.help your customers better sleep at night? By addressing significant issues, diminishing concerns, or eliminating worries.limit or eradicate common mistakes customers make? By helping them use a solution the right way.eliminate barriers that are keeping your customer from adopting value propositions? Introducing lower or no upfront investment costs, a flatter learning curve, or eliminating other obstacles preventing adoption.
Gain creators describe how your products and services create customer gains. They explicitly outline how you intend to produce outcomes and benefits that your customer expects, desires, or would be surprised by, including functional utility, social gains, positive emotions, and cost savings.
Q: create savings that please your customers? In terms of time, money, and effort.produce outcomes your customers expect or that exceed their expectations? By offering quality levels, more of something, or less of something.outperform current value propositions and delight your customers? Regarding specific features, performance, or quality.make your customers’ work or life easier? Via better usability, accessibility, more services, or lower cost of ownership.create positive social consequences? By making them look good or producing an increase in power or status.do something specific that customers are looking for? In terms of good design, guarantees, or specific or more features.fulfill a desire customers dream about? By helping them achieve their aspirations or getting relief from a hardship?produce positive outcomes matching your customers’ success and failure criteria? In terms of better performance or lower cost.help make adoption easier? Through lower cost, fewer investments, lower risk, better quality, improved performance, or better design.
Mission: Build relationships Business goals: Healthy and growing business: In order to achieve this: Boost MAU (Monthly Active Users) How: Increase retention But: Retention is in conflict with the mission!
We need to discover the product to be built, and we need to deliver that product to market. The purpose of product discovery is to quickly separate the good ideas from the bad. The output of product discovery is a validated product backlog.
Will the user buy this (or choose to use it)? Can the user figure out how to use this? Can our engineers build this? Can our stakeholders support this?
Product discovery involves running a series of very quick experiments, and to do these experiments quickly and inexpensively, we use prototypes rather than products. At this point, let me just say that there are several types of prototypes, each for different risks and situations, but they all require at least an order of magnitude of less time and effort than building a product.
To set your expectations, strong teams normally test many product ideas each week—on the order of 10 to 20 or more per week.
Will the customer buy this, or choose to use it? (Value risk)
Can the user figure out how to use it? (Usability risk)
Can we build it? (Feasibility risk)
Does this solution work for our business? (Business viability risk)
We know we can't count on our customers (or our executives or stakeholders) to tell us what to build.
Customers don't know what's possible, and with technology products, none of us know what we really want until we actually see it. It's not that customers or our executives are necessarily wrong; it's just that it's our job to make sure the solution we deliver solves the underlying problem. This is probably the most fundamental principle in all of modern product. Historically, in the vast majority of innovations in our industry, the customers had no idea that what they now love was even a possibility. This is only becoming truer with time.
The most important thing is to establish compelling value.
It's all hard, but the hardest part of all is creating the necessary value so that customers ultimately choose to buy or to use. We can survive for a while with usability issues or performance issues, but without the core value, we really have nothing. As a result, this is generally where we'll need to spend most of our discovery time.
We expect that many of our ideas won't work out, and the ones that do will require several iterations.
“The most important thing is to know what you can't know.”
To quote Marc Andreessen, “The most important thing is to know what you can't know,” and we can't know in advance which of our ideas will work with customers and which won't. So, we approach discovery with the mindset that many, if not most, of our ideas won't work out. The most common reason for this is value, but sometimes the design is too complicated, and sometimes it would take far too long to build, and sometimes there turn out to be legal or privacy issues. The point is we need to be open to solving the underlying problem in different ways if necessary.
We must validate our ideas on real users and customers.
One of the most common traps in product is to believe that we can anticipate our customer's actual response to our products. We might be basing that on actual customer research or on our own experiences, but in any case, we know today that we must validate our actual ideas on real users and customers. We need to do this before we spend the time and expense to build an actual product, and not after.
An MVP, or minimum viable product, has just enough features to get early adopters excited. After launching an MVP, you’ll get a lot of feedback that will help you understand if you have product-market fit and what areas you should invest in next.
To create an MVP:
· Start with the business model canvas
· Weigh against competing solutions
· Make sure it’s aligned with business objectives
· Translate to requirements
· Identify KPIs
How to Test & Validate your MVP (Minimal Viable Product)
DoorDash autonomous d2d program
The goal with this phase is to create a shared understanding of the problem space across all sprint team members.
1. What’s the hardest part about [problem context] ?2. Can you tell me about the last time that happened?3. Why was that hard?4. What, if anything, have you done to solve that problem?5. What don’t you love about the solutions you’ve tried?
Lightning Talk
A lightning talk is a short presentation, usually about 20 minutes, focused on a specific topic. • User research • Who is the user? • What are their needs and goals? • Why does this problem matter to users? • Business goals • What are we trying to solve? • Why does it matter? • What have we tried in the past? • What’s worked well and not so well? • Technology • What are our technical capabilities? • What are the limits and constraints or limitations on our existing tech?
Interview
Interviews allow you to gain perspectives from a number of different vantage points. There are lots of types of interviews you can set up including • User interviews • Build empathy for users • Get a deeper understanding of user needs and pain points • Stakeholder interviews • Dive deeper into some of the reasoning, rationale, and context of why this specific problem is important to solve • Topics can include any previous efforts to solve this or a similar problem • Expert interviews • Provide specialized insights around a specific problem, population, or technology • Can be either internal or external
How might we
How Might We” is a method to capture problems and frame them as opportunities that can be solved. Each statement should be captured on its own sticky note. “How Might We” statements always start with the same three words, which creates a positive solution oriented framing. • How - acknowledges that we don’t know the answer yet but believe this problem can be solved • Might - acknowledges there can be more than one solution and that we shouldn’t stop at the first idea. “Might” also acknowledges that not every solution will work, but it’s still ok to discuss and explore ideas that might not pan out • We - acknowledges that the team is invested in solving this problem together
Affinity Mapping
Affinity mapping is a way to visually sort related ideas together into categories and themes. You’ll go through each idea/insight, quickly discuss, and then place onto the board. As similar or related ideas are discussed their respective sticky notes should be placed next to each other. Over time you will see that clusters of related sticky notes have started to form. Make sure to label each cluster. Once all sticky notes have been placed on the board and you have a couple of different clusters, look to see if any of those clusters are related. Related clusters will create themes If so, rearrange those clusters so that they are next to each other. Draw a circle around those clusters and create a label for the theme that you discovered.
Defining Success Metrics
The HEART framework is a user-centered method to define metrics that measure the quality of the user experience. It’s simple and easy to understand and can help with decision making in later phases. There are five dimensions: • Happiness - user attitude towards your product • Engagement - how users are using the product in terms of frequency or number/types of features used • Adoption - how many new users start using your product • Retention - how many users keep coming back • Task Success - ability for users to complete critical tasks in order to be successful with the product Across these dimensions, you will then want to start by identifying goals, then signals, and finally metrics to measure how well your product is doing.
A goal is something the user is trying to do or something you are trying to help them to do. A signal is a change in user behavior that indicates that the user is achieving the goal. A metric is a way to measure signal and quantify how much user behavior has changed Keep in mind that it’s ok for goals to have multiple signals and metrics. It’s also not necessary to have metrics for every dimension. It’s more important to pick things that are relevant to the problem you are trying to solve.
How to write User Stories?
Assumptions & Questions
Thinking Hats
The Thinking Hats exercise allows you to make sure that different perspectives are being discussed and pushes people to be open to different perspectives since everyone will have to represent multiple, differing views.. The team discussion focuses on one hat at a time. The order can vary, but you'll want to start and end with the blue hat (process). This order works well when comparing ideas: • Blue hat - process (align on goals and order of hats) • White hat - data • Green hat - creativity • Yellow hat - benefits • Black hat - judgment • Red hat - intuition • Blue hat - process
Tool: https://theplot.io/#tutorial
Example: https://www.youtube.com/watch?v=VGJ2Jrf_REk&feature=youtu.be
· Figma: Getting Started with Prototyping
· Figma Mirror App for Android
· Figma Mirror App for iOS devices
Validation is a super important part of the Design Sprint process. It allows you to test your ideas and get feedback without having to invest in fully building out the idea. You’ll validate your idea by talking directly to your target users to learn more about them and then ask them to try out your prototype and provide feedback. In addition to getting feedback from users, it’s also important to validate that your idea can actually be built by the engineering team in a reasonable amount of time. example
Technical Feasibility
You can have the best idea, but if it can’t be built in a reasonable timeline you won’t get very far. • It’s not your job to know how to build it, but it’s important that you can have a technical conversation to understand complexities and make tradeoffs • You can use a prototype to help facilitate the conversation by walking through user facing flows • You should also come prepared with some questions around what data is needed to generate the UI, where user entered data will be stored, and any causes for latency
Kanban: check this video
