Guest Post by: Ryan Pollack (Mentee, Session 10, The Product Mentor) [Paired with Mentor, Andrew Hsu]
I’m a structured guy. I use spreadsheets and checklists to keep me organized and on task. I love processes and procedures that help groups of people work towards common goals. And I love graphs, metrics, and the data that powers them because they communicate results and inspire ideas.
But the world of product management often lacks structure. Salespeople want something new to sell. Customers are dissatisfied with your current product and churn at a high rate. And software developers and testers want to know that their time spent writing and testing code is purposeful.
As product managers, these issues come to you ad-hoc. Sometimes an account manager emails you about a complaint that a major customer has and demands to know when the fix will release. Sometimes quality issues delay a committed launch date and you have to scramble to help estimate and communicate new dates. And sometimes developers push back on a project you ask them to tackle.
When I started as a product manager at my current company, I was overwhelmed by all these demands. An introvert by nature, too many unstructured communications cause my brain to overload and shut down. My neurons want to internalize, analyze, prioritize, and communicate about every single input. But I quickly found that impossible to do.
As a result, I was coming home from work totally drained and needing large amounts of downtime to do it again the next day. Worse, I felt unable to fulfill my primary responsibility of discovering innovations that benefit our customers and that work for our business. I also felt unable to evaluate the many requests and suggestions coming my way. This left people inside the business feeling like I was ignoring them, and it means I was probably missing some useful product improvements.
This article shares how I approached the problem, the solutions I’ve implemented, and the results I’ve seen.
How could I bring some structure to my role? Luckily my introverted, structured, research-heavy nature is well suited to problems like these. I read, and read, and read some more.
I discovered great books like Inspired and Radical Focus. I took Pragmatic Marketing and started a regular meetup group with friends I made in that class. I attended a local Agile development conference. I applied for The Product Mentor program and was accepted, giving me access to lots of high-quality thought and discussion. I even subscribed to the ProductManagement subreddit and the ProductCoalition.com newsfeed. Through it all, I discussed all my ideas with my boss.
My research and discussions highlighted a common theme: metrics are key. Business metrics define the path you’re on; product metrics show progress on that path. Without the former you can’t effectively prioritize work, and without the latter you can know neither how far you’ve come nor how far you have to go.
This is the situation I found myself in. So with the help of my product mentor, I set out to bring focus to my role by promoting a metrics-driven culture. Here’s what I did.
Created an OKR Structure
The Objectives and Key Result (OKR) system appeals to me because it provides a way to line up everyone’s workday with the larger objectives of the company. Not in a totalitarian way, but in a way that invests your 8+ hours at the office with meaning and purpose while ensuring customers (and therefore the business) derives value from your work. And at the heart of the OKR system lies metrics and data. Perfect for me!
I put OKR’s to work for my needs by tying every product project we had to a business goal. I developed this structure in the way modern product management works: prototype, validate, iterate, and launch.
Management frequently communicates our top-line business objectives and key results, even if they don’t frame them as such. So I took these and worked with our data science and customer success teams to understand the product metrics (KPI’s) that influence these results the most.
Then I created sample objectives and key results that link the product KPI’s to the businesses’. The end result was like building a road by starting from two places on the opposite sides of the city and hoping they meet in the middle, but I think it worked out. I ended up with the following structure:
It’s a very boring and dull table, but it’s simple and effective. It links each product initiative (or “feature” to most people) to a business objective. This link helps me communicate with other team members not only what we’re doing, but also why we’re doing it. This link also ensures each initiative is measurable, which means my users stories and acceptance criteria now include telemetry from the start.
Validate and Iterate
I held a few meetings with my boss to validate this approach and structure. I incorporated his feedback and improvements into the current iteration you see above.
I’m not to this point yet. As we all know, the tactical day-to-day responsibilities of product managers often swamp the strategic ones, and a lot of my days are tactical.
But we’ll get there. My vision is to post this structure internally so everyone can see it and give verbal updates at our monthly all-hands meetings. Before I do this, I’ll validate that people other than my boss and me find it helpful and iterate based on their feedback too.
Even though we aren’t using this structure as often as I’d like, the effort I spent to build it helps me prioritize where and how I spend my time, and with whom I spend it, more effectively than I had been. In the future I hope to share this more widely inside the business, and I hope our quarterly goals are based off a chart like this one.
Centralize KPI Reporting
The OKR approach doesn’t work without product KPI’s, and product KPI’s don’t work without measurements. When I started at my company we had some product telemetry in place. But it was incomplete, decentralized, and unused by anyone in the business.
Since we log many actions in our product’s database, I used my background in SQL and R to create a shared document with product KPI’s all in one spot. I augment this document with graphs from third-party tools like Google Analytics, Pendo, and Firebase.
I now update this document weekly and share it with team leads. I also share updates with our engineers in our standups. The graphs I produce give them insight into how well customers are adopting their work.
Having this document forced us to build telemetry into our product launches. For example, we delayed a major product launch for several weeks because we hadn’t discussesd telemetry with our offshore development team at first, so it wasn’t built in to the product. We’re now better about defining success up front and prioritizing the work to measure it.
Improve Team Decision-Making
Centralized KPI’s aren’t just for communicating progress. We’ve used them to justify tackling future projects. Recently some executives questioned why one product KPI, that I track in my report, was moving very slowly. This question led to a discussion about how we can move it further and faster. I’m now working other departments to move this particular needle faster. Without centralized KPI tracking, we would’ve missed a lot of customer and business value.
Let’s face it, I still get overloaded sometimes. I’m responsible for much of the day-to-day decision making and product definition as well as portions of this kind of higher level thinking and direction. We have a long way to go before metrics and data are as accessible and informative as they need to be.
And some people at my company probably still feel like I’m ignoring them. The powerful, flexible nature of software means there will always be more ideas for improvements than I can respond to in a thoughtful manner. I can’t always reply as quickly and thoroughly as I’d like to.
But having a structured, metrics-driven approach to product development and communication helped me out a lot. Just spending the time and effort to think through how our product KPI’s line up with business goals has helped me focus my time better. I can more easily evaluate which discussions I should take part in and how much effort I should put into them. I can also communicate better, by helping people understand why it’s not the right time for their idea, or by sharing how their recent idea has made an impact to our business.
If you’re feeling like your role or company lacks focus, I hope you’re able to put some of these strategies and tactics to use. They certainly are paying off for me.
Ryan Pollack is a Product Manager in sunny Austin, TX. He’s passionate about solving users’ problems, measuring impact, and communicating results. He is also a huge baseball stats nerd.
More About The Product Mentor
The Product Mentor is a program designed to pair Product Management Mentors and Mentees around the World, across all industries, from start-up to enterprise, guided by the fundamental goals…
Better Decisions. Better Products. Better Product People.
Each Session of the program runs for 6 months with paired individuals…
- Conducting regular 1-on-1 mentor-mentee chats
- Sharing experiences with the larger Product community
- Participating in live-streamed product management lessons and Q&A
- Mentors and Mentees sharing their product management knowledge with the broader community
Check out the Mentors & Enjoy!
The Product Guy