Victor Dronov

Here are some of the areas one can look to potentially increase engineering team velocity, i.e. do more over the same period of time. * Cross-craft collaboration: PM, UX and Engineering. Do you make decisions quickly, or spend a lot of time debating the direction? Do you trust each other? Do people have to go back to PM for clarifications all the time (and stay blocked, while waiting for such clarification)? * External dependencies: are you sell-sufficient working on your thing, or have to rely on other teams’ deliverables and timelines? Can you either influence priority of your external components, or own all of it end-to-end if it's the latter? * Motivation: is the entire team bought into a grand idea of your thing? Do they consider it fun to work on it? Or people just “clocking in”? * Roadmap efficiency: do you frequently have to go back and re-do a thing? (e.g. late requirements or design changes) Is one-off, throw away work common on your team - or you are building with one brick over the other? * Tech debt: PM nightmare - stopping working on new features for a while. Yet sometimes team may see opportunities to modernize their codebase - unlocking unbelievable velocity for the future. Decide together if it's an "okay" time to do it now (it is never a "good time" from a PM point of view, and always is from Engineering point of view) * Perceived velocity: is your team working on something behind closed doors for a long time, or is open to share exciting, tangible, easy-to-consume updates every week? The latter would help external stakeholders to appreciate team’s velocity way more. At Atlassian, we foster a culture of micro updates (think of a Tweet-size shareout) shared every week - and we have a platform component Goals & Projects to enable this process at the organization level.

Let me assume you are staying within your software (or hardware) realm, as switching from software to hardware product management (or vice versa) could be way steeper hill than entering a new domain like AR/VR. Here is something that would made me seriously consider a candidate without a specialized AR/VR experience - for an AR/VR position: * Stellar track record in non AR/VR product management. You rock as a product manager - many will consider this more valuable than hands-on with the domain. This is table stakes. You are already at disadvantage, so first of all demonstrate you are a rock star PM. * Story telling - if at all possible, find and demonstrate how aspects of your prior work can be applicable to AR/VR. Was there a project where you came up and succeeded with an unconventional UX solution? Tell a story how AR/VR is evolving quickly to find new UX patterns - and how you can apply your past experiences to that. * Domain knowledge: yes, you didn’t work as an AR/VR PM. But you surely invested a lot of time in understanding this domain. You know the market, the players, the product, the technologies. You’ve been to industry events and meet ups to hear inside stories first-hand. You talked to AR/VR customers about their experiences, yays and nays. You can speak the same language with your hiring team. * Passion - lack of hands-on experience is your disadvantage. Make your genuine passion offset that one. Show it’s not “just a job” for you. With all other things equal, this will tip the scale in your favor.

PM work life is a firehose of Slack/Teams message, customer emails, meeting requests and deadlines. Here is what I find helpful to make sense of the chaos and stay on top of the key things. * Capture, Organize, Get Shit Done. Resist the urge to jump on every message or email the same moment - you may find yourself exhausted while still behind on your goals. Instead, find a tool which lets you to quickly “capture” a thing which require your attention - and move on. Organize these to-dos thoughtfully - later, when you have time: what need to be done now, today, later this week? Some people find Eisenhower matrix framework helpful, though it may require much discipline and self-training to apply it to every day situations. My personal go-to solution for capturing and organizing PM to-dos is Trello. * Meetings. Look at your calendar and brutally question it. Which meetings you don’t have to be in? Which ones you’d be fine just reading a summary after? Sometimes you’ll have to say “no” to get your work done, even if it slightly annoys someone. * Async collaboration. A great way to reduce meetings load for me is Atlassian Loom: record a short video clip and share with your collaborators, let them responds or even with another video clip, async, at the time which works best for everyone! * Focus time. Every week you likely have a Big Rock - a bit of work which isn’t immediately urgent, yet have an outsize importance and require significant focus time to accomplish. * Plan your week. Apply everything above to your Friday routine - plan your next week ahead. Meetings you’ll decline? Focus time you’ll block on your calendar - to accomplish most important tasks? 3 things (maximum) you are looking to accomplish next week? * Plan your energy, not time. Lastly, recognize when you are at the peak of your productivity - late afternoon? mid-day? morning? Do your best to allocate this time to the most important things you are looking to accomplish. You are most productive on Fridays? Make it a no-meeting day to finish up that blog or product spec!

Okay, you are not happy with your recent track record - good opportunity to flex your analysis, story telling and “marketer” muscle. * Goals. These features didn’t seem to support your goal - but they likely supported someone else’s (even if you were unhappy about it)? Demonstrate how you supported supported those goals or how you thought outside of the scope of your immediate team, to support some fellow team. * Learning. Did these features fail, though you knew this from the start? Focus your story on what your team and organization could learn shipping these features, and how you had a chance to apply this learning to do better in what followed. This could include external (customers) and internal (process, best practices) learning. * Leadership. You weren’t happy with what sound like a top-down request to build these features. Likely your team wasn’t thrilled either. Tell a story how you helped them to “disagree and commit”, stay motivated and deliver what just needed to be done.

Product Manager position could be optional. A team building a software product will have someone fulfilling a product manager role either way. * Who will take accountability for the market success of team’s work? * Who will deeply understand the market, the customer and their pain worth solving? * Who will fight for the team inside of the organization to acquire needed resources and to defend existing? * Who will be a “PR manager” building team’s brand inside of the organization? * Who will detect early learning and make a case for adjustments and improvements? This list may go on and on. Try to make the case not for the position of a PM (“I am a PM, you listen to me”), but for the inevitability of the work above for any successful team. Chances are, your engineering leader and their team do not find this type of work most exciting. Hopefully they are reasonable to agree it is required, or at least helpful for the eventual market success of your product. From there, if you established there is work to be done - demonstrate how you can take this work off the team’s plate and have them focus on what they do best and enjoy most - building great software (or hardware, if that’s your thing).