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 budget for remodelling. 😉
A good product manager spends time offline authoring a vision and plan for the product.
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.
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.
Teams
My teams aren't made up of designers, engineers, product managers, QA engineers, etc. They're composted 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 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 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 face to face discussions and watch productivity escalate.
Good product managers may be experts in a specific process, but great ones are experts in flexibility and adapting to change.
Products
Making a product better starts by examining the data, crafting hypotheses, and instrumenting smart analytics.
Good products don’t always start out looking good, but they do solve a problem for their users.
Design for the future, it'll be here before you know it.
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.
Users
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; if you’re nice to them, they’ll give you feedback.
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
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 forumla 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 process needs to flex around what is going to make teams more successful.