Bryan Dunn

I've been working at fully (or practically) remote companies for ~5 years now and I believe they can certainly work. Tools like Zoom, Slack, and Miro can (mostly) handle the day to day activities of product teams. However, in person time is still critical for some activities and for building a product culture you want. Some rules I have: 1. I try to do a team offsite at least quarterly. This allows for free flowing discussions and brainstorming that don't translate well virtually. I plan a few days that include ample whiteboard time as well as dinners to do some bonding. 2. As a product leader, you need to be hyper aware of how team members perform in a virtual environment. You don't get as much signal from body language virtually. I always try to check in during 1:1s on how each team member feels about the culture, their role within the team and try to manage virtual meetings accordingly.

I've consistently seen the best PMs do a few things to increase velocity, though I think this would be framed better as impact as a PM since the result of that velocity is shipping more product. 1. Be the voice of the customer - this is the most important thing by far. The best PMs employ the help of their team to solve customer problems. If you do this effectively, you get everyone on the team to focus on the customer problem, not the tech or the design or the architecture. This is where great teams live. “If you want to build a ship, don’t drum up the men to gather wood, divide the work, and give orders. Instead, teach them to yearn for the vast and endless sea.” 2. Aggressively pursue the Pareto Principle - find the 20% of the work that is going to deliver 80% of the impact. 3. Build a great relationship with your technical lead - this will allow you to comfortably challenge each other about the scope of the work, even if you don't have a technical background.

This is always a deeply personal decision, but over the years, I’ve found myself in scenarios where I stayed too long because I was comfortable. Here is my rubric for determining whether to stay or go: 1. Am I still learning? If you’re not learning something new, it’s easy to become complacent. The earlier you are in your career, the more you should demand to be in a position that challenges and stretches your skillset. If you have great leadership and perform well, you can often find ways to grow within your current company. However, if you’re unable to move out of your comfort zone and into the learning zone, it might be time to move on. 2. Do I feel excited about work when I wake up? Life is too short not to enjoy what you do. If you’re no longer enjoying the journey, it may be time to get off the train. Additionally, try to define your career goals—even though many people find this challenging. Ask yourself whether, in your current role and company, you can achieve the career you aspire to have. If the answer is no, focus on learning what you can and then move on. There’s less stigma around job switching than there used to be, so prioritize what’s right for you.

I've seen this situation quite a bit and the single most effective way to drive change towards impact-based product building is bringing data to show the downsides of the current approach. I personally failed to drive change early in my career because I tried to debate the merits of different approaches without bringing evidence (only theory). Even if you are to operating in a project-focused way, there are things you can do to shine a light on a better way: * Measure the impact of everything you are building (or being asked to build) - nothing drives change like showing investments aren't delivering impact. Go back and see how many customers are using features you built last quarter. Get that data in front of leadership. Include ways you could improve the approach next time (e.g. if we spoke with 3 customers before building, we would have known X would have been a better solution). * Get close to customers - this may be easy or hard to do in your organization, but figure out how to do it anyway. Ask for forgiveness, not permission. I like a situation where you are on a text-friendly basis with a few customers. This allows you to proactively get feedback before execution and offer this as evidence you may need to make changes. Make sure you don't let your bias get in the way here - also call out when what you are being asked to execute resonates with customers (let leaders know you are objective). * Find leaders who knows your current situation needs to change - there are usually at least a couple empathetic leaders in any organization that see the need for change. This may be outside of the product organization - it could be a sales leader, someone from marketing, customer success, etc. Work with them to first highlight the problem with project-focused operation and show a better path. Advice may differ slightly depending on your specific situation. A few situations I've seen where this is common: * In organizations where the culture is more execution than product focused (typically legacy businesses) * In organizations where leaders are making all product decisions * In specific parts of the org where a single leader is unable to let go of the details A few books you might read - Escaping the Build Trap by Melissa Perri, Transformed by Marty Cagan, and Aligned by Bruce McCarthy and Melissa Appel.