AMA: Workiva Vice President Of Product Management, Chris Omland on Technical Product Management

Oh, this is a tough one! Since the AMA is about Technical Product Management, I'll answer from that perspective. It's common for a successful company and product to face tech challenges after they've achieved significant growth. When you're a startup moving fast to find product-market fit, you might not prioritize the technical hygiene of your product. Then, as you scale up, you may need more time to go back and clean up or improve your technology. Eventually, this issue needs to be addressed, as outdated tech could limit future success, pose security risks, or even hinder expansion into new markets. I've been asked to lead product and R&D teams through situations like this, which can be extensive, multi-year efforts. My biggest takeaway is that more than focusing solely on technology is needed. It's easy to say, "Our tech stack has reached its end of life, and we need to adopt this new one." But stakeholders, like executives, customers, partners, and investors, care about business results. So, always frame your work regarding the outcomes you'll create, such as faster scaling, improved product experiences, or reduced operational costs. By emphasizing these outcomes instead of just the technology, you'll gain support from key stakeholders, which will help you secure the necessary time and resources for success.

It's fantastic that you're planning to grow your skills. You probably already have solid technical skills and knowledge, so I'd suggest focusing on learning more about the discipline of Product Management (and hey, reading this is a great start!). A fundamental resource I always recommend is Marty Cagan's books: Inspired, Empowered, and Loved. Start with these to establish a strong foundation in Product Management.

I'm excited to see a question about metrics – being data-driven is super important! First, keep in mind that there are various types of product metrics. I think of them as Usage, Business, and Performance. * Usage metrics might include daily active users, feature usage frequency, and time spent on the product. * Business metrics can cover churn rate, revenue per customer, cost per customer, and monthly recurring revenue. * Performance metrics focus on availability, response time, and defect rate. Of course, these are just a few examples – you could track many more metrics. The key to deciding which ones to measure is to focus on the outcomes you want to achieve. For instance, if your CSAT score is low and you think it's due to performance, define performance metrics that will impact CSAT, like UX latency or uptime. Measure your baseline, design experiments to improve performance, run those experiments, evaluate the changes in your metrics, and then see if that boosts your CSAT.

Thank you for your question, and it's excellent to see that you're considering a transition into Technical Product Management. To help you with this process, I recommend focusing on three primary areas. Firstly, it's essential to evaluate your motivation for this change. What drives your interest in Technical Product Management? Is it your passion for problem-solving, a desire for more significant influence, or the pursuit of new opportunities? Understanding your motivations, documenting them, and effectively communicating them to others will help you set, work towards, and measure progress against specific goals as you transition into Technical Product Management. Secondly, seek a Technical Product Management mentor or colleague within your organization who can assist you in this transition. Initiate a conversation with this individual by sharing your reasons for wanting to make this career change. For example, "I find the most fulfilling aspect of my job is working closely with my current Technical Product Manager to understand customer problems and apply technology to solve them. While I enjoy coding, I derive greater satisfaction from comprehending the issues we're addressing and implementing technological solutions. I hoped we could collaborate to identify opportunities for me to focus more on these aspects." Lastly, invest time in learning about Product Management. Given your background as a software engineer, your technical skills and ability to understand and comprehend technology are likely sufficient. However, you may need to develop various aspects of Product Management. I recommend reading the following Marty Cagan books * Inspired * Empowered * Loved

Awesome question! First off, take some time to understand your audience. Who are they? What challenges do they face? What matters to them? The answers to these questions will help you tailor your communication for different stakeholders. One tip I often give to Product Managers on my team is that the real meeting often happens before the actual meeting. I encourage them to connect with key stakeholders before a larger meeting, walk them through their updates, and ask for feedback. This approach gets their support and makes them feel involved in the process, and helps you refine your updates before the stakeholder meeting. You can also use this opportunity to ask them about other stakeholders, like, "What do you think is missing from my update that our Client Success leadership team might need?"

Stakeholder management is crucial in Product Management. Start by identifying your stakeholders and understanding their concerns, motivations, and what matters to them. Once you have a clear picture of your stakeholders, you can prioritize them based on your product's life cycle stage, the outcomes you're aiming for, and where you'll need support and alignment. For instance, if launching a new product, focus more on Product Marketing and Customer Support teams. Their support will be essential in raising customer awareness and ensuring success. On the other hand, if you're looking to scale a product that has achieved product-market fit and requires additional resources or investment, you might spend more time with executive stakeholders, discussing the business impact and future effects on crucial business metrics.

This might be unconventional, but I don't rely on a single methodology or framework for prioritization. You can use approaches like RICE or Value vs. Effort. Still, they should only be one part of the prioritization process. We could automate the whole thing if it were as simple as applying a scoring system. But there's so much more to consider! Product Managers must consider factors like business context, technology team input, long-term strategy, and more. My top recommendation is to start by identifying the outcome you want to achieve. Understand the "why" behind that outcome and how you'll measure success. This understanding should serve as a baseline for prioritization.