Dogfooding for PMs
Dogfooding means using the product I help build in a real work context. I value it because direct use can reveal confusing language, broken transitions, missing defaults, and operational friction that a plan or demo may hide. I do not treat dogfooding as proof that the product works for every customer. It is one source of evidence, and it becomes more useful when I define its limits.
I use dogfooding as a disciplined practice rather than a slogan. I choose a workflow, use the product with ordinary constraints, record what happens, and separate observations from explanations. The goal is not to perform enthusiasm for an internal audience. The goal is to make product quality and customer empathy part of everyday decision-making.
Choose a real workflow
I start with a task that matters to the people we serve. “Use the app more” is too vague. “Set up a new workspace, invite a colleague, and recover from a missing permission” gives me a path to follow. I write down the trigger, desired outcome, dependencies, and point at which the workflow should be complete.
I prefer a workflow that includes the edges around the feature. A happy-path demo may look fine while setup, permissions, empty states, notifications, billing, or handoffs remain confusing. I note which parts of the experience are representative and which depend on an internal account, test data, or privileged access.
I decide what I am trying to learn. I may be checking whether the terminology is understandable, whether the first-use path exposes the right next action, or whether a support handoff contains enough context. A learning question keeps me from turning every annoyance into a priority without understanding its consequence.
Use the product like a customer, carefully
I try to use normal devices, data, time constraints, and permissions for the workflow. When I need an internal shortcut, I label it. I do not quietly use administrator access and then conclude that a standard user’s experience is clear. I also avoid asking the team to create artificial behavior just so my session looks successful.
I record what I expected, what I saw, what I did, and what happened next. These are different things. If I cannot find a setting, the observation is that I could not find it. The explanation might be naming, placement, permissions, or a missing mental model; I should investigate before declaring the cause.
I capture friction close to the moment it occurs, but I do not let a running list become a verdict. A rough note such as “export failed” needs a later check: what data, role, browser, state, and error were involved? Reproduction turns an impression into an actionable product question.
Protect the difference between internal and customer evidence
My internal context changes what I notice. I know the roadmap, terminology, workarounds, and intended design. I may forgive a confusing label because I know what the team meant. I may also notice edge cases because I understand the system better than a new customer would. Both effects matter.
I mark dogfooding findings as internal observations. I do not use them to claim that customers behave the same way or that a problem has a particular market size. For those questions, I combine dogfooding with customer interviews, support themes, behavioral data, usability research, or other relevant evidence. Continuous discovery for product managers helps me keep that broader learning habit active.
I also avoid asking employees to expose personal or sensitive information just to make a scenario feel real. Test data should be safe, representative enough for the question, and clearly separated from production records. Privacy and security constraints are part of product quality, not paperwork after the fact.
Turn friction into a useful ticket
When I find an issue, I describe the customer situation and consequence before suggesting a fix. “The button is too low” is weaker than “A new workspace member cannot tell whether the invitation was sent, so they retry and may create duplicate invitations.” The second description gives design, engineering, support, and product a shared problem to examine.
I include reproduction steps, account context, expected behavior, observed behavior, evidence, and open questions. I distinguish a defect from a preference. A workflow that feels slower to me may be appropriate for a permission or compliance requirement. I ask what risk the current experience creates and who is affected.
I prioritize dogfooding findings by consequence and confidence. A blocker in a core workflow deserves attention differently from an awkward phrase in a rarely used setting. I do not need a false precision score, but I do need a reason for the order. Some findings should become fixes; others should become research questions, documentation, instrumentation, or explicit decisions not to change.
Make it a team habit without making it theater
I invite design, engineering, support, sales, and operations to dogfood where their context adds something. Different roles encounter different failure modes. I make the session safe for reporting problems: the purpose is learning, not evaluating the person who shipped the feature.
I define when dogfooding happens. It can be part of discovery, pre-release readiness, a rollout checkpoint, or a review of a mature workflow. A feature flag guide for product managers is useful when I need to expose a change to a controlled internal group without pretending that internal access is a complete launch.
I close the loop. I tell participants what happened to their findings, even when the answer is “not now” or “we need more evidence.” Without that response, dogfooding becomes a suggestion box and people learn that reporting friction has no consequence.
My bottom line
I use dogfooding to make product behavior concrete. It is most valuable when I choose a real workflow, preserve the customer’s constraints, document observations carefully, and combine internal experience with external evidence. Using the product myself does not make me the customer. It makes me a more attentive steward of the experience I am asking others to trust.
Next step
For a structured foundation in product discovery, experimentation, and product decisions, I use the Product Manager Certification, a commercial Product HQ resource. The Product HQ newsletter shares practical product lessons and frameworks.
