My Product Philosophy

This list was originally published on kathy.pm/philosophy, and it’s maintained in a GitHub gist, where it’s updated regularly and you can see how it has evolved over time!

Product managers

• Seek out failure, it teaches us to think like a scientist. If you start with a hypothesis, then try to prove yourself wrong, you’re bound to make much better decisions. You have to be willing to fail, and that in itself is going to help you build confidence and be more convicted about what your strategy is in the end.
• There are hundreds of methods for building products and running teams. As a quality PM, it’s important to have an open mind about all of it, but finding your own process and philosophy can be grounding. It helps you find your pillars so that you don’t smash into things while you’re building. Remember, however, that you can always find a budget for remodeling. 😉
• The beauty of a good process is when it just becomes how you do your work. When you forget you’re following a process at all is when you know the process is working for you, your team, your company, and your customers.
• The advice I give new Product Managers or PMs coming onto a team for the first time: put your ego away, don’t be ‘the big idea person,’ and help your team ship as much as possible. If you ship products you’ll learn about them, and people around you will benefit from the momentum you’re building.
• The advice I’ve given myself throughout my career: put your ego away, you don’t have to be the ‘the big idea person,’ and just have fun shipping good software that people use.
• Giving yourself the permission to learn helps minimize anxiety caused by the expectation to succeed.
• Be comfortable being uncomfortable.
• A good product manager spends time offline authoring a vision and plan for the product.
• A great product manager starts their vision work by listening to customers.
• A product manager’s success is measured by the sum of her team’s capabilities to deliver successful outcomes.
• Mentors will support and push you to do a better job. Allow them to see your vulnerabilities. They’ll consistently be a force for inspiration and creativity.
• Ask questions and always assume you’re not the smartest person in the room.
• Be the anthropologist for your product, hunt for questions, and figure out how are you going to get what you need in order to make improvements.
• Protect momentum at all costs. Making no decision is worse than making the wrong decision.
• Experience is built by continually shining the spotlight on challenges, risks, and failures and then making a plan to come out on the other side stronger and better equipped.
• It’s always a good idea to take time to write a triage plan. Then keep it in your back pocket.
• Getting dirty helps build empathy for teammates and a clearer understanding of how a product works.
• There is always room for improvement. Staying humble helps keep us curious so that we can watch for opportunities that make us better at building useful, good products.
• Good product managers may be experts in a specific process, but great ones are experts in flexibility and adapting to change.
• Don’t be afraid to have a mantra. These days, mine is “bring yourself.”

Teams

• My teams aren’t made up of designers, engineers, product managers, QA engineers, etc. They’re composed of product makers. Everyone should feel empowered to contribute to the process, vision, design, etc. (and know who your experts are and let them be that).
• A lot of chatter is a solid indication that your team is operating well. Silence is a scary, dark place that you want to get away from pronto.
• Teams operate better when they’re happy, but being afraid of disagreements is detrimental. Consensus is not always a good thing, bring boba tea if you have to.
• Remember the POA (product opportunity assessment) that you wrote? Share that with your team, they’re dying to know what the vision is for the product that they’re building.
• The best team members are infinitely curious about how to make the product more usable; this is their number one agenda.
• The best designers are part engineer and vice-versa.
• It’s vital for team members to have empathy for other disciplines.
• Take time to think about what your team needs to have a good, happy, productive, and fulfilling day.
• Collaboration doesn’t require a calendar invite; welcome impromptu discussions and watch the productivity scale.
• The moment you realize you have forgotten to tell someone something about a project is the exact moment you should tell them.
• It’s important to have empathy for your customers but also work on building empathy for your teammates. When I do this I build trust and a sense of solidarity. This is something my customers also benefit from because it means we’re able to build better products as a team.

Products

• Making a product better starts by listening to customers, examining the data, crafting hypotheses, and instrumenting smart analytics.
• Good products don’t always start out looking good, but they do solve a problem.
• Strive to be nimble and build flexibility into your product architecture so that you can iterate quickly.
• Analytics shouldn’t build a product alone but act as a single factor that helps influence decisions.
• Good products are easy to make. Great products are made because they’re worked and reworked — it sometimes feels like it’s working just how the rock tumbler I had as a kid did.

Customers

• How people use your product is different than how they say they use your product; know the difference.
• Sometimes the best feedback will completely surprise you, and that’s a good thing.
• Users have names and email addresses; go talk to them.
• 20 minutes is a perfect amount of time to gather some quick insights about your product from a customer.
• Don’t let your data and analytics fool you into thinking you understand your users. Your job is to understand customers, not just analytics dashboards.
• If you ask for information from a user, explain why you need it. If you don’t need it, don’t ask for it.
• Become really great friends with your customer support team members, they usually have a holistic beat on what’s going on with your users.

Process

• Value flexible communication over process tactics. A process that is too rigid runs the risk of paralyzing the team, resulting in missed opportunities and weak communication. For example, an engineer may be afraid to speak up after seeing wireframes because they don’t know ‘when the right meeting’ is for providing feedback.
• The product development process doesn’t just happen, it’s calculated and flexible. Refine your process as you go, but do it with intent and in collaboration with your team.
• Keep a diary and write down what’s happened from the week (include notable mentions, burn, projected releases, etc. Scroll through IRC and look for anything that pops out). Send diary entries to key players on your team (stakeholders, clients, team members, curious marketing and sales folks, your manager).
• Write a plan for how you’re going to get started (I like using a strawman in the beginning and refine as I go based on goals and vision)
• In a quality process, everyone on the team knows and understands their role from day one. If there are questions like, “what should I be working on,” or “how do we resolve this disagreement,” your team should know how to get the answer quickly so that they can commit to moving on and continuing making the product.
• If you keep a good eye on your process flow, chances are it’s going to be easy to spot where it’s breaking down. Using tools to help unstick these areas are key: retro, MVS (minimum viable story) conversations, three amigos, pull request tsar, etc.
• There’s a formula for standups: I’m working on X, I’m blocked/not blocked by Y, I’m going to be working on Z. But don’t get in a standup rut.
• At standup ask, “how are you feeling about the way things are working/going/running/etc. today?” Sometimes the details get lost between the lines, and it’s very important to know how and when to bring those out (you’ll be dealing with it one way or another, might as well be now).
• The product rollout and launch process should be just as calculated as the one used to make the product.
• I believe that agile should always have a little ‘a’ because the process needs to flex around what is going to make teams more successful.