The most important question we all need to ask ourselves today, and to keep asking going forward is: “What kind of community do I want to be a part of?” Once you’ve created a vision of what calls to you, then you need to clarify by asking “Why do I want to be a part of it?”. What will you get out of giving of your attention and time to that community, and how much do you want to give?

these frameworks have become a crutch for organizations that want to look innovative, but are too scared to lean into true continuous inquiry and actually allow data and evidence into their decision-making processes. Like me with my fake mirror checks when I couldn’t have told you the color the car behind me, many product managers “perform” agile. They do stand-ups, retrospectives, and look at analytics data, but still can’t articulate their customers’ primary challenge, or describe how customer value aligns with business goals.

Managers of product managers or product leaders usually end up in those roles because they are great product managers, but great product managers, perhaps counter-intuitively, do not always make great people managers. Great people managers need to be really intentional and transparent about how they manage their direct reports and what is expected from them.

I meet a lot of product people – product managers, product owners, agile coaches, scrum masters, business analysts, project managers – and I’ve learned that there are a couple of constants, whatever the title or role. Namely that each of these roles performs an ever-evolving mix of tasks and that most product people want to understand how to progress.

This complete lack of qualitative data process within functional teams often leads to really bad habits, like finding a way around the product manager, begging dev teams for favors, or throwing tantrums in a desperate attempt to get their voice inserted in the process. Product managers might complain about problematic stakeholders who “disrupt” their backlogs, but ask yourself: have you really taken the time to build a process that helps funnel this data in a way that is clear, transparent and workable?

A dev once told me “you can’t make a baby with 9 ladies and 1 month.” This sentiment very much applies to process engineering and driving change. As much as you might want to enact change on all fronts, all at the same, that tactic usually sets you up for disaster, burn-out, or both. The best thing you can encourage and drive forward as a product person in change management is focus, focus, focus.

As I’ve moved through various product roles over the last 10 years, I’ve come to realize that there are two types of product people – builders and optimizers. I fall very naturally and easily into one of these types and have found that it can be helpful to think about my own skills and career progression through the lens of theses two types for the following reasons:

As I’ve examined all of the great thinking that is going into Operations, I considered my own approach to implementing Ops. As a Builder PM, I’ve landed on Operations being the practice of trying to engineer myself out of a job. My driving question as I’m working on building a product/service is, “Are the processes and systems that I’m building going to continue to help the team and support a good process after I’m gone?” This perspective is crucial for PMs because anyone can hold a badly organized process together if they are the only ones who have to deal with it. I challenge you to reflect: if you disappeared tomorrow, would the processes you have put into place be accessible and understood by someone else? If the answer is no, then you need to rethink your approach to Ops.

As 2019 gets underway, I’ve been enjoying taking stock of what we saw at Mind the Product Training over 2018. As a product manager I’m always looking for signals and patterns, and evaluating what early trends could mean for my products, and now for product practice. Noticing early indications of patterns of behavior can help product managers to plan ahead and work specific questions into their learning roadmaps.

We ended up writing and then completely trashing two entire versions of the full-day workshop. This was wasteful, maddening, and completely avoidable. Luckily, we kept learning, and kept iterating, and in October 2018, rolled out our full-day workshop, titled A Product Mindset on Metrics, which received extremely positive feedback from a group of product managers at our London conference. I’d like to reflect on the lessons we’ve learned over the past year, in the hope that these will help other product managers to identify and rejig their experimentation process